hi, i am trying to emerge xorg-server with the following settings on a default install, no changes to make.conf or /etc/portage, except the ones reflected beyound: x11-base/xorg-server-1.5.3-r5 USE="ipv6 kdrive nptl xorg -3dfx -debug -dmx -hal -minimal -sdl -tslib" INPUT_DEVICES="evdev keyboard mouse synaptics vmmouse -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300 -elographics -fpit -hyperpen -jamstudio -joystick -magellan -microtouch -mutouch -palmax -penmount -spaceorb -summa -tek4957 -tslib -ur98 -virtualbox -void -wacom" VIDEO_CARDS="ark chips dummy epson fbdev glint i128 i740 imstt intel mach64 neomagic nv r128 radeon rendition s3 s3virge siliconmotion sis tdfx tga trident tseng vesa via -apm -ast -cirrus -fglrx -geode (-impact) -mga (-newport) -nvidia -radeonhd -savage -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -v4l -vermilion -virtualbox -vmware -voodoo -xgi" After xorg-server is installed, the following drivers fail unless putting the following into /etc/portage/package.use: =x11-drivers/xf86-video-tdfx-1.4.1 dri =x11-drivers/xf86-video-sis-0.10.1 dri =x11-drivers/xf86-video-ati-6.12.1-r1 dri =x11-drivers/xf86-video-intel-2.6.3-r1 dri =x11-drivers/xf86-video-r128-6.8.0 dri All with A similar error, i didn't want this to become too big, but if needed i can attach the actual compile-errror later this day: ERROR: x11-drivers/xf86-video-intel-2.6.3-r1 failed. Call stack: ebuild.sh, line 49: Called src_compile environment, line 3053: Called x-modular_src_compile environment, line 3833: Called x-modular_src_make environment, line 3872: Called die The specific snippet of code: emake || die "emake failed" The die message: emake failed Reproducible: Always Actual Results: driver doesn't install
Re-appearance of bug #120057 maybe?
*** Bug 266101 has been marked as a duplicate of this bug. ***
*** Bug 266974 has been marked as a duplicate of this bug. ***
*** Bug 265536 has been marked as a duplicate of this bug. ***
*** Bug 276630 has been marked as a duplicate of this bug. ***
Ok, so I've committed a patch upstream for Intel that fixes that bug but I haven't done it for other drivers. The thing is that this configure switch (at least for intel) only controls DRI1. DRI2 on the other hand is 100% automagic: configure looks at the server's SDK headers to see whether or not it's available. Now, as far as I'm concerned, DRI1 is dead. Intel ditched it (only the nearly separate i810/815 driver uses DRI1, the rest of the driver uses DRI2 exclusively). And now that mesa is a proper dep of the server, I'm tempted to just remove the USE flag from all drivers. It serves no purpose anyway as it doesn't reduce the dep list anymore and is just misleading. @Team, what say you? Thanks
Explanation why it happens in my case and some kind of a workaround to compile it without dri support: http://bugs.gentoo.org/show_bug.cgi?id=276630#c1
(In reply to comment #7) > Explanation why it happens in my case and some kind of a workaround to compile > it without dri support: > http://bugs.gentoo.org/show_bug.cgi?id=276630#c1 That's indeed what I properly fixed in the Intel driver [1] so by the next release, USE=-dri _will_ work even if the server does have DRI1 support (USE=-minimal). The open question now is whether it's worth fixing/patching all drivers or not. My own answer is "no". Disabling DRI was interesting back in the days where it was unstable or downright broken, or if you wanted to shave off a few deps to save build time and disk space. None of those arguments are still valid today (again, IMHO). Cheers [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a851139c2141f6da370186148f2836e18b2acf83
> Disabling DRI was interesting back in the days where it was unstable... I don't know if something changed the last view weeks but with loongson/MIPS I'm pretty shure this is still the case. Apart from that there are some drivers/cards without 3D support, especially the sis/XGI one.
(In reply to comment #9) > I don't know if something changed the last view weeks but with loongson/MIPS > I'm pretty shure this is still the case. Then the best thing to do is to fix the driver, regardless of any USE flag considerations. I'm just talking about the drivers' _build_. If a driver fails to build, that should be reported (here or upstream). > Apart from that there are some drivers/cards without 3D support, especially the > sis/XGI one. Then that won't change anything. If the ebuild doesn't have USE=dri, then it'll work the same. Besides, in all cases, you can still disable DRI at run-time in your xorg.conf. And FWIW, sis is dead. No one is really working on it. There are like 3 or 4 different drivers for the same hardware family and no-one has stepped up to merge them and clean them up. And since I don't own any sis hw, I'm not likely to do that myself. Thanks
*** Bug 303925 has been marked as a duplicate of this bug. ***
Hia! Please add patch [1] to stable =x11-drivers/xf86-video-savage-2.3.1. This patch does not change USE=dri case, so should be harmless for those who is able to build it already. Steps to reproduce: USE="minimal nptl xorg -dmx -doc -hal -ipv6 -kdrive -static-libs -tslib -udev" emerge =x11-base/xorg-server-1.8.2 USE="-debug -dri" =x11-drivers/xf86-video-savage-2.3.1 Thanks! [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-savage/commit/?id=b877be5d8e633227764b9a158fb41be6d19c10e5
Created attachment 244441 [details, diff] xf86-video-savage-2.3.1.ebuild.patch <- added PATCHES entry
Created attachment 244443 [details, diff] 0001-Fix-builds-when-XF86DRI-is-undefined.patch <- actual exported patch
*** Bug 347937 has been marked as a duplicate of this bug. ***
*** Bug 347938 has been marked as a duplicate of this bug. ***
It's 2013. Everything should be perfect. xf86-video-savage is fixed in version 2.3.2 upstream, intel driver work.
(In reply to David "okias" Heidelberger from comment #17) > It's 2013. > Everything should be perfect. > xf86-video-savage is fixed in version 2.3.2 upstream, intel driver work. Closing as requested. Feel free to reopen if David missed something.