When a device has multiple regions, ei_device_pointer_motion_absolute()
would walk all of the regions and bail out if the coordinates are
outside any region.
As a matter of facts, it means that an absolute event must fall within
all the device regions to succeed.
That doesn't seem right, it should be the opposite, the coordinates must
be within at least one region.
Fix the logic by reusing the existing ei_device_in_region() function.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is primarily for namespacing: where a portal sets some properties
it needs to do so *before* the Connect event. By moving this out to a
different namespace we can separate this easier, avoiding a portal
accidentally sending a property event after it has already passed the fd
to the client.
Fixes#23
The same socket is used for pre-connection configuration by a portal and
for the actual client that then uses the data. The portal and the client
may need different protocol versions *and* there may be different REIS
intermediaries.
So let's allow version negotiation for the configuration through
transactions: a REIS intermediary must start/finish a transaction with a
given version number.
This is only partially implemented in libreis right now: each API call
is wrapped in a transaction. Since we support version 1 only anyway,
there's no need to do anything but send our version down the wire. In
the future where we actually need to negotiate, libreis will need a
reis_dispatch() so we can wait for the server version to arrive, parse
it, etc. before sending ConfigureVersion down the wire. It's likely this
will never be needed.
Let the client set the version number it wants on Connect. There is new
public API to query the client/server's version as set once the connect
finished (eis_client_get_version() and ei_get_version()) but there is
currently no public API for the client to select the version it actually
wants, other than whatever both support. IOW, it's not possible for the
client to say "I want version 8 but if that's not supported, use version
5".
Add a new protocol message "GetVersion" and the matching reply from the
server with "Version" that can be sent at any time. The server always
replies with the highest protocol version it supports, allowing the
client to choose the protocol version it wants.
These two messages also have a fixed string to make the protocol easy to
identify in hexdumps.
To avoid roundtrips on connection, libeis immediately sends the Version
message. Ideally and by the time the client actually starts, that
version is already available and we can continue without requiring a
full roundtrip.
This patch only adds the version exchange with the server, it does not
yet add the bits for the client to actually set the version.
Punt this job to the caller, any structured logging handler doesn't need
them anyway and it makes handling of messages more awkward.
For our default log handlers (fprintf) we can just append them
ourselves.
Fixes#19
For all but the simplest loggers, the current approach of "this is a
continuation of the previous message" doesn't work well. The caller
cannot know whether the *current* message is complete until it receives
the next message - but that message may never come.
Drop this approach, if we need to compile multiple messages into one,
we can handle this internally and then pass it all as one message to the
caller.
The demo client has an inner while loop for the events, followed by
the code to send events to the server. Skip that code if our while loop
indicated we'll stop.
The basic set of functions and macros to have access to a libreis
context for our to-be-client.
Since we connect the ei context to a backend during peck_new(), we need
a new function for the case where we do want to have libreis in the
mix.
All we do here is decide whether the connect event gets handled, clients
are always effectively connected (i.e. the client does send the connect
request) since we set up the backend during init.
This silently ignores any bit higher than the target storage (e.g.
flag_set(some_uint32, 33)) but that's still better than silently writing
into random memory.
Add a c file for util-bits.h as well - only contains the tests but at
least that way those are picked up like all other util tests.
If a REIS implementation sends multiple ConfigureCapabilities messages,
the allowed capabilities would be whichever ones were sent last rather
than the intersection of all capablities.
Fallout from 7fc9498f1d.
There's a very limited use for configure messages after client
connection. The name is already static after connect anyway, and
the ability to drop capabilities after connect would just complicate the
EIS implementations unnecessary.
Xwayland is not a compositor, it's a Wayland client.
Also fix a few typos while at it (XWayland -> Xwayland).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Incoming device events are now added to a device-internal queue. Once
the frame event comes in, that queue is shuffled over to the main event
queue. For libei/the EIS implementation this means that device events
are seen only once the frame event appears from the sender (or it is
emulated by other means).
Currently only implemented for frame events, the vague plan for the
future is to merely queue the device events internally and "release"
them once a frame event was received, retrofitting the timestamp to the
C event struct (i.e. making ei_event_get_time() available on all device
events).
Meanwhile, the frame event it is.
Where the sender sends empty frame events, or a device event without a
subsequent frame events ensure that event is filtered or emulated in our
event queue.
Note: because of our sender filters, we cannot actually test
this, at least not easily. Let's hope it works.
