Without these devices, things that depend on the existance of input
device classes won't know about the existance of e.g. pointer devices,
if the only pointer device is from a virtual one.
This requires handling situations where e.g. a device doesn't have a
device node thus can't be matched against a udev device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
Libinput will queue a few initial events when a seat is assigned to the
udev backend; a result of it probing udev adding detected devices. For
us to see these events, we need to dispatch libinput before going idle,
as nothing will show up on the libinput file descriptor until something
else (e.g. keyboard event or mouse movement) wakes us up.
Do this by adding a prepare() function to the libinput GSource, that
checks whether there are any events in the queue already, and return
TRUE if so is the case, causing us to dispatch before going fully idle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
Currently, when a remote desktop user submits a keycode, it will be
interpreted differently, when using the x11 session, instead of a
wayland session.
In a wayland session, submitting a keycode will have the expected
result (as if the key was pressed locally).
In a x11 session, this is not the case. Instead of getting the expected
key, some other key will be pressed (or sometimes even none).
The reason for this is that the native backend interprets the keycode
as evdev keycode and the x11 backend interprets the keycode as xkb
keycode.
To ensure that both backends produce the same behaviour when submitting
a keycode, fix the x11 backend to always interpret the keycode as evdev
keycode, instead of a xkb keycode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
When a remote desktop user emits a virtual smooth scrolling event, a
smooth scroll event, that is not emulated, is emitted and on occasion
a discrete scroll event, that is emulated, is emitted.
As base for the discrete scrolling event, the smooth scrolling steps
are accumulated.
When the accumulated smooth scrolling steps surpass the
DISCRETE_SCROLL_STEP, the discrete scrolling event is emitted.
Currently, mutter uses for DISCRETE_SCROLL_STEP the value 10, which is
a terrible value to work with, especially for high resolution mouse
wheels.
When a triple resolution mouse wheel is used, each scrolling step will
have the value 3 1/3.
Three of such events won't however surpass the DISCRETE_SCROLL_STEP.
To fix this situation, add DBL_EPSILON to the calculation step, when
checking for the discrete scroll event to ensure that 3 smooth scroll
events, with each having the value 3 1/3, emit a discrete scrolling
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
MetaVirtualInputDeviceX11 currently doesn't handle smooth scroll events
at all.
So, if a user of the remote desktop API uses smooth scroll events, then
only the wayland backend handles these events.
The user of the remote desktop API however, might not know which
backend is being used and actually the user should not even have to
care about it.
Actual smooth events cannot be emulated in the X11 events.
What can be done however is accumulating smooth events and then when
the accumulated steps surpass the DISCRETE_SCROLL_STEP value, emit a
discrete scroll event.
So, do exactly that, to make smooth scroll events work when the remote
desktop API is used with the x11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
Given X11 nature, the pointer "leaves" the stage anytime it wanders into
a client window, or any other areas that are not deemed part of the
stage input region.
Yet we want to stay correct in those situations, e.g. have the clutter
side reasonably in sync, picking and highlighting to work properly, etc.
In order to achieve that, emulate motion events on XI_RawMotion. These
are as much throttled as our pointer tracking for a11y, in order to avoid
too many XIQueryPointer sync calls. This emulation only kicks in anytime
that X11 notifies us that we are not "on" the stage.
This replaces some sync_pointer() calls in GNOME Shell code that are
there just to compensate for this trait of X11, e.g. in the message tray
code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.
Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
g_set_error_literal() asserts that the provided message is not NULL.
If it is NULL, the function is entirely no-op.
This resulted in a NULL dereference of the GError, which remained
NULL in this case, when trying to print a warning in
clutter_stage_cogl_redraw_view().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
PipeWire recently introduced busy buffers, which actually fixes the last remaining
issue that blocked us from downgrading these cogl_framebuffer_finish() calls into
cogl_framebuffer_flush() ones.
Switch to cogl_framebuffer_flush() in all three stream sources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1701>
When a transfer request is done to the MetaSelectionSourceRemote source,
it's translated to a SelectionTransfer signal, which the remote desktop
server is supposed to respond to with SelectionWrite.
A timeout (set to 15 seconds) is added to handle too long timeouts,
which cancels the transfer request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
Nothing is hooked up, it only does basic sanity checking i.e. whether
the clipboard was enabled when interacting with it. No actual clipboard
integration is hooked up yet.
This also syncs org.gnome.Mutter.RemoteDesktop.xml from
gnome-remote-desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
The original implementation of ::touch-mode tested for keyboard
presence to know whether the OSK and other touch-only features were
enabled.
However that didn't pan out, every webcam, card reader and kitchen
sink like to live a second life as EV_KEY devices. This made the
detection of actual external keyboards a much harder task than it
sounds, and was thus removed in commit f8e2234ce5.
Try a different approach here, and test for pointer devices, it
doesn't matter if internal or external devices, the rationales:
- It is significantly easier to get this right, there's virtually
no devices with abs/rel axes that don't try to be a real input
device of some sorts.
- It's not as good as testing for keyboard presence, but it's the
next best thing. These usually come in pairs, except in weird
setups.
- It is better than not having anything for a number of situations:
- Non-convertible laptops with a touchscreen will get touch-mode
disabled due to touchpad presence (plus keyboard). There's
been complains about OSK triggering with those.
- Same for desktop machines with USB touchscreens, the mouse
(and presumably keyboard) attached would make touch-mode
get in the middle.
- Convertible laptops with a broken tablet-mode switch get a
chance to work on tablet modes that do disable input devices
(e.g. detachable keyboards, or via firmware)
- Kiosk machines, tablets, and other devices that have a
touchscreen but will not regularly have a mouse/keyboard
will get the touch-mode enabled.
All in all, this seems to cover more situations the way we expect it,
there's only one situation that the OSK would show where it might
not be desirable, and one that might not show when it better should:
- Tablets and kiosk machines that get one keyboard plugged, but not a
mouse, will still show the OSK, despite being able to type right
away.
- Convertible laptops with broken/unreliable tablet-mode switch (e.g.
ignored by the kernel) rely entirely on the device/firmware
characteristics to work. If after folding into tablet mode the
touchpad remains active, touch-mode will not turn on.
Fixing the tablet-mode switch on these devices should be preferred,
as that'll also make libinput magically disable the touchpad.
The latter can be worked around with the a11y toggle. The former is
merely inconvenient, and nothing prevents the user from plugging a mouse
in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1710>
When recording the screen and real time encoding it using a gstreamer
pipeline, that pipeline can stall when the encoder is too slow. Log a
debug message using the new SCREEN_CAST debug topic in that case so we
know when framedrops are happening.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1709>
The other end of the PipeWire stream can set the buffer data type to a
bitmask of supported buffer types. We should respect this, and not
attempt to allocate a DMA buffer if it isn't asked for.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1697>
Instead of getters, pass the width, height and stride around when
relevant. This also removes the redudant "stream_size" and
"stream_height" variables from the src struct, as they are already part
of the video format.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1697>
Mutter needs to fetch the X11 Window ID from the onscreen and did that
by using an X11 specific API on the CoglOnscreen, where the X11 type was
"expanded" (Window -> uint32_t). Change this by introducing an interface
called CoglX11Onscreen, implemented by both the Xlib and GLX onscreen
implementations, that keeps the right type (Window), while avoiding X11
specific API for CoglOnscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Instead of calling "init_onscreen()" on two different separate vtables
from the allocate() funtion, just have the CoglOnscreen sub types
themself implement allocate() and initialize in there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Thins means that e.g. MetaOnscreenNative now inherits CoglOnscreenEgl,
which inherits CoglOnscreen which inherits CoglFramebuffer, all being
the same GObject instance.
This makes it necessary to the one creating the onscreen to know what it
wants to create. For the X11 backend, the type of renderer (Xlib EGL or
GLX) determines the type, and for the native backend, it's currently
always MetaOnscreenNative.
The "winsys" vfunc entries related to onscreens hasn't been moved yet,
that will come later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
To get meta-renderer-native.c down to a bit more managable size, and to
isolate "onscreen" functionality from other (at least partly), move out
the things related to CoglOnscreen to meta-onscreen-native.[ch].
A couple of structs are moved to a new shared header file, as
abstracting those types (e.g. (primary, secondary) render devices) will
be dealt with later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The mutter naming convention for types and their instance variables is:
Type name:
[Namespace][BaseName][SubType]
Instance name:
[base_name]_[sub_type]
This means that e.g. CoglOnscreenGLX is renamed CoglOnscreenGlx, and
glx_onscreen is renamed onscreen_glx. This is in preparation for
GObjectification.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Makes sure that monitor specs which may be read from EDID data do not
contain characters that are invalid in XML. Makes it possible to restore
monitor configs of monitor models with characters such as '&' in them.
To make this change not break any tests, the sample monitor configs need
to be adjusted as well. Apostrophes don't strictly have to be escaped in
XML text elements. However, we now do escape the elements in
`<monitorspec>` specifically.
Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1685>
If the monitor configuration changed, even though the streamed monitor
didn't change, we'd still fail to continue streaming, as we failed to
update the stage watchers, meaning we wouldn't be notified about when
the stage views were painted.
Fix this by reattaching the stage watches, i.e. update the painted
signalling listeners to listen to the right views, when monitor changes
happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1691>
