Same as already done for libei. There's relatively little benefit here since
we won't have a lot of different events and any caller will do the switch
based on the event type anyway. So let's just export a single event type and
have everything contained in that.
Since this required rewriting all getters, let's move the lot to a new file
and streamline things a bit that way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Original idea of 1/1000 of a pixel was to allow subpixels while sending fixed
width down the wire. Let's not care about that and use doubles instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Motivation for peek is the same as for libei - the upcoming test suite needs
to check a few things before actually dequeuing the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the backend is more of an implementation detail, namespace for
eis_setup_backend_foo()
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main reason for having different functions to create the initial context
was so we can nest the eis struct inside the context-specific struct. That
shouldn't leak into the API though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the minimum framework to support new clients, added devices and
pointer relative motion events. It's missing a bunch of checks and
verification, most of the server hooks aren't there yet, the only
implementation is a UNIX socket and the protocol is plain text (but at least
the last two makes it netcat-compatible).
Protocol is plain text for now and interaction is like this (S is server, C is client):
S: hello
C: connect myclientname
S: connected
C: add 2 4
S: accept 2
C: rel 2 -1 1
C: rel 2 5 4
Where the last two lines are: add device with id 2 and capability mask 0x4,
send a relative pointer motion event for device 2 with coordinates -1/1, then
5/4.
The implementation relies heavily on some abstraction and macros galore, see
the various util-* files. These are largely copied from libinput, with a few
parts removed and a few other parts added.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
keymap handling is difficult because a lot of it relies on specific server
implementation details. So let's provide the API for a client to assign a
specific keymap to the device and for the server to accept/refuse/override
that keymap.
Where the server refuses, it's up to the client to figure out the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The use-case of suspending individual capabilities is niche - where a client
needs to rely on this it should create multiple devices with different
capabilities so they can be suspended separately.
Also clarify that the server *must* process events even from a suspended
device. This works around a race condition where a client has sent several
events already before the suspend comes in - it has to assume that any event
sent before the server event is handled updates the state in the server.
Implementation-wise, libei will start filting events once ei_dispatch()
returned the suspend event to the client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only allow changing or querying for a single capability at a time.
More verbose but less ambiguous and it removes any bugs resulting from bitmask
errors. There is no supported use-case where the server *adds* a
capability to a client-requested device, so has_capability and
disable_capability is enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We assume that any libei client has access to the windowing system through
other means (at least where it matters) so they can set up the pointer range
accordingly. This also allows the server to do heuristics on monitor mapping,
similar to what we have for Wacom tablets already.
And forcing the ranges to be constant means the race conditions are halved,
only the client is now affected by a potential race condition between the
screen size changing and the pointer ranges needing updates. Those can be
mitigated by the server though, e.g. an input device that maps to a
single-monitor *should* still be mapped to that same monitor after another
monitor is plugged in (and this should apply before the client is notified of
the screen mapping). So the client events in transit will still go to the
right position of the screen (though admittedly the target areas may have
migrated to the new screen so the click now goes wrong anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
