[Wayland-bugs] [Bug 99800] Some way to inject automated libinput events?

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99800

--- Comment #3 from rhendric <ryan.hendrickson at alum.mit.edu> ---
So libinput is a hardware abstraction layer, yes, and an automation source
isn't hardware. But as an abstraction layer, libinput owns those abstractions.
libinput defines what it means to be a LIBINPUT_EVENT_POINTER_AXIS, and why
that's not the same thing as an evdev REL_WHEEL or REL_HWHEEL. You might be
saying that you want libinput's interface to be effectively promoted to a
standard, so that non-libinput producers like, say, libautomation, can produce
the same events and compositors can reasonably be expected to combine the two.
But it seems to me like a bad technical solution to have a producer of
LIBINPUT_EVENT_POINTER_AXIS events and a producer of
LIBAUTOMATION_EVENT_POINTER_AXIS events and for mutual clients to be forever
anxious about or adapting to divergences between them--am I misinterpreting
your proposal?

If instead, you permit libinput's purpose to be taking diverse *input sources*
and processing them into a known set of events, it looks like the right place
to inject additional LIBINPUT_EVENT_POINTER_AXISes--yes, because all users
would get them, but also because there would be a single source of libinput
events from the perspective of the compositor, which keeps the burden of
writing compositors low, which I thought was one of the goals.

Unless, of course, you also want to make the argument that this functionality
isn't part of the core set of what users expect from a graphical desktop
environment, and that's why you want me to convince each individual compositor
to include it instead of bundling it with libinput. If that's your position,
then I don't know--sure, it isn't necessary, but with all the xdotools and
ldtps and whatever other automation tools and frameworks exist for X out there,
it seems like people want to use them, which means that if Wayland compositors
are going to take over from X, they're going to want to have a way to do that
sort of thing too... which they can implement themselves, or get from libinput.

---

Since you didn't insta-WONTFIX this (thanks!), I'll ask some technical
questions too, just in case the above sways you a little. :-)

Thanks for your comments about the backends; I agree, adding a new backend
doesn't sound like it would help. It's not quite as clear to me why creating a
new device would be messy--to the one issue you pointed out, it looks like
libinput_device_get_udev_device is already permitted to return NULL for some
devices, so are there other reasons why creating a non-udev-backed automation
device wouldn't play well with things?

About libinput events not being good enough: why would GUI testing/automation
tools have to use relative pointer events? Isn't
LIBINPUT_EVENT_POINTER_MOTION_ABSOLUTE available, or does that not work for
some reason? (For my personal needs, evdev is too low-level for the very
specific reason that I want to generate fractional POINTER_AXIS events, not
integral REL_WHEEL events, and I definitely don't want to do it by emitting a
string of ABS_MT_POSITION_Y and ABS_PRESSURE and whatever else I'd have to
provide to spoof libinput into just giving me the POINTER_AXIS I want.
Otherwise, it's fine.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170214/3f2af31e/attachment.html>