On 12/10/19 10:43 , Software Orchestration wrote:
On Friday, October 11, 2019, 3:33:52 PM PDT, Peter Hutterer
<peter.hutte...@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
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
