input driver maintainance changes

[Marc Balmer]

Hello guys!

> 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. 

Indeed that is my problem at the moment.  I have many elographics touchscreens here, serial, USB, whatever from very different brands (ELO itself, IBM, etc.).  As I am a BSD developer mostly, I have the same problem as Matthieu probably has:  The BSDs always are a bit behind, to say the least.  But I have no problem installing and using a Linux machine for this purpose, but I would need a recommendation about which Linux I should go for.

> 
> 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

As mentioned above, that could be arranged, though of course I prefer to work on BSD.

> 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. 

I have written a lot of line disciplines, I know this part quite well.  But I think we need to find a successor to tty line disciplines (FreeBSD, e.g, removed them completely).  Since elographics are serial devices, the input driver is still needed atm.

> 
>> - 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


- Marc