With this design, a single PointerInterface manages multiple wl_pointer
objects. This makes the API tidier and allows implementing things such as
keyboard grabs more easier.
In addition to that, the PointerInterface doesn't inject its own frame
events anymore. It's up to the compositor to decide when it has to be
sent. However, the PointerInterface may still send a frame event if the
pointer focus changes.
Besides re-writing the pointer interface, this change, unfortunately,
also affects the implementation of pointer-gestures and relative-pointer
protocols because previously they were coupled to individual instances
of PointerInterface.
During a drag the source can disappear at any time. The other client
will be notified, but it may have actions in flight.
Other methods were guarded but not data_offer_finished.
Currently, the compositor is supposed to pass the position of the touch
point to the touchDown() function and in return get its unique global
id. The id can be be passed to subsequent touchMotion() and touchUp().
The compositor is responsible for mapping between libinput slots and
internal touch point ids.
The mapping step is unnecessary and adds in some complexity as the input
code now has to keep the mapping table up to date.
This change makes the touch API more convenient to use by making
relevant functions take touch ids that are assigned by the compositor.
Usually, compositor would use libinput_event_touch_get_seat_slot() to
get touch ids.
It also allows introducing event objects that can be useful later in the
future.
This is a copy of the code from Qt5.15 with some backported patches from
development branch of Qt.
One of the upcoming fixes introduces new API, which is why we can't rely
on distro packaging.
The cmake macro is mostly copied from ECM, but set to rebuild generated
code when the scanner changes.
The following order of events are legal:
Typically order is:
- server announces a new output
- client binds to a new output
- server updates the surface to be on new output
But we can have events occur in the following order:
- server announces a new output
- server updates the surface to be on new output
- client binds to a new output
At which point when we update the surface there is no ID to tell the
client which output the surface is on.
This patch watches for clients binding to output and updates
appropriately.
Be more explicit about the types, prefer passing semantically correct
parents and keep track of the pads from the object rather than relying
on them being initialised properly.
We send modifiers to the active client when they change, and when we
focus an existing client we send the cached state.
For this reason it's important we always update our internal store of
modifiers regardless of whether a surface is currently active.
Unit test is adopted accordingly.
BUG: 429930
The main reason why we have factory methods is that up to some point,
kwayland had its own signal to indicate when globals have to be removed.
Now that all globals add destroy listeners for the wl_display object,
we don't have that signal. Most factory methods are equivalent to doing
new T(display).
Besides adding unnecessary boilerplate code, another reason to get rid
of the factory methods is to reduce the amount of merge conflicts. If
several persons work on implementing wayland protocols at the same time,
sooner or later someone will have to resolve merge conflicts in Display.
libwayland-server allows the wl_display accept client connections on
more than one socket. We currently don't listen on multiple sockets,
but it would be nice if Display supported such operation mode.
And make them public in th keyboard_interface, there's no point in
wrapping this in seat_interface with new approach
See also: plasma/kwayland-server#13
A threshold exists to stop users flooding the server for no reason.
However, there is a usecase for small timeouts.
rsibreak has a "please relax for 20 seconds" interface. Here it makes
perfect sense to know if a user is active in small increments. The plan
is to start a 1s timer and wait for that. Then we wait locally for 20s
without a resume event.
We cannot end a drag after the destroyed() signal for the source data
device is emitted because DataDeviceInterface and its d pointer are gone
by that time.
One of the most disappointing things when writing autotests is dealing
with a race condition where destructor requests are processed after all
globals have been destroyed.
With this change, the Display object will destroy all clients and their
resources before destroying the wl_display object. The good thing about
doing so is that shut down logic becomes simple. We don't have to assume
that wl_resource objects can outlive their wl_global objects, etc. The
bad thing is that it exposed a couple of pre-existing latent bugs in the
data device and the xdg foreign code.
closesplasma/kwayland-server#2
