input driver maintainance changes

[Matthieu Herrb]

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
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel

-- 
Matthieu Herrb