FS#30464 - [xf86-video-*] Support for DRI1 should not be explicitly disabled
Attached to Project:
Arch Linux
Opened by Connor Behan (connorbehan) - Wednesday, 27 June 2012, 19:27 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 01 July 2012, 08:08 GMT
Opened by Connor Behan (connorbehan) - Wednesday, 27 June 2012, 19:27 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 01 July 2012, 08:08 GMT
|
Details
Description: This is a meta issue requesting that
"--disable-dri" be removed from the configure / autogen
flags in DDX drivers for old hardware. It is not necessary
to replace it with "--enable-dri" since this is the default
anyway.
1. DRI1 was explicitly disabled when mesa dropped support for the old video cards upstream. The DRI1 drivers are now in [community] under my maintainership (you will not get bug reports for them, I will) so in the interest of people who want to use these packages, it is best to stop disabling DRI. 2. This does not introduce ANY additional run-time or build-time dependencies. The DDX will still only link to glibc. DRI1 support will be dlopen'd so the package maintainers and package users will be still be perfectly fine if they do not install the DRI1 drivers in [community]. Affected packages: * xf86-video-mach64 6.9.1-1 * xf86-video-mga 1.5.0-1 * xf86-video-r128 6.8.2-1 * xf86-video-savage 2.3.4-1 * xf86-video-sis 0.10.4-1 * xf86-video-sisimedia 0.9.1-3 * xf86-video-tdfx 1.4.4-1 |
This task depends upon
Closed by Andreas Radke (AndyRTR)
Sunday, 01 July 2012, 08:08 GMT
Reason for closing: Implemented
Additional comments about closing: please ping me if something needs further changes and pray it keeps working for a long time.
Sunday, 01 July 2012, 08:08 GMT
Reason for closing: Implemented
Additional comments about closing: please ping me if something needs further changes and pray it keeps working for a long time.
Why would someone want to have the DRI1 3D features with such ancient cards? They should be way too slow for any serious modern desktop effects or even games.
Sure we can workaround upstream decission. But prove me first it's worth the work.
There's two ways to go if you want to implement this. Either build one pkg with optional dep on the DRI1 pkg
or we stay in extra repo the upstream way and you provide full xf86-video-foo-dri1 additionally in community your own conflicting/providing the one in extra repo.
Way1 example with mach64:
This requires the following change in our PKGBUILD:
makedepends=('xorg-server-devel>=1.12.0' 'libdrm' 'xf86driproto' 'mesa=7.11.2')
and removing the --disable-dri switch
Right now your mesa 7.11 pkg doens't provide the main mesa pkg. Only the DRI1 stuff. I can't build against the old mesa headers. It would build against
new mesa 8.0 right now but might break stuff or will do in the future. Even if you would add full old mesa packages generally it's not recommended to build packages in the extra repo against
(make)deps of the community repo.
I suggest you go the 2nd way to build your own full driver packages in community repo not touching upstream decission I'm responsible for in extra.
I would agree with you that the (non-Arch-way) xf86-video-*-dri in [community] would be preferable if the drivers required mesa 7.11.2 headers, but they don't. I just built xf86-video-mach64 with --enable-dri and mesa 8.0.3 instealled. Try it.
I suggest that you remove the --disable-dri switch for now and restore it if a future build ever fails. Dave Airlie said that it won't because the DDX <=> libGL interface is stable. Note that xf86-video-unichrome and xf86-video-openchrome in [extra] are already doing this.