<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Mar 22, 2017 at 1:24 PM Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class="gmail_msg">
<br class="gmail_msg">
This is an RFC for a new interface to generate input events from arbitrary<br class="gmail_msg">
clients. Note that this is only a few days old, so **do not** assume this is<br class="gmail_msg">
anything more a thought experiment right now. This email is supposed to start a<br class="gmail_msg">
discussion and collection of the various points that need to be addressed.<br class="gmail_msg">
<br class="gmail_msg">
First: why? There are some commandline tools like xdotool that allow for some<br class="gmail_msg">
scripting of desktop interactions. xdotool supports two categories: input<br class="gmail_msg">
device emulation and window management.<br class="gmail_msg">
<br class="gmail_msg">
This RFC primarily addresses the input device emulation bits but there is<br class="gmail_msg">
room for adding window management capabilities. I have a basic repo here:<br class="gmail_msg">
<a href="http://github.com/whot/woodotool" rel="noreferrer" class="gmail_msg" target="_blank">http://github.com/whot/woodotool</a> but it doesn't contain much beyond what's<br class="gmail_msg">
in this email.<br class="gmail_msg">
<br class="gmail_msg">
This will be a discussion of the interface only because the implementations<br class="gmail_msg">
are so specific that there is no real code-sharing beyond the interface<br class="gmail_msg">
itself. I've talked privately to some of you already, the general mood is<br class="gmail_msg">
somewhere around reluctant acceptance.<br class="gmail_msg">
<br class="gmail_msg">
So here's a list of talking points:<br class="gmail_msg">
<br class="gmail_msg">
== DBus ==<br class="gmail_msg">
What we need is basic IPC and not directly Wayland related, DBus provides a<br class="gmail_msg">
bunch of extras over the wayland protocol: introspection, ease of<br class="gmail_msg">
extensibility, bindings, etc. Also, Mir.<br class="gmail_msg">
<br class="gmail_msg">
== Functionality-based interfaces ==<br class="gmail_msg">
We need a mix of capabilities and features, not all of which will/should be<br class="gmail_msg">
available to all clients. Right now, I have two for devices:<br class="gmail_msg">
 org.freedesktop.WoodoTool.Keyboard (Press, Release)<br class="gmail_msg">
 org.freedesktop.WoodoTool.Mouse (Press, Release, MoveRelative, MoveAbsolute)<br class="gmail_msg">
Compositors can implement one, both, either, etc. For future extensions,<br class="gmail_msg">
having a Touch interface, Joystick, or whatever is deemed useful is<br class="gmail_msg">
technically trivial.<br class="gmail_msg">
<br class="gmail_msg">
There's a manager interface too but that's a technical detail, see the repo<br class="gmail_msg">
for more details.<br class="gmail_msg">
<br class="gmail_msg">
== Control of the event stream ==<br class="gmail_msg">
The events are coming in through a custom interface, so it's relatively<br class="gmail_msg">
trivial to ignore events based on context, e.g. ignore fake key events while<br class="gmail_msg">
the screen is locked. Any uinput-based solution would lack this context.<br class="gmail_msg">
<br class="gmail_msg">
== Authentication/Identification ==<br class="gmail_msg">
The goal is to filter clients based on some white/blacklist, so that e.g.<br class="gmail_msg">
xdotool can access this interface but others cannot.<br class="gmail_msg">
<br class="gmail_msg">
This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this reliably.<br class="gmail_msg">
It's trivial to do per user, but per-process is difficult. DBus filters<br class="gmail_msg">
are largely limited to per-users. It's possible to get the process ID of a<br class="gmail_msg">
sender but going beyond that is unreliable (kernel doesn't guarantee comm<br class="gmail_msg">
being accurate).<br class="gmail_msg"></blockquote><div><br></div><div>For Ubuntu, at least, we use the apparmor dbus integration to filter dbus on a pretty granular level. If push came to shove it would presumably be reasonably easy to add an selinux query in the same path to do the same. *waves hands*</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">…<br class="gmail_msg">
<br class="gmail_msg">
== Use for testing ==<br class="gmail_msg">
Came up several times, I'm not yet convinced this is a good compositor testing<br class="gmail_msg">
interface beyond basic input. A good testing interface likely requires<br class="gmail_msg">
something more compositor-specific where more of the window state is made<br class="gmail_msg">
available. But it could work as an interim solution.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Toolkits seem to have pretty usable introspection capabilities - for example, there are lots of automated tests of the Ubuntu Touch devices that use Qt hooks to verify lots of behaviours and need only a way to generate input events and lookup screen coordinates from client coordinates.</div><div><br></div><div>It'll be less useful for testing the compositor itself, though (unless you happen to have written the compositor in an introspectable toolkit).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
== Input coordinate handling ==<br class="gmail_msg">
Keys and mouse buttons are trivial unless we want custom focus (we don't).<br class="gmail_msg">
Relative coordinates are ok too, absolute ones are trickier because they<br class="gmail_msg">
rely on screen layout not available to the client.<br class="gmail_msg">
<br class="gmail_msg">
So the specification needs to include a behaviour we can stick to forever,<br class="gmail_msg">
something like "in pixels as measured from the logical top-left of the<br class="gmail_msg">
top-left-most screen" etc. Not difficult per se, but this stuff is usually<br class="gmail_msg">
prone to corner-case unhappiness.<br class="gmail_msg">
<br class="gmail_msg">
== Input coordinate filtering ==<br class="gmail_msg">
One use-case that was mentioned to me was effectively "intercept button X<br class="gmail_msg">
and send key events 'abc' instead". This is not possible with the current<br class="gmail_msg">
proposal and I'm not sure it can be without going overboard with<br class="gmail_msg">
specifications. It *may* be possible to provide some global hotkey hooks I<br class="gmail_msg">
have not come up with a good solution to that.<br class="gmail_msg">
<br class="gmail_msg">
== Window management ==<br class="gmail_msg">
This is beyond the current suggestion but also where it gets both<br class="gmail_msg">
interesting and difficult.<br class="gmail_msg">
<br class="gmail_msg">
I have a sample org.freedesktop.WoodoTool.Desktop interface that would send<br class="gmail_msg">
Edge signals to clients. The compositor decides when these are triggered,<br class="gmail_msg">
the client can react to these things with custom commmands.<br class="gmail_msg">
<br class="gmail_msg">
But this is where we get into the proper scripting territory and that's also<br class="gmail_msg">
where the opinions will diverge quite quickly.<br class="gmail_msg">
<br class="gmail_msg">
For example, xdotool supports things like "search for window with name 'foo'<br class="gmail_msg">
and activate it". Implementing this is ... tricky. Now we need some<br class="gmail_msg">
definition of what a window classifies as and how windows are sorted within<br class="gmail_msg">
a process - compare multiple GIMP windows with multiple gnome-terminal<br class="gmail_msg">
windows for example. Not specifying exactly what order we return leaves us<br class="gmail_msg">
open to behavioural dependencies which may break in the future.<br class="gmail_msg">
<br class="gmail_msg">
In other words, an interface to search for windows of a given application<br class="gmail_msg">
is technically feasable but extremly hard to get right.<br class="gmail_msg">
<br class="gmail_msg">
Anyway, with the separation of interfaces this is not something we need in<br class="gmail_msg">
the first iterations. But one legitimate question is whether just an<br class="gmail_msg">
implementation for virtual input devices is sufficient or whether it's<br class="gmail_msg">
largely pointless without any additional window-management capabilities.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>I'm *only* interested in the virtual input device support, so an implementation of that is fine for me :).</div></div></div>