input driver maintainance changes

Peter Hutterer peter.hutterer at who-t.net
Tue Sep 20 03:21:37 PDT 2011


On 20/09/11 18:37 , Marc Balmer wrote:
>
> 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.

IMO developing on BSD is fine. The drivers are supposed to be 
cross-platform anyway and chances are that the code you're working on 
won't break anything on Linux.

I'll just add you as maintainer to the MAINTAINERS file, ok?

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

The input API doesn't change that often. I'd certainly appreciate it if 
you could test changes within a reasonable timeframe. The build scripts 
these days are pretty good, it's not hard to get a server from git up 
and running. I'll of course still fix the driver whenever I break the 
API, so I'd mostly need you to test and fix those issues that I miss 
when compile-testing only.

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

good enough reason for me.

Cheers,
   Peter

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



More information about the xorg-devel mailing list