Input driver on 1.15.1 vs. 1.19.6

[Peter Hutterer]

On 12/10/19 10:43 , Software Orchestration wrote:
>   On Friday, October 11, 2019, 3:33:52 PM PDT, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> 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.
> 
> It might work by working on the code, I do get a valid shared library that seems to load, but it is pretty ugly how it is and will take some time to get it working, IMO. I'm not clear on how much exactly, but it would be better to create a new one. This is a point of sale devices, and really doesn't need to do too much. AFAIK, all the other devices are USB touchscreens. This one is a serial.
> 
>> 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.
> 
> That answers about the polling, I didn't think I needed to do that like a USB driver.
> 
> I've abandoned using the synaptics driver, it doesn't do too much for me other than call the serial. I think I've narrowed a start to:
> 
>   xf86-input-void - https://gitlab.freedesktop.org/xorg/driver/xf86-input-void
> 
> or
> 
> xf86-input-evdev -  https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev
> 
> I do have my device listed in /proc/bus/devices and it points me to the event, and I checked and see the kernel has the needed CONFIG_INPUT_EVDEV, and that would make me lean towards the xf86-input-evdev sources as a start, which I think they were intended to be.

if your device has a /dev/input/eventX node anyway, then yes, evdev is 
the way to go. You may  not need any modification at all, evdev may do 
the trick.

>> and an early-enough version doesn't have the fancy
>> bits the current driver has to split into subdevices etc.
> 
> When you say subdevices, in the evdev it has a middle button, third button, wheel, etc...is that what you're saying to avoid? Or are you talking about a keyboard, mouse, touchscreen type driver? (if such exists, I think it does)

the X server isn't great at handling devices that are both mouse and 
keyboard, so we end up splitting those evdev devices into two X devices, 
one for the keyboard events and one for the pointer events. That's what 
the "subdevices" term refers to in the libinput driver. For a device 
that's a touchscreen only you don't need to care about that.

Cheers,
   Peter

> Thanks for your help.
> Alan
>