input driver maintainance changes
marc at msys.ch
Tue Sep 20 01:37:52 PDT 2011
> 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.
> 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.
>> 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
More information about the xorg-devel