input driver maintainance changes
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
>> I know Marc is using Elographics touch screens and needs a working
>> driver, however he doesn't seem to have updated his development
> 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.
> 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.
>>> 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