<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> <span class="fn">Peter Hutterer</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - Some way to inject automated libinput events?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99800">bug 99800</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>peter.hutterer@who-t.net
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Some way to inject automated libinput events?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99800#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Some way to inject automated libinput events?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=99800">bug 99800</a>
from <span class="vcard"><a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> <span class="fn">Peter Hutterer</span></a>
</span></b>
<pre>libinput already has two backends (udev and path-name based), adding other
backends is relatively trivial. But the design of libinput is not well-suited
to having *additional* backends. So while it would be easy to write a backend
that reads events from e.g. dbus and forwards them as libinput events, it
wouldn't be trivial to have this in addition to the udev/path backends. That
causes another problem: it's the caller that decides which backend to use
(compositors use the udev one, xorg uses the path one), so adding a new
independent backend wouldn't get you very far.
To get this working, you'd need libinput to handle your event source as a new
device, but that again doesn't necessarily play with other bits (e.g. no
udev_device would exist for that).
So much for the technical bits. Doable but messy and the non-messy approach
wouldn't help much.
But really, libinput strikes me as the wrong layer to implement this anyway.
libinput's purpose is to take diverse hardware and process it into a known set
of events that are directly usable. in the automation/gui testing case you
don't need this, and in the joystick case you have something else doing that.
So libinput would just be a router for existing events - you don't need
libinput for that [1]
For GUI testing at least I can tell you that libinput events aren't good enough
anyway. Relative pointer events are notoriously state-dependent, making proper
GUI testing almost impossible. Same likely goes for automation - if evdev is
too low-level/unpredictable then libinput events suffer from the same issue
here.
So the best solution to approach this would be to write some sort of external
daemon (dbus, most likely) that makes the events available and provides enough
information for a caller to hook onto the right bits when needed. e.g. a GUI
testing interface should only be listened to when testing. Get that working,
then get the compositors to listen to that interface and DTRT with the events.
Yes, that's a lot of work, but with a long-term view that's the right technical
solution.
[1] yeah, I know, getting it into libinput would make it available in all users
of libinput, but that's not a good technical justification.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>