This leaves only the atomic mode setting cap check before creating the
impl device, aiming to make it possible to create a non-mode-setting
MetaKmsImplDevice implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to pass --headless as a command line argument in order
to turn the native backend "headless". This currently doesn't do
anything, but the intention is that it should not use logind nor KMS,
and work completely headless with only virtual outputs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
With commit 7d78768809 we switched to
storing pointer coordinates in MetaInputDeviceNative instead of
ClutterInputDevice, and while we had set the coordinates of the
ClutterInputDevice in ClutterStage when queueing an event, we now set
the MetaInputDeviceNative coordinates in new_absolute_motion_event().
Here a small mistake snuck in: new_absolute_motion_event() only
translates the coordinates of the event, but we call
meta_input_device_native_set_coords() using the x and y variables
(which remain untranslated), so now the input device coordinates are no
longer translated.
Fix that by translating the coordinates of the x and y variables in case
we're we handling a tablet/stylus event instead of only translating the
event coordinates.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1685
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1760>
With commit c985753442 the support for
multiple hardware cursors broke, but those were never properly supported
anyway as we usually assume there's only one hardware cursor around.
With the introduction of the KMS thread in the future, we'll only have
one KMS cursor that gets updated directly from the input thread. So
apart from the fact that it never really makes sense to have two cursors
visible, in this new model having multiple cursors won't work anyway.
So make the cursor we show for stylii a software cursor again.
Eventually the plan is to make the input device that's driving the KMS
cursor interchangeable, so that we can always use hardware cursors.
This reverts commit 165b7369c8.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1645
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1758>
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.
The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
KMS and GLX device timestamps have microsecond precision, and whenever
we sample the time ourselves it's not the real presentation time anyway,
so nanosecond precision for that case is unnecessary.
The presentation timestamp in ClutterFrameInfo is in microseconds, too,
so this commit makes them have the same precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
A flag indicating whether the presentation timestamp was provided by the
display hardware (rather than sampled in user space).
It will be used for the presentation-time Wayland protocol.
This is definitely the case for page_flip_handler(), and I'm assuming
this is also the case for the two instances in the GLX code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
The old calculation was introduced to improve the precision
with commit c16a5ec1cf.
Here, I call the calculation as "revision 2", and the
calculation even older as "revision 1", and the new
calculation introduced with this commit as "reivion 3".
Revision 2 has two problems:
1. The calculation is mixed with fixed-point numbers and
floating-point numbers.
To overcome the precision loss of fixed-point numbers division,
it first "calculates refresh rate in milliHz first for extra
precision", but this requires converting the value back to Hz.
An extra calculation has performance and precision costs.
It is also hard to understand for programmers.
2. The calculation has a bias.
In the process, it does:
refresh += (drm_mode->vtotal / 2);
It prevents the value from being rounded to a smaller value in
a fixed-point integer arithmetics, but it only adds a small
bias (0.0005) and consumes some fraction bits for
floating point arithmetic.
Revision 3, introduced with this commit always uses
double-precision floating-point values for true precision and
to ease understanding of this code. It also removes the bias.
Another change is that it now has two internal values, numerator
and denominator. Revision 1 also calculated those two values
first, and later performed a division with them, which minimizes
the precision loss caused by divisions. This method has risks of
overflowing the two values and revision 1 caused problems due to
that, but revision 3 won't thanks to double-precision. Therefore,
revision 3 will theoretically have the result identical with
the calculation with infinite-precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1737>
This removes the responsibility of tracking these from the backend to
the base object. The backends are instead responsible for calling the
function to update the values.
For the native backend, it's important that this happens on the correct
thread, so each time either of these states may change, post a idle
callback on the main thread that sets the, at the time of queuing said
callback, up to date state. This means that things on the main thread
will always be able to get a "new enough but not too new" state when
listening on the 'notify::' signals and getting the property value
after.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1739>
Each next and current scanout buffer has a reference on them making sure
they stay alive. When dumb buffers were used on the secondary GPU state,
this didn't happen, leading to crashes due to unref:ing one time too
many, with backtraces such as
0) g_type_check_instance_is_fundamentally_a ()
1) g_object_unref ()
2) secondary_gpu_release_dumb ()
3) import_shared_framebuffer ()
4) update_secondary_gpu_state_post_swap_buffers ()
5) meta_onscreen_native_swap_buffers_with_damage ()
6) cogl_onscreen_swap_buffers_with_damage ()
7) swap_framebuffer ()
8) clutter_stage_cogl_redraw_view_primary ()
9) clutter_stage_cogl_redraw_view ()
10) _clutter_stage_window_redraw_view ()
11) handle_frame_clock_frame ()
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1746>
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>
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>
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>
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>
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>
Make the API used more shared and better named.
meta_monitor_manager_on_hotplug() was renamed
meta_monitor_manager_reconfigure(), and meta_monitor_manager_reload()
was introduced to combine reading the current state and reconfiguring.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
It was named "backend_native" and "backend" which is easily confused with
MetaBackendNative and MetaBackend which tends to have those names.
Prepare for introducing the usage of a MetaBackendNative and MetaBackend
pointers here by cleaning up the naming.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to
non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple.
This has various behavioral differences worth noting, compared to the
simple backend:
* We can only commit once per CRTC per page flip.
This means that we can only update the cursor plane once. If a primary
plane composition missed a dead line, we cannot commit only a cursor
update that would be presented earlier.
* Partial success is not possible with the atomic backend.
Cursor planes may fail with the simple backend. This is not the case
with the atomic backend. This will instead later be handled using API
specific to the atomic backend, that will effectively translate into
TEST_ONLY commits.
For testing and debugging purposes, the environment variable
MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to
force-enable or force-disable atomic mode setting. Setting it to some
other value will cause mutter to abort().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In order to reliably manage the reference count of the user data passed
to page flip listeners - being the stage view - make the ownership of
this data travel through the different objects that take responsibility
of the next step.
Initially this is the MetaKmsPageFlipListener that belongs to a
MetaKmsUpdate.
When a page flip is successfully queued, the ownership is transferred to
a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the
simple impl device, the MetaKmsPageFlipData is passed to
drmModePageFlip(), then returned back via the DRM event. In the future
atomic impl device, the MetaKmsPageFlipData is stored in a table, then
retrieved when DRM event are handled.
When the DRM events are handled, the page flip listener's interface
callbacks are invoked, and after that, the user data is freed using the
passed GDestroyNotify function, in the main context, the same as where
the interface callbacks were called.
When a page flip fails, the ownership is also transferred to a
MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page
flip data will be passed to the main context via a callback, where it
will discard the page flip, and free the user data using the provided
GDestroyNotify.
Note that this adds back a page flip listener type flag for telling the
KMS implementation whether to actively discard a page flip via the
interface, or just free the user data. Avoiding discarding via the
interface is needed for the direct scanout case, where we immediately
need to know the result in order to fall back to the composite pipeline
if the direct scanout failed. We do in fact also need active discard via
the interface paths, e.g. in the simple impl device when we're
asynchronously retrying a page flip, so replace the ad-hoc discard paths
in meta-renderer-native.c and replace them by not asking for no-discard
page flip error handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Suspending might have changed the CRTC configuration, turning some off,
some on, etc. We need to update our internal representation of this
state, so that we know how to reconfigure upon resuming, e.g. what CRTCs
to turn off again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Destroying an onscreen destroyes the gbm_surface, the gbm_bo's, and the
fb_id's. Doing this (drmModeRmFB() of the fb_id specifically), may on
some hw implicitly disable the CRTC of the plane that framebuffer was
assigned to. This would cause following atomic commit that attempts to
disable the CRTC to fail as disabling an already disabled CRTC is not
allowed.
It'd also mean we'd always disable the plane before having finished next
mode set, leaving it monitor content potentially empty when not really
necessary.
Solve this by keeping the CoglOnscreens (thus the gbm_surface, gbm_bo
and fb_id) alive until the following global mode set has completed, i.e.
the new state has been fully committed and applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes "power save" (i.e. when you make a monitor go into power save
mode, or make it come out of power save mode), a per device action when
turning on power saving (power save being set to 'off'), and implicitly
handled when turning off power saving (power save being set to 'on')
when doing a mode set.
This is needed as with atomic mode setting, the configuration of DPMS
(Display Power Management Signaling), is replaced by directly turning on
or off CRTCs, and via the CRTC drm properties. Thus in order to handle
both with a common API, make that API high level enough for both cases
being covered.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Before we received new gamma updates via D-Bus and posted the update to
KMS directly. This won't be possible with atomic KMS, since one can only
update the state of a CRTC once per cycle.
Thus, to handle this, when configured by D-Bus, only cache the value,
and mark it as invalid. The next frame, the native renderer will pick
up the newly cached gamma value and configure the CRTCs accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
We cannot switch DPMS state to 'on' first, then mode set later, when
using atomic KMS. So when we're turning it on, just let the eventual
mode set handle DPMS too.
When switching DPMS to 'off', do it directly, synchronously, both by
setting the DPMS state and switching off CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Before each frame is maybe redrawn, push any new cursor KMS state to the
pending update. It'll then either be posted during the next page flip,
or when the same frame finishes, in case nothing was redrawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes it possible to post a symbolic page flip and frame callback,
meant to be used by immediate symbolic page flip reply when emulating
cursor plane changes using legacy drmMode* functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of setting the frame result in the most generic layer, have the
backends do it themselves. This is necessary to communicate that a
swap-buffer call didn't really succeed completely to present the swapped
buffer, e.g. errors from KMS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterFrame aims to carry information valid during dispatching a frame.
A frame may or may not include redrawing, but will always end with a
result.
A asynchronous page flip, for example, will result in a
CLUTTER_FRAME_RESULT_PENDING_PRESENTED, while a frame that only
dispatched events etc will result in CLUTTER_FRAME_RESULT_IDLE. Instead
of this being implicit, make the ClutterStageWindow implementation
handle this itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The way drm events are handled depends on whether we're using atomic or
not. Lets move the handling to the implementation, so that later the
atomic backend can handle the event they it need to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If we reassign e.g. a cursor plane twice before it's updated, we need to
make sure the 'fb-unchanged' flag is correctly handled, so that if we
changed the fb first, then updated the assignment again only changing
the position, the new assignment should not be flagged with
fb-unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When we e.g. try to post an direct client buffer scanout update, it
might arbitrarily fail; when this happen we still will want to post the
rest of the update when we try again after having composited the primary
plane. To do this, add a way to preserve the metadata of an update if it
failed, only dropping the failed plane assignments. This involves
unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary
plane can be assigned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Sealing is a one way operation, but in the next commit, the "seal" will
be broken, so to avoid missusing the "seal" terminology, rename related
methods and variables to use the term "lock" instead. E.g.
meta_update_is_sealed() is now meta_update_is_locked().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If a modeset is pending, it's likely that the cursor update will not
work; thus, wait with updating the cursor so that it's applied together
with the mode set update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Something might want to affect the next update that is going to be
posted, but without posting it immediately. For example, changing the
cursor might need to wait for mode setting. Make it possible to get
feedback from posting the update, in order to gracefully handle any
errors.
Note, the API for notifiying about results take out the result listener
from the update, and notifies them in an open coded for loop. The reason
for this is that in the next commit we'll sometimes reuse updates, and
we only want notify about the results once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Page flipping shouldn't necessarily be an actively requested action, but
happen implicitly depending on the given state. Thus, change the "page
flip" update into adding listeners for page flip feedback instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This will later make it possible to pass cursor plane assignments,
together with a complete update including the primary plane, but not
failing the whole update if just processing the cursor plane failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If posting an update resulted in an immediate error, don't communicate
this failure using the page flip feedback callbacks, but directly as a
return value.
This makes it possible for the direct client buffer scanout path not to
pass around flags triggering this behavior, meaning we can handle such
direct scanouts better.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a "post all pending updates", pass an update specific to a
single device. This gets rid of the awkward "combine feedback" function,
and makes it possible to queue updates to a multiple devices without
always posting them together.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Custom page flips are meant to allow using e.g. EGLStream API to
indirectly trigger page flip queueing, when the KMS API cannot be used
directly. This is really something that is specific to a device, so
instead of making part of the page flip API, make it a configuration of
the update itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Eventually the type of impl device will depend on the driver details, so
get that information before constructing the impl device. This commit
doesn't introduce any new usage of the details, it just prepares for
the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
For now feedbacks from an update are combined, meaning we might lose
error information. The feedback API may have to be reconsidered and
redesigned when planes gets a more front seat position.
This means we need to avoid trying to post updates if we're in power
save mode, as it may be empty.
Note that this is an intermediate state during refactoring that aims to
introduce atomic mode setting support, and we'll stop combining
feedbacks completely in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a constructor method, use the type directly and handle error
reporting using GInitable.
The DRM capability setting is done before construction, as later it'll
determine what type of impl device should be constructed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector
property changes, make the update itself aware of the changes, making
the impl side translate that to property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of having MetaKmsPlaneAssignment carry a low level property
list, set the actual state change, and then have the implementation
translate that into the necessary property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
With the aim at always using the property table to fetch and parse
property metadata, move IN_FORMATS handling to the property table, using
the newly introduced parse vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Values may need to be processed and parsed in custom ways; make this
possible via the property table infrastructure using a callback.
Will be used for e.g. parsing rotation and formats.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of relatively verbosely going through the DRM properties finding
the properties we care about and saving their ID's, add a more
declarative way to fetch property metadata. This'll allow for fetching
more property IDs with relatively less code, which will be useful for
the atomic backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This contains a copy of a drmModeModeInfo, describing a mode. It also
has an unused pointer to the impl device it is associated with. It'll
later be used to get a blob ID for the mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This means backend implementations can have more control of the order of
how things are destroyed. To be precise, this will, in the next commit,
allow us to destroy the logind integration after the clutter backend
thus the libinput owning seat, that uses the logind integration to
release input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
We can't post tasks to the input thread when cleaning up the
MetaSeatImpl, as that will make the GTask complain about adding
references to a to be purged object. Avoid this by adding an explicit
meta_seat_impl_destroy() function that handles the destruction of the
MetaSeatImpl properly.
This also does more of the cleanup in the input thread, as that is where
it was managed. Will likely not make a difference as before this
happened after tearing down the thread, but lets tear down things in the
thread they were managed for good measure.
This fixes the last log spew I see right now when terminating mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
We didn't tear down the libinput objects in the right thread when
exiting, but did so after the input thread exited.
We also tried to destroy the libinput devices after the libinput context
was destroyed, which isn't allowed.
Fix these two issues by tearing down the libinput objects in a input
thread task that when done exits the input thread. This effectively
"flushes" the input thread tasks while destroying the libinput objects
just before the thread exits.
While it might fine to tear down libinput objects in an arbitrary (main
in this case) thread while making sure nothing pokes at it in parallel
(e.g. the input thread is gone), libinput is by definition single
threaded, and could theoretically make assumptions about this, and we
shouldn't cause any possible surprises here, so make sure to destroy it
all in the right thread.
This fixes an abort() on exit caused by an assert about invalid object
destruction in libinput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
The "seat" usually refers to the ClutterSeat (MetaSeatNative) object,
and "seat_impl" to the MetaSeatImpl object, but there were still a few
places where this wasn't adhered to so fix those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
To clear a pointer constraint, the Wayland backend passes a NULL
constraint to the native input backend.
The new async API however tries to reference/un-reference the given
object to use it while running in a separate task, which leads to a
warning from GLib trying to g_object_ref()/g_object_unref() a non
GObject pointer.
To avoid that issue, simply set the data only if the given constraints
pointer is not NULL.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1587
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1652>
Power saving changes in laptop panels enable/disable the attached
touchscreen input device, this is an asynchronous operation that
may be happening while the device is disappearing.
In fact, closing the lid is such perfect storm where both things
happen around the same time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1644>
Currently, the MetaInputDeviceNative owns the libinput_device, with the
small catch that it is eventually finished in the main thread (as the
CLUTTER_DEVICE_REMOVED event keeps the last reference to it).
Make it sure that the libinput_device is destroyed in the input thread,
before giving away the last extra input device references.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1639>
There was an attempt to remove an unnecessary inclusion of a header
file, but only got so far as compile testing after having commented out,
but didn't remove the comment before creating a commit. This commit
fixes that mistake.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1640>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Ensure that color_ptr gets set, and avoid color_char usage too in
that case. Fixes:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c: In function ‘meta_monitor_manager_kms_set_crtc_gamma’:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:370:7: warning: ‘color_char’ may be used uninitialized in this function [-Wmaybe-uninitialized]
370 | g_string_append_printf (string, " %c: ", color_char);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:351:12: note: ‘color_char’ was declared here
351 | char color_char;
| ^~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:391:36: warning: ‘color_ptr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
391 | (*color_ptr)[i]);
| ~^~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:350:24: note: ‘color_ptr’ was declared here
350 | unsigned short **color_ptr;
| ^~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
Figuring out the MetaSeatImpl this much indirectly is fairly awkward when
the keymap is only updated from the MetaSeatImpl, pass instead the seat
impl's xkb_state, as we have it handy in all the places this is called.
This will not break on NULL seats during initialization, should the numlock
state be restored from previous sessions.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1556
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1612>
Make it impossible to add individual includes of input thread objects.
This must go through meta-input-thread.h now, which should be enough
to make anyone think it twice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
They're a dime a dozen. If it gets called exclusively from the
input thread, it got one. Hopefully these breadcrumbs will be
enough so people don't lose their way here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This (now) doesn't change anything in regards to the API that the UI
thread should access from the MetaSeatImpl. The MetaInputDeviceNative,
MetaInputSettings and MetaKeymap objects are now considered owned by
the input thread, as well as all of libinput objects.
The MetaEventSource now dispatches events in a GMainContext that is
the thread default to this thread, and all UI-thread-accessible API
(seat and virtual input device API) will be handled in a serialized
manner by that same input thread.
The MetaSeatImpl itself is still considered to be owned by the caller
thread, and all the signals that this object emits will be emitted in
the GMainContext that is default at the time of calling
meta_seat_impl_new().
The MetaInputSettings configuration changes will likewise be handled
in the input thread, close to libinput devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of going through the event queue, stage handling code, and
back to the input device via a vmethod call, do this directly in the
MetaSeatImpl. This is not too different from X11, where everything
happens inside the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This API is the one accessed from different bits of the UI thread,
make it "async" (it's basically one-way setters, so API stays the same
in the surface) and able to run in the MetaSeatImpl main context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Simplify the handling of numlock state, so it can be entirely handled
within the input thread. Since the saving/restoring is triggered inside
each backend code, there's no need anymore for meta_backend_set_numlock().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Push it a little bit down to the MetaSeatNative. As both the UI thread
and the input thread are interested in dealing with the xkb_keymap and
it is not meant to be used in different threads, keep 2 separate copies
around.
The keyboard map will always be set from the UI thread, so the xkb_keymap
owned by the MetaSeatNative (owned by the UI thread) can be considered
canonical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Don't let the vfuncs (meant to be called from the UI thread) deal with
xkb state itself. Instead store the current state in struct fields, which
is then fetched in vfuncs.
This makes the keymap able to be used from the UI thread, while being
maintained by the input thread. Same caveats apply than
clutter_seat_query_state(), you are asking for the most up-to-date state,
but it still may be changing under your feet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Wrap all keyboard state updates, and all pointer/stylus/touch cursor
position with a write lock, and ::query_state() (The only entrypoint
to this state from other threads) with a read lock.
The principle is that query_state may be called from different threads
(UI so far, but maybe KMS too in the future), while the input thread
may (or may not) be updating it. This state is fetched "atomically"
(eg. x/y will be consistently old or new, if the input thread were
updating it at the same time).
There's other places deep in backends/native that read this state,
they all will run in the input thread, so they count as "other readers"
to the other thread. Those changes are already mutually exclusive with
updates, so they don't explicitly need the RW lock.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While barriers will be added from the main thread, the native barrier
manager will sit close to the MetaSeatImpl in its own thread. Add the
necessary locking so that we can pass MetaBarrierImplNative from the
UI thread to the input thread, and ensure the MetaBarrier signals are
still emitted in the UI thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Depending on the backend, we want to integrate this object at different
levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but
it will be put deep down with MetaSeatImpl in the native backend, in a
separate thread.
Since we can't depend on a single object type, nor are able to track
ClutterSeat signals neatly, make this API something to be called
explicitly by backends.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These changes will happen in the input event management code, so let them
be emitted via the MetaSeatImpl, as that's what we'll have neat access to.
The ClutterSeat signals are now emitted from there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Move most of the functional bits (those meant to run on a standalone
thread) to a MetaSeatImpl object. This object is managed by the MetaSeatImpl
and not exposed outside the friend MetaSeatNative/MetaInputDeviceNative/
MetaInputSettings classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Banish MetaInputSettings from MetaBackend "public" API, it's now meant to
spend the rest of its days in the backend dungeons, maybe hanging
off a thread.
MetaInputMapper replaces all external uses.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio()
one that takes an aspect ratio double, instead of leaking monitor info
into subclasses to let them all figure out this number themselves.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We have 2 sources (this one in MetaSeatNative, and the one in
MetaBackend) dispatching ClutterEvents to the stage. Make the
MetaSeatNative one exclusively about dispatching the libinput
queue, and leave ClutterEvents to the other.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This will resort to SW rendering if this cursor renderer does not
own the MetaKmsCursorRenderer, so it's pretty much equivalent thus
far, except we may now implement logic to flip the kms cursor renderer
around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We are aiming for a split of HW and SW cursor rendering management.
Given the HW plane is a limited resource and the amount of cursor
renderers may be >1 (due to tablets, even though we currently use an
always-software cursor renderer there), it would ideally be able to
switch between renderers.
Being MetaCursorRenderer not really a singleton, having cursor
inhibitor accounting here doesn't pan out. Make it MetaBackend API
so all cursor renderers get the same picture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Different devices may get standalone cursor renderers, add this API
to adapt slowly to this. The meta_backend_get_cursor_renderer() call
still exists, but shortcuts to the mouse pointer's renderer (as it
actually did before).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Use a new set in MetaInputDeviceNative, this coexists with
ClutterInputDevice coords for the time being. This API will
eventually be only accessed from the input thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
xkb recently gained support for user-specified keymaps, which means we
can no longer assume that the configuration data is necessarily fully
complete or correct; and the configuration language is quite a labyrinth,
so it's easy to get wrong. If setting the keymap fails, leave it in
whatever state it previously had, since that seems preferable to crashing
with a NULL pointer dereference.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1555
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1605>
Sometimes the automatically selected primary GPU isn't suitable with no
way to make an well educated guess to do it better. To make it possible
for the user to override the automatically calculated default, make it
possible to override it using a udev rule.
E.g. to select /dev/dri/card1 as the primary GPU, add a file e.g.
/usr/lib/udev/rules.d/61-mutter-primary-gpu.rules (path my vary
depending on distribution) containing the fellowing line:
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
Reboot or manual triggering of udev rules to make it take effect may be
required.
Related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/1057https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562>
At startup, libinput dispatch is called from the MetaSeatNative
constructed callback.
That means that we may get libinput events even before the default seat
is set.
In turn, processing those events may trigger the use the default seat
while it's still not set yet, and cause a crash of gnome-shell/mutter
at startup.
A simple reproducer for this is to start gnome-shell/mutter with a
tablet connected and the stylus in proximity, the proximity event will
cause gnome-shell/mutter to crash at startup.
To avoid that issue, avoid dispatching libinput events early from the
MetaSeatNative constructed callback, those events will eventually get
processed when the seat and the backend are all setup.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1501https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
As it does seem from a read to libinput code, TOUCH_CANCEL events
actually do contain slot information, and are emitted per-slot.
This means we can avoid iterating over the slots ourselves, they
are still expected to be sent altogether.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.
This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.
This fixes tablet-mode-switches only being recognized when they are added
at runtime.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.
Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
During seat initialization, we process early libinput events (adding all known
devices) before the seat gets a stage assigned. This causes warnings when trying
to handle the corresponding CLUTTER_DEVICE_ADDED events, as they are sent
stageless.
As it is definitely too soon to have those events sent meaningfully, filter
those events out and instead handle the CLUTTER_DEVICE_ADDED emission for all
known devices after the seat receives an stage. This makes the events guaranteed
to be emitted early in initialization, but not so soon that they can't be
handled yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1472
In X, buttons 1, 2, 3 are left, middle, right. In evdev, the order is
BTN_LEFT, BTN_RIGHT, BTN_MIDDLE. So setting a scroll button to 2 gave us a
middle button in the X session and a right button in a wayland session.
Fix that by hard-coding the LMR buttons handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1433
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
It's enabled by default when using the i915 driver, but disabled
everywhere else until it can be made reliably an improvement. Until
then, for anyone want to force-enable it, add the string
'dma-buf-screen-sharing' to the experimental features list in GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
