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

Michael macallan1888 at
Sat Sep 17 18:20:59 PDT 2011


On Sat, 17 Sep 2011 16:55:47 +0100
Daniel Stone <daniel at> wrote:

> Hi,
> On 17 September 2011 02:36, Michael <macallan1888 at> wrote:
> > On Fri, 16 Sep 2011 21:13:10 -0400
> > Matt Turner <mattst88 at> wrote:
> >> 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.
> >
> > We ( as in NetBSD ) already keep a bunch of patches to a bunch of drivers namely:
> > - chips. Put back basic ISA/VL support back so it can run on NetBSD/shark. It's also used in some old PowerBooks which some people still find useful ( that's PCI though )
> > - we keep mach64, r128 and old radeon support going because they were used in lots of Suns and Power Macs
> > - we have feature updates and fixes for almost all SBus and UPA drivers ( yes we run Xorg on almost everything )
> > - we use wsfb instead of vesa wherever we have a mappable framebuffer
> Any chance of seeing these patches sent and committed upstream?

Sure, I'll get there eventually ;)
There are some new drivers too ( for old hardware though ) which for now are kinda NetBSD-specific ( I made no real attempt to keep them OS-independent since I didn't think anyone else would want them - the NetBSD-specific part is only about /dev/whatever and mmap offsets so that would be trivial to port should anyone want to do that )
- xf86-video-crime, for the SGI O2. Register and DMA buffer mapping is NetBSD-specific and stuff like mode switching is done by the kernel driver, should be easy enough to port. The biggest 'challenge' ( if you can call it that ) on Linux would be the fact that this driver expects the framebuffer in tiled mode while Linux' kernel driver uses a trick to make it appear linear ( which the drawing engine can't deal with ). Since we use the drawing engine in the kernel as well it's always tiled and I threw out the linear hack long ago.
- xf86-video-ag10e, for the Fujitsu AG-10e SBus monster. More or less a glint, an i128 and a Weitek P9100 behind an SBus-PCI bridge, glued together with an IBM 561 RAMDAC. This driver talks to the glint. Kinda obscure and hard to get but one of the few accelerated 24bit SBus cards that won't melt the case.
- xf86-video-igs, for IGS CyberPro 20x0, written for NetBSD/shark so it only supports the VL variant. Adding support for the PCI variant should be trivial. There's a bunch of sharks floating around ( they're small StrongARM-based network computers, technically all prototypes but DIGITAL made tons of them ), Linux has been ported long ago - no idea if anyone's still running linux on them. I use mine as Xserver debugging aid ( read: second head with keyboard and such that just needs to be plugged in, is silent and can run a bunch of xterms and editors )
Question is, would it make sense to have any of these on The crime driver would probably draw a little bit of interest, not so sure about the others.

have fun

More information about the xorg-devel mailing list