This is required for supporting synergy/barrier and similar clients.
Replacing the touch and pointer range we now have server-defined
rectangular regions that specify the active zones for this device.
For example, a dual-monitor EIS server would create two touch devices
with one region each for the respective monitors - libei-generated
touches would thus fall on the right area of the monitor. Or just one
device with one region if the second screen should be inaccessible.
A relative device may have multiple regions since it can reach all
screens in the layout.
This leaks the screen layout to libei but that is necessary for the
functionality to work. A libei client may need to control devices
through absolute coordinates and it needs to know where screen
transitions from one to the next screen happen:
+-----------++----------------+
| || |
| B||Q |
| |+----------------+
| |
| A|P
+-----------+
In the above example, position P is unreachable and a client that
controls input on both screens must know that it cannot transition from
A to P but it can transition from B to Q.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is useful for debugging, let's pass it through and let the log
handler decide whether to use it or not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This changes the protocol so that it is the EIS implementation that
creates devices within a seat.
A client now "binds" to a seat and the EIS implementation creates
devices matching the requested capabilities. A client can close a device
if it no longer wants those but otherwise everything (including pointer
ranges) is handled by the server.
This is one giant patch because changes at the protocol level cannot
easily be broken out into smaller patches. Some FIXMEs are left which
will be handled in follow-up patches, e.g. the keymap handling is
basically broken right now.
Fixes#7
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After CONNECT, the EIS implementation needs to add one or more seats. The
libei client can only create devices within those seats. This mirrors the
wayland hierarchy as well as the X.Org one.
The seat has a set of allowed capabilities, so the client knows ahead of time
when it may not be possible to create a specific device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Build the doxygen API documentation. This is copied from libinput so it takes
over that style (which is more readable than the default doxygen style).
Some extra documentation is added too and all the immediate errors are fixed
in this commit but doxygen still warns about undocumented parameters.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Client-side the approach is a managed touch object rather than passing the
touchid around. This is intentional, it allows for a stackable API in the
future if we need to add things like pressure or major/minor to it.
On the server side the touches are managed through the event object anyway, so
we don't need the same abstraction there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The original idea here was that a libei client could request the Pointer
capability to be notified of any pointer movements, thus providing a simple
way to capture input for the synergy use-case.
This is a can of worms better left untouched. How input events are captured
and what information is available is quite specific to the display server, let
alone the triggers for when it needs to start and stop. To have that in libei
requires something like triggers ("start when pointer hits the edge") which
again opens a new can of worms. Which seat are we referring to? What is a
screen edge? How about shortcuts?
Receiving input events can be handled by libeis anyway: any EIS server is
capable of receiving input events by definition so the capability monitoring
could be solved by making the capturing compositor a libei client and the
other process an EIS server. i.e. the circle is closed with:
[compositor|libei] -> [EIS|synergy-client]
||
[synergy-server|libei] -> [EIS|compositor]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because events may be in-transit when a client removes the device, we need to
make this a full roundtrip to the server. Otherwise the client may assume a
device is removed, releases all references and then gets the original device
added event for that device. Better to have this as a round-trip instead.
This requires the server to call eis_device_disconnect() on the removed
notifications but we do so during eis_event_unref() anyway in case the server
forgets.
And it changes some of the API behaviors, so adjust the tests for that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous approach would implicitly allow any capability not known to the
server. Switch instead to requiring an explicit 'ok' for any capability the
server wants to support.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Naming scheme is now: ei_device_<capability>_get/set_<what>. So far the
range is the only one where we had to deal with the same thing for two
different capabilities and it's unlikely we'll have to have different keymaps
for different capabilities. But still, let's do this now while it's still
easy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The logger utilities are useful for quick prototyping, but we've reached the
point where we need the "proper" implementation of a log handler.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were added originally to illustrate how the diffent backends could work
but they're not going to be implemented this way anyway. So let's just drop
them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
