drivers to de-support (was: [PATCH 2/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires)

[Matt Turner]

On Fri, Sep 16, 2011 at 7:53 PM, Alan Coopersmith
<alan.coopersmith at oracle.com> wrote:
> On 09/16/11 01:54, Jeremy Huddleston wrote:
>>
>> On Sep 15, 2011, at 8:31 AM, Gaetan Nadon wrote:
>>
>>> A bonus would be a list of drivers that do use pciaccess (maybe not in
>>> the commit text!). A complete list of drivers can be found in build.sh.
>>
>> Here's a complete list of modules which didn't contain the links *BEFORE*
>> my change:
>>
>> ./drivers/chips_drv.so: needs_pciaccess=1
>> ./drivers/chips_drv.so: needs_pixman=1
>> ./drivers/cirrus_alpine.so: needs_pciaccess=1
>> ./drivers/cirrus_drv.so: needs_pciaccess=1
>> ./drivers/glint_drv.so: needs_pciaccess=1
>> ./drivers/glint_drv.so: needs_pixman=1
>> ./drivers/i128_drv.so: needs_pciaccess=1
>> ./drivers/intel_drv.so: needs_pixman=1
>> ./drivers/mach64_drv.so: needs_pciaccess=1
>> ./drivers/mach64_drv.so: needs_pixman=1
>> ./drivers/mga_drv.so: needs_pciaccess=1
>> ./drivers/mga_drv.so: needs_pixman=1
>> ./drivers/neomagic_drv.so: needs_pciaccess=1
>> ./drivers/neomagic_drv.so: needs_pixman=1
>> ./drivers/nouveau_drv.so: needs_pixman=1
>> ./drivers/nv_drv.so: needs_pciaccess=1
>> ./drivers/nv_drv.so: needs_pixman=1
>> ./drivers/openchrome_drv.so: needs_pciaccess=1
>> ./drivers/openchrome_drv.so: needs_pixman=1
>> ./drivers/r128_drv.so: needs_pciaccess=1
>> ./drivers/r128_drv.so: needs_pixman=1
>> ./drivers/r300_drv.so: needs_pixman=1
>> ./drivers/rendition_drv.so: needs_pciaccess=1
>> ./drivers/savage_drv.so: needs_pciaccess=1
>> ./drivers/savage_drv.so: needs_pixman=1
>> ./drivers/sis_drv.so: needs_pciaccess=1
>> ./drivers/sis_drv.so: needs_pixman=1
>> ./drivers/sunleo_drv.so: needs_pixman=1
>> ./drivers/tdfx_drv.so: needs_pciaccess=1
>> ./drivers/tdfx_drv.so: needs_pixman=1
>> ./drivers/tga_drv.so: needs_pciaccess=1
>> ./drivers/trident_drv.so: needs_pciaccess=1
>> ./drivers/trident_drv.so: needs_pixman=1
>> ./drivers/tseng_drv.so: needs_pciaccess=1
>> ./drivers/vesa_drv.so: needs_pciaccess=1
>> ./drivers/vmwlegacy_drv.so: needs_pciaccess=1
>> ./drivers/vmwlegacy_drv.so: needs_pixman=1
>> ./drivers/voodoo_drv.so: needs_pciaccess=1
>> ./drivers/xgi_drv.so: needs_pciaccess=1
>> ./drivers/xgi_drv.so: needs_pixman=1
>> ./drivers/xgixp_drv.so: needs_pciaccess=1
>> ./drivers/xgixp_drv.so: needs_pixman=1
>
> Which goes back to another question raised at XDC - is it time to start
> dropping support for video drivers the way we have for input drivers?
>
> rendition is one of my favorite examples there - it's so old that
> Windows support isn't available for anything newer than Windows 98.
>
> Since Solaris 11 dropped 32-bit CPU support and is going 64-bit only,
> the list of video drivers we'll be shipping shrunk dramatically, based
> on those we expected to see in x64 systems, and is just:
>
> xf86-video-ast         xf86-video-mach64      xf86-video-trident
> xf86-video-ati         xf86-video-mga         xf86-video-vesa
> xf86-video-cirrus      xf86-video-nv          xf86-video-vmware
> xf86-video-dummy       xf86-video-openchrome
> xf86-video-intel       xf86-video-r128
>
> Besides the obvious ones, Cirrus survived mainly for the emulated forms in
> qemu & similar virtualization, Trident because Sun shipped one on board in
> one of our early AMD64 servers (the Sun Fire V20z), Matrox because of the
> number of server/blade systems using service processors such as those from
> Emulex with G200SE & similar graphics.   I don't actually have a good reason
> why "nv" survived since we ship the nvidia proprietary driver.
>
> On the sparc side, we just ship ast & ati, since that's all that's supported
> in
> the SPARC server models that Solaris 11 officially supports.

I think we should simply maintain the drivers we care about. I'll try
to keep -glint going. For other drivers without any sort of
maintainer, I don't think anything really changes from what's going on
now.

For a rather small (but perhaps still too large) amount of effort, we
could write basic KMS drivers. Given that none of these drivers have
3D components anymore, and for the most part don't offer very much
acceleration, with a basic KMS driver the DDXs could be gutted.

Could we have a single DDX (-modesetting, or -fbdev?) that would just
allow X to run on top of the KMS drivers? Is there some way with a
single driver like this that we could still have any acceleration for
things like Xv across different underlying KMS drivers?

Thanks, and sorry for diverting the topic a bit.

Matt