We can remove those when we have a working implementation, for now it's too
painful to debug when an exchange doesn't work for some reason.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For the Portal case, we'll have the portal open the sockets for us and then
(depending on policy) restrict what the client can do. Then the socket can be
passed to the client with e.g. keyboards disabled and the client is none the
wiser (other than that the server will reject any keyboard caps).
Since the portal doesn't need a EI context, the configuration is a separate
small library.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main purpose of that was for (plain-text protocol) debugging. With the
current intentions to "preload" a connection with restrictions, having the
server initiate a connection is not useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more explicit API that makes it more obvious where the ref/unref
calls need to go. The sink now has two refs to the sources as well (epoll data
pointer and the list) which means a caller cannot just source_unref() anymore
without removing a source. Since this is how we've been using it anyway - meh.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let the context take care of adding the device so we have better separation
here. Removal isn't handled in a special way because any list node can remove
itself safel anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
protobuf relies on external framing and exact buffer lengths to parse things
correctly. So let's provide that by sending a fixed-length Frame message
before every real message.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're in a library here, so expecting the caller to handle SIGPIPE just in
case we get it is a bit demanding. Let's use send() instead so we can just
prevent that altogether.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We may get more than one message per dispatch so let's make sure we iterate
through all the available data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plain-text was useful for the initial implementation where the counterpart was
netcat but now that both parts are in place, protobuf is a much more
convenient system to handle a frequently-changing protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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>
