We don't control compiler warnings in that project and currently we
always get one, so let's not prevent werror from working.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The test suite makes a lot of use of this pattern:
_unref_(ei_event) *ev = peck_ei_event(....)
Most of the work is done in the peck function, with the caller just
needing cleanup. Unfortunately clang sees this as unused variable and
insists on warning about all of them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks pretty const to me but compiler authors presumably have a
different interpretation.
../src/libei-log.c:52:34: error: initializer element is not a compile-time constant
static const char *reset_code = ansi_colorcode[RESET];
^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get EPROTO or EINVAL on the connection, all we do is disconnect
(ourselves or the client). So let's drain the fd so there's no other
data to be parsed by accident and then continue with actually
disconnecting.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We will need eis_device_foo() for the actual event API soon, so let's
move the internal handlers out of the way by namespacing them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previous sequence reproducible with the eis-demo-server and
ei-demo-client:
- ctrl+c the client
- eis client dispatch fails with an rc < 0 due to the socket being closed
- eis calls eis_client_disconnect() which calls eis_seat_removed()
- that triggers an event for `SEAT_UNBIND`
- seat is set to REMOVE
- eis-demo-server gets the `SEAT_UNBIND` event and (correctly) calls
eis_seat_remove() since it doesn't know the client is disconnected
yet. That is due to the library unwinding the state transparently.
Fix this by splitting out the calls: eis_drop_seat() is the internally
used one that sets it to a new state of REMOVED_INTERNALLY, and then
eis_seat_remove merely updates the state.
Fixes#10
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prevents any ABI suprprises by the enums being expanded to long or
shortened to char on special targets.
Fixes#11
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These aren't actually used here but it provides an easier-to-understand
example for what the current portal interface is.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's not force users/developers to dig through the commit log to figure
out what each tool does.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The latest version of the portal communication adds session capabilities
and wraps the calls a bit differently.
This now also includes a helper tool for the impl.portal part so we can
run xdg-desktop-portal against that without the need for a mutter
implementation.
Use:
- run the eis-demo-server
- run the eis-fake-impl-portal
- run the xdg-desktop-portal (it'll use the fake impl portal)
- run an ei client with the portal enabled
Note that the ei-fake-portal is a shortcut, it will open eis directly
without going through the impl.portal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the case of a refused portal connection we get disconnected before we
had a chance to send the CONNECT message. This still needs to queue a
disconnect event and thus bubble back up to the caller.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have libreis setting properties on the connection, this looks to
the server like they're coming from the ei connection. But libreis is a
different context than the libei context later, so when libei
initializes, it may set the same properties again. Since the libei
context doesn't know about the properties, it can't filter internally
and will send the properties to the server.
So we need to do all the permissions checks in the server to make sure
we don't overwrite values that we're not allowed to overwrite.
There are no real restrictions on changing properties from within the
eis implementation (other than not being able to set the reserved
namespaces).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Pass the fd into the original context creation, then write any changes
to the wire immediately. For the capabilities that means we can't build
them up as before anymore, so change the API to have a vararg function
and require the allowed capabilities to be passed in.
There's likely little use for the previous allow-vs-deny policy etc, so
let's not make things more complicated an they have to be.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
