On Tue, Sep 20, 2011 at 12:46:57PM +1000, Peter Hutterer wrote: > - elographics is maintained, but Marc hasn't committed to the driver yet. > I know that elographics-1.3.0 crashed on UnInit with server 1.10 until I > fixed it about a month after the release. > I'm currently in a private conversation with a user to get this driver to > work.
I know Marc is using Elographics touch screens and needs a working driver, however he doesn't seem to have updated his development machines. I also have a elographics touch screen. I just need to plug it in to actually test it. (And will do so when switching OpenBSD to server 1.11 + the input drivers updates that are needed) So this driver is going to be a bit more supported than others. But I don't object removing it from build.sh. > - fpit. unmaintained and untested. > - hyperpen. unmaintained and untested > - microtouch. unmaintained and untested > - mutouch. unmaintained and untested > - penmount. unmaintained and mostly untested though we have reports of user > sightings every so often. Jani volunteered to test the driver in April but > that never made it into MAINTAINERS. > - void. maintained and pointless. Agreed. I polled the OpenBSD user list a few month ago, and found no users of any of this hardware. > I've actually tested (and fixed) all of these to work on server 1.10, though > the testing was limited to module loading. Several, despite released, > crashed the server on startup or shutdown. Now, I could continue to spend > time on fixing drivers that I cannot test but that time could be spent on > something more useful. > > Next week, all the above except the big 4 and joystick will be switched to > maintained-on-demand. This simply means: > - those in build.sh will be removed from build.sh > - a configure.ac warning will be added to warn that this driver likely will > not build and is untested. > - their status in MAINTAINERS will be changed to unmaintained > > Alternative course-of-actions is: You sign up as maintainer, test against > recent X server versions and ensure the fixes go into a driver release > within a reasonable time of the X server release. Basically, your driver is > expected to work with the X server from git. > > If you want me to fix the driver, I need you to: > - tell me why the kernel driver isn't good enough (why writing a kernel > driver isn't the better solution), and For the elographics, the reason are) 1. Neither Marc or I are running Linux 2. It's a serial device. on BSD systems we could put the driver in the kernel as a line discipline, but it's not 100% trivial and it isn't clear what the benefits are. > - send me a device so that I can actually test the fixes > > I'll still accept patches for any of the above drivers regardless of > maintainership if someone actually runs them. You just can't expect that > they will build or work against any specific X server version and driver > releases will be even more random than now. > > Of course, if you sign up for maintainer, I'm happy to help you with any > input-related questions. > > Cheers, > Peter > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Matthieu Herrb _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
