Add a method to ClutterSeat that allows peeking the list of input
devices and allow looping through devices a bit faster. The API left is
private so we can make use of peeking the GList internally, but don't
have to expose any details to the outside, which means we'd have to
eventually stick with a GList forever to avoid breaking API.
Since we now have the peek_devices() API internally, we can implement
ClutterSeats public list_devices() API using g_list_copy() on the list
returned by peek_devices().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Trying to figure out what this comment was actually about, it turns out
that MSC means Media Stream Counter, and as mentioned in an article[0]
is related to DRI3 and the X11 Present extension. Anyway, the comment
has been there raising questions for some years now, I think we can
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The ID and name are just moved into the instance private, while the rest
is moved to a `MetaCrtcModeInfo` struct which is used during
construction and retrieved via a getter. Opens up the possibility to
add actual sub types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Just as with MetaOutput, instead of the home baked "inheritance" system,
using a gpointer and a GDestroyNotify function to keep the what
effectively is sub type details, make MetaCrtc an abstract derivable
type, and make the implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Instead of the home baked "inheritance" system, using a gpointer and a
GDestroyNotify function to keep the what effectively is sub type
details, make MetaOutput an abstract derivable type, and make the
implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Now set as a property during construction. Only actually set by the
Xrandr backend, as it's the only one currently not supporting all
transforms, which is the default.
While at it, move the 'ALL_TRANFORMS' macro to meta-monitor-tranforms.h.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The output info is established during construction and will stay the
same for the lifetime of the MetaOutput object. Moving it out of the
main struct enables us to eventually clean up the MetaOutput type
inheritence to use proper GObject types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
MetaCrtcInfo and MetaOutputInfo did not represent information about
MetaCrtc and MetaOutput, but the result of the monitor configuration
assignment algorithm, thus rename it to MetaCrtcAssignment and
MetaOutputAssignment.
The purpose for this is to be able to introduce a struct that actually
carries information about the CRTCs and outputs, as retrieved from the
backend implementations.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
That is is_presentation, is_primary, is_underscanning and backlight.
The first three are set during CRTC assignment as they are only valid
when active. The other is set separately, as it is untied to
monitor configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
It was used during configuration to ensure that we always dealt with
every output and CRTC. Do this without polluting the MetaOutput and
MetaCrtc structs with intermediate variables not used by the
corresponding types themself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
When the stage views the stage is shown on are changed, ClutterStage
currently provides a clutter_stage_update_resource_scales() method
that allows invalidating the resource scales of all actors. With the new
stage-views API that's going to be added to ClutterActor, we also need a
method to invalidate the stage-views lists of actors in case the stage
views are rebuilt and fortunately we can re-use the infrastructure for
invalidating resource scales for that.
So since resource scales depend on the stage views an actor is on,
rename clutter_stage_update_resource_scales() and related methods to
clutter_stage_clear_stage_views(), which also covers resource scales.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
When we created the DMA buffer backed CoglFramebuffer, we handed it over
to CoglDmaBufHandle which took its own reference. What we failed to do
was to release our own reference to it, effectively leaking it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
This cannot be made to work reliably. Some factoids:
- Internal devices may be connected via USB.
- The ACPI spec provides the _PLD (Physical location of device) hook to
determine how is an USB device connected, with an anecdotal success
rate. Internal devices may be seen as external and vice-versa, there is
also an "unknown" value that is widely used.
- There may be non-USB keyboards, the old "AT Translated Set 2 Keyboard"
interface does not change on hotplugging.
- Libinput has an internal series of quirks to classify keyboards as
internal of external, also with an "unknown" value.
These heuristics are kinda hopeless to get right by our own hand. Drop
this external keyboard detection in the hope that there will be something
more deterministic to rely on in the future (e.g. the libinput quirks
made available to us directly or indirectly).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2378
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1277
Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.
The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
Will be used for logging to identify what view a log entry concerns. For
the native and nested backend this is the name of the output the CRTC is
assigned to drive; for X11 it's just "X11 screen", and for the legacy
"X11 screen" emulation mode of the nested backend it's called "legacy
nested".
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
We were iterating through evcodes, but using API that expects Clutter button
numbers. Instead of transforming those to Clutter numbers to have those translated
back, use the inner seat API that already takes evcodes.
Fixes stuck buttons keys after a virtual device is destroyed while those are
pressed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1239
If drmModePageFlip() or custom_page_flip_func fails, process_page_flip() was
forgetting to undo the ref taken for that call. This would leak page_flip_data.
The reference counting works like this:
- when created, ref count is 1
- when calling drmModePageFlip, ref count is increased to 2
- new: if flip failed, ref count is decreased back to 1
- if calling schedule_retry_page_flip(), it takes a ref internally
- if calling mode_set_fallback(), it takes a ref internally
- all return FALSE paths have an explicit unref
- return TRUE path has an explicit unref
This issue was found by code inspection and while debugging an unrelated issue
with debug prints sprinkled around. I am not aware of any end-user visible
issues being fixed by this, as the leak is small and probably very rare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.
A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Surface buffers are created with meta_drm_buffer_new_acquire(), taking a
gbm_surface acquiring the gbm itself, and meta_drm_buffer_new_take()
that takes over ownership of a passed gbm_bo.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
The CRTC level transform (not necessarily the hw transform) must be
taken into account when calculating the position of the CRTC in the
stage coordinate space, when placing the hw cursor, otherwise we'll
place the cursor as if the monitor was not rotated.
This wasn't a problem in the past, as with rotation, we always used the
OpenGL cursor, so the issue newer showed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
The port to per CRTC views was incomplete; we still used the logical
monitor layout as the stage view layout, while still using one view per
CRTC.
This worked fine for most cases, e.g. regular monitors, tiled or
non-tiled, transformed or non-transformed. Where it broke, however, was
when a monitor consists of multiple CRTCs. We already have the layout a
CRTC corresponds to on the stage kept with the CRTC metadata, so use
this directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1170https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199`
The motion events of tablets for example need to be mapped on the
selected screen area if the input device is configured to use only a
part of the active logical monitor.
To achieve this behavior each motion event is transformed using the
transformation matrix set for the input device.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1118
GObject recommends to break references to other objects on dispose
instead of finalize, also we want to release the pressed virtual buttons
as early as possible if we know the object is getting destroyed.
So release the pressed buttons and unref our virtual
MetaInputDeviceNative when the dispose vfunc is called, which also
allows us to release the buttons immediately from javascript instead of
waiting for the garbage collector by calling run_dispose() on the
object.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1157
When calculating the transform we should apply to the cursor sprite
before uploading it to the cursor plane, we must also take into
account non upright mounted LCD panels.
Otherwise the cursor ends up 90 degrees rotated on devices where the
LCD panel is mounted 90 degrees rotated in its enclosure.
This commit fixes this by calling meta_monitor_logical_to_crtc_transform
in get_common_crtc_sprite_transform_for_logical_monitors to adjust the
transform for each Monitor in the LogicalMonitor.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1123https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1153
The transactional KMS API has been modelled after atomic KMS. Atomic KMS
currently doesn't support forwarding cursor hotspot metadata, thus it
was left out of the transactional KMS API having the user set the simply
create a plane assigment with the cursor sprite assigned to a cursor
plane using regular coordinates.
This, however, proved to be inadequate for virtual machines using
"seamless mouse mode" where they rely on the cursor position to
correspond to the actual cursor position of the virtual machine, not the
cursor plane. In effect, this caused cursor positions to look "shifted".
Fix this by adding back the hotspot metadata, right now as a optional
field to the plane assignment. In the legacy KMS implementation, this is
translated into drmModeSetCursor2() just as before, while still falling
back to drmModeSetCursor() with the plane coordinates, if either there
was no hotspot set, or if drmModeSetCursor2() failed.
Eventually, the atomic KMS API will learn about hotspots, but when
adding our own atomic KMS backend to the transacitonal KMS API, we must
until then still fall back to legacy KMS for virtual machines.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
This class sits between ClutterInputDevice and the backend implementations,
it will be the despositary of features we need across both backends, but
don't need to offer through Clutter's API.
As a first thing to have there, add a getter for a WacomDevice. This is
something scattered across and somewhat inconsistent (eg. different places
of the code create wacom devices for different device types). Just make it
here for all devices, so users can pick.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
