Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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.
Comment by Andreas Radke (AndyRTR) - Saturday, 30 June 2012, 08:55 GMT
One basic question at the beginning:

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.
Comment by Connor Behan (connorbehan) - Saturday, 30 June 2012, 20:33 GMT
My personal use for DRI1 is to run Xscreensaver hacks at native speed.

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.

Loading...