The iobuf treats this as binary data but then we're using it as strings in the
message parsing code. So make sure all messages have a trailing null byte.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better than the current "myclient". Lacks safety and whatnot so long-term it
will have to get replaced with something else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the minimum framework to support connecting to a libeis server, adding
a device and sending relative pointer motion events.It's missing a bunch of
checks and verifications, many of the hooks are still missing, etc.
See the tools/ directory for an example. The protocol is as outlined in
commit f7a24b2fbd.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Aparently the compiler is not smart enough to handle the case correctly where
a cleanup variable is introduced after a goto statement.
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>
This allows for some negotiation - server sends hello with some magic auth
data, client sends connect with the reply to the hello. Not sure yet how or
whether this makes sense, but at least it makes testing easy.
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>
Split into a _new() call and make the others setters, with a bit more
explanation of what the server does.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
