Input driver on 1.15.1 vs. 1.19.6

[Peter Hutterer]

On 11/10/19 20:29 , Software Orchestration wrote:
>     On Thursday, October 10, 2019, 9:35:47 PM PDT, Peter Hutterer <peter.hutterer at who-t.net> wrote: > I'd argue that any input driver that worked in the past should still work
>> with current X servers, provided that you switch the SIGIO bits over to
>> handle input threads instead.
>>
>> There are very few features that have truly been removed from input drivers> such as access to the screen dimensions etc. Can't remember when this happen
>> but my gut feeling is that if it worked on 1.15 it'll probably work on
>> 1.19.
> 
> Peter,
> 
> Yes, I kind of was thinking that last night, or at least that this should actually work. AlanC pointed out that those functions haven't changed much. One thing I had to do in order to compile the code on Ubuntu 18.04 was add an include for <bits/types/sigset_t.h> as it was giving me a redefinition in one of the libraries called from xf86Xinput.h. If you could elaborate a tad I would appreciate it.

the headers may have shuffled things around a bit - without knowing your 
source code I can't really comment on what has changed for you. but I 
don't expect there to be anything that's not resolved by including some 
standard headers.

> In regard to what you mention with switching over to an input thread, will that let me register a callback that Xorg will send back for all the input events? And then I could just r/w the serial through the xf86 calls?

drivers register a file descriptor that is added to the server's 
internal poll() call. When data is available, your callback is invoked 
and you can process data. For the most part you don't really need to 
care about the input thread within the driver, it's largely handled by 
the server anyway.

> Also, the old style with the SIGIO, it exported the init routine. I haven't dug into the code too much, other than getting it to compile. The old driver was 32-bit, and 32-bit is not supported on Ubuntu 18.04 moving forward. Old X, 32-bit, old hardware, etc...this is not a glamorous project.
> 
> This weekend I'm going to try and decide, use what is there, or just write a new input module. This one is pretty ugly and there's a lot of #ifdefs for old versions. I am still not clear when Xorg 4.x switched over, possibly 2005 or so? Are these defines for XFREE86_V3 and XFREE86_V4 older than Xorg 4? Was that the old XFree86?

yeah, you don't need any of those for newer servers.

> I looked through those input drivers that AlanC pointed to and the synaptics uses the xf86ReadSerial() and xf86WriteSerial(). I just need a simple module that will stuff the touch to the mouse.
> 
> I'm ok with re-writing, and my client is ok with that also (as long as it doesn't take too long), but I need to decide pretty quickly if that is the best way to approach this.
> The previous driver was morphed from the wacom driver. I would guess because it was as close to the serial driver they needed. So the code is ugly and creating a new input module could be worth it. Especially if this will take the client to 1.20, or if it will continue working for the client on Ubuntu 20.04. Although that is not a requirement for me, that would give them another 5 years from next April for 20.04 to end support.
> 
> I'll look through those input drivers AlanC pointed to and see if I see an example using input threads.

look at early versions of the xf86-input-libinput driver. that's the 
most modern code base and an early-enough version doesn't have the fancy 
bits the current driver has to split into subdevices etc. You can 
probably take that code and replace the read callback with your 
device-specific data and you're good to go. -ish :)

There's no documentation that's up to date, writing xorg input drivers 
simply isn't a thing anymore and the one person who still does that on a 
regular basis already know how it works ;)

Cheers,
   Peter

> Thanks for your reply.
> Alan (and sorry this stupid yahoo mail sent HTML to the list, I changed that, I hope)
>    
>