Install xf86-video-omapfb-0.1.1.1 on Raspberry Pi

[owrjeyz]

Hi,all I'm just trying install kodi on rpi but emerge failed because of t xf86-video-omapfb-0.1.1.1,

I installed gentoo on rpi according to https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide the head of the output of emerge is
'''

[Leio]

xf86-video-omapfb has no business being on a RPi - there is no OMAP in raspberry. You'd want xf86-video-fbdev or preferably xf86-video-fbturbo (from an overlay still afaik), but omapfb would do no good for you anyways. It probably wants some omap specific system headers, which you don't have, or some such.
RPi has a broadcom chip with their own VideoCore4 GPU or whatnot inside the SoC. To drive that in 2D, you'd want mentioned xf86-video-fbdev for starters for X, and fbturbo later for optimizations (or immediately once easily accessible or don't mind getting it from the start) - those optimization are mostly targeted at ARM specific of framebuffer usage, like making use of NEON and such, but I believe there are some raspberry specific DMA things in there to speed things a bit further. For 3D you want raspberrypi-userland (main tree might be severely outdated for the snapshot version) or the new mesa VC4 driver. I hear arm official overlay might have something these days for the latter, and possibly also the former.

Not sure if this is still an issue, some random search found this month old post. I monitor alternative architectures category for raspberry specific posts to help out with, not kernel one - and xf86-video-omapfb has little to do with kernel.

But in short - go over your VIDEO_CARDS variable in make.conf to tune what gets pulled in by xorg-drivers meta package, and it should probably be VIDEO_CARDS="fbdev" on RPi, with later xf86-video-fbturbo package added manually (or maybe in VIDEO_CARDS once things get integrated nicely in main tree).
_________________
GNOME team lead; GStreamer; MIPS/ARM64

[EvadingGrid]

Solution : apply a patch
"0007-always_include_xorg_server.h.patch"

Bug 549264
https://bugs.gentoo.org/show_bug.cgi?id=549264

[Leio]

The solution is to not build omapfb for a platform that isn't OMAP and has no use for it, as said above. But yes, if you actually have an OMAP based board, not rpi, then the patch is useful to get a more optimized driver (if it's better than fbturbo, modesetting or some such at all).
_________________
GNOME team lead; GStreamer; MIPS/ARM64

[EvadingGrid]

[Leio]

Set VIDEO_CARDS in make.conf. That's how USE_EXPAND flags work.
So for raspberry you might want this in your make.conf alongside your USE flags:

VIDEO_CARDS="fbdev"

profiles/desc/video_cards.desc has the options.

It actually also expands to USE flags like video_cards_*, so -video_cards_omapfb or something in USE will disable it, but that's not how they are meant to be used - just set VIDEO_CARDS var like USE, but those aren't cumulative like USE are, so just setting it should override omapfb without negative entries.
The USE flag expand can be useful for e.g python flags (python_single_target_python2_7 and such) for per-package setting - thoguh it also has a syntax to handle it as a USE_EXPAND variable, but that syntax is a bit underdocumented and less official, so I use the expanded USE flag names to tweak what python supports I have per-package. But VIDEO_CARDS is a global thing, no need to mess with it there, just set in make.conf

Though you are saying it isn't disabling it like this? My experience was different when set in make.conf and I don't have any omapfb business going on
_________________
GNOME team lead; GStreamer; MIPS/ARM64

[NeddySeagoon]

owrjeyz,

[EvadingGrid]

VIDEO_CARDS="fbdev"

While in theory that should not pull in omap, I can assure readers it most certainly is pulling it in as a dependency.

Next time I do it, I will try the USE="-video_cards_omapfb" and see if that fixes it.

[NeddySeagoon]

EvadingGrid,

Add -t and -v to your emerge command so we can see whats pulling it in and why.
DOn't run the emerge we just want the indented package list with the USE flag settings.

Wild guess .. its not something you have in /etc/portage/package.use is it?
The contents of that file/dir will override make.cont on a per package basis.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[EvadingGrid]

/usr/portage/profiles/arch/arm/make.defaults

# Main ARM profile

ARCH="arm"
ACCEPT_KEYWORDS="arm"

CHOST="arm-unknown-linux-gnu"
CFLAGS="-O2"
CXXFLAGS="${CFLAGS}"
FFLAGS="${CFLAGS}"
FCFLAGS="${CFLAGS}"

MULTILIB_ABIS="arm"
DEFAULT_ABI="arm"
ABI=${DEFAULT_ABI}
LIBDIR_arm="lib"
CHOST_arm="${CHOST}"

# 2006/08/18 - Donnie Berkholz <dberkholz@gentoo.org>
# Defaults for video drivers
VIDEO_CARDS="exynos fbdev omap omapfb"

[Yamakuzure]

[EvadingGrid]

One thought I had, was that after the Stage-3 went on - I did eselect set profile desktop

I wonder, if I had just before doing the profile switch, point set VIDEO_CARDS="fbdev" - if that would have made any difference.

Anyway, if somebody wanted omap, that does not circumvent the fact that it aint gonna compile until a dev adds the extra patch to the e-build.