The function meta_monitor_manager_read_current_config() was renamed to
meta_monitor_manager_read_current_state() as it does not read any
configuration, but reads the current state as described by the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation of replacing the configuration system with one working
with high level monitors instead of low level outputs etc, move
configuarion handling code into obviously named function (containing
the word 'legacy'.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
A monitor spec object is meant to be used to identify a certain monitor
on a certain output. The spec is unique per actual monitor and connector,
meaning that a monitor that changes from one connector from another
(e.g. HDMI1 to HDMI2) will not be identified as the same. It is meant
to associate for example a configuration entry with an actual monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a "mode spec" concept, meaning to be used as a identifier for an
actual monitor mode. It consists of details making a mode unique, i.e.
the total resolution and refresh rate. This will later be used to get
the actual monitor mode (set of one or more CRTC modes).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add "monitor modes" abstracting the modes set on a monitor. On normal
monitors, this directly maps to the CRTC modes, but on tiled monitors,
a monitor mode can consist modes per tiled output.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't try to mirror the physical dimension, since that's a property of
one of the monitors, not of the logical monitor. Callers are changed to
deal with choosing the monitor to represent the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't deal with adding/removing tiled Xrandr monitors in the generic
backend, but leave it to the Xrandr backend. The tiled monitor will
itself notify the backend when such a monitor is added and removed.
Tiled Xrandr monitors are now based no MetaMonitor instead of
MetaLogicalMonitor. This means that mirrored tiled monitors will now be
represented correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of using crtcs and outputs to generate logical monitors, use
the ready made monitor abstraction that hides irrelevant things such as
monitor tiling etc.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Generate a set of "monitors" abstracting the physical concepts. Each
monitor is built up of one or more outputs; multiple outputs being
tiled monitors. Logical monitors will later be built from these.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The MetaMonitorMode referred to the mode of a CRTC, and with the future
introduction of a MetaMonitor, theh old name would be confusing.
Instead call it what it is.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add private API for overriding the compositor configuration, i.e. the
compositor type (X11 WM or Wayland compositor) and backend type. This
will make it possible to add a special test backend used by src/tests/.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Put the monitor xinerama index in a separate struct that is attached to
the logical monitor using g_object_set/get_qdata(). Eventually this
should be moved to some "X11 window manager" object, but lets keep it
in MetaScreen until we have such a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Refactor the tiled monitor assembly code (that constructs a logical
monitor out of tiling information. Part of the reason is to move away
from array based storage, part is to make the code easier to follow,
and part is to separate logical monitor construction from list
manipulation.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Change meta_monitor_manager_get_logical_monitor_at() to use floats,
replace users of meta_monitor_manager_get_monitor_at_point() to use the
API that returns a logical monitor and remove the now unused function.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The method used for getting the current logical monitor (the monitor
where the pointer cursor is currently at) depends on the backend type,
so move that logic to the corresponding backends.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Turning a rectangle into a logical monitor also has nothing to do with
the screen (MetaScreen) so move it to MetaMonitorManager which has that
information.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This is the current equivalent of looking up the logical monitor in the
logical monitor array using the number, but eventually that will be
deprecated, and before that done differently, so add a temporary helper
for the places that has not been ported yet.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
It was just pointer to the actual list; having to synchronize a list of
logical monitors with the actual monitors managed by the backend is
unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
src/backends/meta-egl.c: In function ‘set_egl_error’:
src/backends/meta-egl.c:144:16: error: format not a string literal and no format arguments [-Werror=format-security]
error_str);
^~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=777389
Use the proposed EGL_WL_wayland_eglstream EGL extension instead of the
file descriptor hack that was used as a temporary solution.
Note that this results in EGL clients will no longer work if they are
running on a Nvidia driver with a version older than 370.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
We need to do swap notifications asynchronously from flip events since
these might be processed during swap buffers if we are waiting for the
previous frame's flip to continue with the current.
This means that we might have more than one swap notification queued
to be delivered when the idle handler runs. In that case we must
deliver all notifications for which we've already seen a flip event.
Failing to do so means that if a new frame, that only swaps buffers on
such a swap notification backlogged Onscreen, is started, when later
we get its flip event, we'd notify only an old frame which would hit
this MetaStageNative's frame_cb() early exit:
if (global_frame_counter <= presented_frame_counter)
return;
and we'd never finish the new frame and thus clutter's master clock
would be waiting forever stuck.
https://bugzilla.gnome.org/show_bug.cgi?id=774557
When flush-swap-notify is already queued, we might end up trying to
requeue it, for example when handling flip callbacks inside
swap-buffers. Actually queuing it there is harmless, since old frames
will be discarded anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=774923
We might still end up in swap-buffer without the previous flip callback
having been invoked. This can happen if there are two monitors, and we
manage to draw before having all monitor flip callbacks invoked.
https://bugzilla.gnome.org/show_bug.cgi?id=774923
This commit adds for a new type of buffer being attached to a Wayland
surface: buffers from an EGLStream. These buffers behave very
differently from regular Wayland buffers; instead of each buffer
reperesenting an actual frame, the same buffer is attached over and
over again, and EGL API is used to switch the content of the OpenGL
texture associated with the buffer attached. It more or less
side-tracks the Wayland buffer handling.
It is implemented by creating a MetaWaylandEglStream object, dealing
with the EGLStream state. The lifetime of the MetaWaylandEglStream is
tied to the texture object (CoglTexture), which is referenced-counted
and owned by both the actors and the MetaWaylandBuffer.
When the buffer is reattached and committed, the EGLStream is triggered
to switch the content of the associated texture to the new content.
This means that one cannot keep old texture content around without
copying, so any feature relying on that will effectively be broken.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
This commit adds support for using a EGLDevice and EGLStreams for
rendering on top of KMS instead of gbm. It is disabled by default; to
enable it pass --enable-egl-device to configure.
By default gbm is first tried, and if it fails, the EGLDevice path is
tried. If both fails, mutter will terminate just as before.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
There is no way to pass any backend specific parameters to a
CoglFramebuffer until after it has been allocated by
cogl_framebuffer_allocate() (since this is where the winsys/platform
fields are initialized). This can make it hard to actually allocate
anything, if the platform depends on some backend specific data.
A proper solution would be to refactor the onscreens and framebuffers to
use a GObject based type system instead of the home baked Cogl one, but
that'll be left for another day. For now, allocate in two steps, one to
allocate the backend specific parts (MetaOnscreenNative), and one to
allocate the actual onscreen framebuffer (via
meta_onscreen_native_allocate()).
So far there is nothing that forces this separation, but in the future
there will, for example EGLDevice's need to know about the CRTC in
order to create the EGLSurface.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
A swap-buffers should never be issued when we are waiting for a flipped
callback, so instead of trying to handle a situation that sholud never
happen, warn instead.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
When a swap failed with EACCES (possibly due to VT switching), don't
mark the framebuffer as 'in use', so that it'll be cleaned up properly
and not set as current.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
For when there is no gbm available, for example when using
EGLDevice/EGLStream's, just fall back to the OpenGL texture based
cursor rendering path.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Drivers may be bad at guessing what is passed to eglGetDisplay, ending
up return non-functioning EGLDisplay's. Using eglGetPlatformDisplay
avoids this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Lets use a pbuffer surface as a dummy surface instead of a gbm based
one, so that we don't need to rely on the availability of gbm to create
a dummy surface when there is no need for it.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Separate gbm initialization from general renderer initialization. Do
this even though no other initialization is done for now; later there
will will be other types of rendering mode, initialized in their own
functions.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Add proc symbol loading and helper functions for calling them, dealing
with errors etc. So far no extension symbols are loaded, only the
infrastructure is there.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
In another step getting rid of the duplications introduced by Cogl,
use the equivalent GLib types where Cogl types previously used. While
CoglBool is not a typedef to gboolean, they are both typedefs to int,
and we already use GLib's TRUE/FALSE to set them.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Initialize the GError pointer used when creating the renderer. If an
error occurs, the error is expected to be NULL, otherwise it'll
misinterpreted as already set.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
The Clutter X11 backend can't drop CLUTTER_PEN_DEVICE and
CLUTTER_ERASER_DEVICE in favor of CLUTTER_TABLET_DEVICE without
losing information (as the driver will create one device for each).
So make MetaInputSettings cater for both sets of device types.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Its only purpose was caching settings applying to an stylus/tool, this
is now handled through ClutterInputDeviceTool evdev specific API, or
X device properties, so is not needed anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Enabling edge scrolling before disabling two finger would result in
edge scrolling not actually being enabled because two finger is still
enabled at the time and we bail out.
This patch moves this logic to common code for both the native and X
backends and fixes it by ensuring that both settings are never set at
the same time and still re-checking if edge scrolling should be
enabled after two finger scrolling gets disabled.
We also simplify the code by not checking for supported/available
settings since the underlying devices will just reject those values
and there isn't anything we can do about it here. It's the UI's job to
only show supported/available settings to users.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
Checking for supported methods isn't needed since libinput will just
error out and do nothing itself if a requested method isn't supported
and, in fact, this logic was preventing the enum values 0 from being
set.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
commit e2bfaf0751 does this:
g_hash_table_insert (cards,
g_udev_device_get_name (parent_device),
g_steal_pointer (&parent_device));
The problem is the g_steal_pointer call may happen before the
g_udev_device_get_name call leading to a crash.
This commit does the get_name call on an earlier line
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Right now we accept any character device that matches the glob card*.
That's fine, but we can be a little more specific by checking that
the devtype is what we expect.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Despite g_udev_client_new taking a list of subsystems, it doesn't
implicitly filter results to those subsystems.
This commit explicitly adds a subsystem match to make sure sound cards
don't end up in the resulting list of video cards.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Using the view's MetaMonitorInfo to find all the crtcs which should be
configured to display a given onscreen doesn't work unfortunately. The
association runs only the other way around, i.e. we need to go through
each crtc and find the ones corresponding to our monitor info.
https://bugzilla.gnome.org/show_bug.cgi?id=773115
If this isn't initialized and an idle watch gets instanced before
meta_idle_monitor_native_reset_idletime() gets called, that idle watch
would get triggered as soon as we hit the main loop.
This was causing gnome-session to go into idle mode at session start
thus making gnome-shell lock the screen.
In the past this bug was being masked by either logind emiting
session active signals or a stray input event making it through at
startup.
https://bugzilla.gnome.org/show_bug.cgi?id=772839
Going through the global mode pool and then checking if the mode is
available for a given output is pointless work since we can look at
the output's available modes directly.
This implicitly changes how we choose the default mode since, instead
of relying on the sort order of the global modes array, we now rely on
the sort order of the output modes array. Still not ideal, but at
least it makes more sense since the global array is essentially
unsorted.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.
Note that X doesn't account for these flags either for its mode
refresh rates.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
As the m format specifier doesn't consume any arguments, the number
of varargs currently doesn't match the number of specifiers; the
failed transform may be relevant, so include it in the message
instead of removing the excess argument.
backends/meta-input-settings.c:1245:27: error: format '%lx' expects
argument of type 'long unsigned int', but argument 3 has type 'guint64
{aka long long unsigned int}' [-Werror=format=]
Those will be unseen by g-s-d/g-c-c, so no settings will be written on
disk for those. Still, look up an ID correctly in this case instead of
crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=771628
This is needed to make the wayland backend react to configuration
changes until gnome-control-center is updated to use the
gsettings-desktop-schemas settings.
https://bugzilla.gnome.org/show_bug.cgi?id=771315
Some output devices only advertise their preferred mode even though
they're able to display others too. This means we can include some
common modes in each output's supported list.
This is particularly important for mirroring, since we can only mirror
outputs which are using the same resolution.
https://bugzilla.gnome.org/show_bug.cgi?id=744544
This signal allows interested parties to be notified of a new cursor
frame being painted regardless of whether it's being painted by the
backend directly or if it's a software rendered cursor frame handled
by clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=749913
Instead of hiding stage views enablement behind MUTTER_STAGE_VIEWS=1,
default to enable it, while making it possible to disable using
MUTTER_STAGE_VIEWS=0 instead.
https://bugzilla.gnome.org/show_bug.cgi?id=770366
Switch to the output naming logic used by the X server's modesetting
driver which, in particular, uses drmModeConnector's connector_type_id
instead of connector_id.
The kernel generates new connector_id's every time there are changes
which means we can't identify the same monitor on the same connector
after an hardware hotplug. Switching to connector_type_id fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=770338
We can only honor this properly in the MUTTER_STAGE_VIEWS=1 case. When using
the legacy view, software implemented transforms are only exposed if there is
only one output, as we can only transform the entire stage there.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The texture is only created if the view is transformed at the software level,
otherwise the texture is NULL, and rendering happens on the onscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The offscreen is given through the ::back-buffer property, the ClutterStageView
will set up the the CoglPipeline used to render it back to the "onscreen"
framebuffer.
The pipeline can be altered through the setup_pipeline() vfunc, so ClutterStageView
implementations can alter the default behavior of blitting from offscreen to
onscreen with no transformations.
All getters of "the framebuffer" that were expecting to get an onscreen have
been updated to call the right clutter_stage_view_get_onscreen() function.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The call to _cogl_framebuffer_winsys_update_size() results in no-op here,
as the framebuffer has already the right size when rebuilding the views.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Those will need a separate treatment from the modes that we eventually
support through "software", so split those into a separate enum so we
can can do the right thing when applying the configuration.
Also, add a helper function that returns the transform that the software
fallbacks should perform, which should be "normal" if the rotation is
already handled via hw.
The function applying the configuration has been modified to always set
a HW rotation mode (even if normal), when we come to support SW rotation
modes, we'll be relying on a normal transformation, so it will be
necessary to have mixed HW/SW managed transforms.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
As whether edge scrolling is enabled depends on whether two-finger
scrolling is disabled, make sure to update two-finger scrolling first.
Note that this only fixes the problem on startup. Changing the
settings in GSettings directly might cause an inconsistent state, but
the main UI for this setting, gnome-control-center, makes sure to
update two-finger scrolling before edge scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=769276
The scale will have been set to 1 no matter what when initializing the
MetaOutput since it at the time didn't have an CRTC assigned to it.
Now, when we assign the CRTC to the output, we need to update the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=769505
Allocate the offscreen stage view framebuffers up front; otherwise they
may get allocated after the viewport calculated by the stage is set,
which would cause the viewport to be incorrect until recalculated.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Support changing the mouse and trackball acceleration profile. This
makes it possible to for example disable pointer acceleration by
choosing the 'flat' profile.
This adds an optional dependency on gudev. Gudev is used by the X11
backend to detect whether a device is a mouse or not. Without gudev
support, the accel profile settings has have effect for mouse devices.
Trackball still uses the "strstr" approach, since udev doesn't support
tagging devices as trackball devices yet.
https://bugzilla.gnome.org/show_bug.cgi?id=769179
Add support for setting edge-scrolling separately from two-finger
scrolling. We now have 2 separate boolean settings for those, with the
Mouse panel in gnome-control-center allowing to set only one of those at
a time, but nothing precludes both being set in the configuration.
We need to handle:
- two-finger-scrolling-enabled and edge-scrolling-enabled settings both
being set.
- those 2 settings being change out-of-order
- two-finger-scrolling being set on a device that doesn't support it
- edge-scrolling-enabled on a device that doesn't support it
And the combinations of one touchpad supporting just one of edge
scrolling and two-finger scrolling and another vice-versa.
https://bugzilla.gnome.org/show_bug.cgi?id=768245
Instead of continuing eventually crashing with a segmentation fault due
to a missing renderer, make MetaBackend an GInitable, and gracefully
handle the failure to fully create the backend with an EXIT_FAILURE.
https://bugzilla.gnome.org/show_bug.cgi?id=769036
It does nothing at the moment, but can be hooked into MetaWaylandTabletPad
now. For X11, we need to trigger these for the pad events we receive from
the passive pad button grabs.
This function will be useful for the wayland implementation, because buttons
are mapped at the time of sending those through the wire.
As x11/wayland implementations differ here, this function will be useful for
the wayland implementation, as the action is handled lat
Some settings make no sense on external tablets, and others make
no sense in display/system-integrated tablets. Perform those checks
so we don't end up with possibly broken configuration.
Given that information defines largely how such devices are to be
configured, it makes sense to have that information at hand. A getter
has been also added for the places where it could be useful, although
it will require HAVE_LIBWACOM checks in callers too.
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
By creating a pending gbm/EGL surface pair, only setting it on
swap-buffers, we would draw onto a buffer on the old surface, then swap
the buffer from the new surface, causing the first frame after a
hot-plug always having no content.
This was in the past not very noticable since some non-deterministic but
frequent side effect in gnome-shell caused hot-plugging to always render
two new frames, but after "Introduce regional stage rendering", this
side effect did not occur as often, thus making it more visible.
This commit updates the current gbm/EGL surface pair before painting a
frame, so that when the frame is painted, the surface with the correct
size is used and the buffer from correct surface is swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Being a listener to a signal, it is inconvenient to enforce order of
execution between different signal listeners. If there are things in
the backend that should be updated before various other signal
handlers, make sure so is done by emitting the signal after having
explicitly notified the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Call a CoglContext "cogl_context", CoglDisplay "cogl_display" and
CoglRenderer "cogl_renderer" so that they won't be confused with
ClutterContext, MetaDisplay and MetaRenderer etc.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make the cogl vfunc functions have names that are globally
discoverable. Calling the same function in every backend the same name
causes code navigation tools to not function properly. Rename the
affected functions to closer correspond to the style mutter uses.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This commit completes the move of monitor logic to the monitor
mangager. The renderer now only deals with framebuffers, asking the
monitor manager to do the crtc flip tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Let MetaMonitorManagerKms manage KMS modes. This lets us pass less
state to MetaRendererNative. Instead let MetaMonitorManager tell the
monitor manager when it should set the mode and with what framebuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Absorb the CoglRendererKMS struct into MetaRendererNative. The gbm
device initialization is moved earlier so that the renderer fails to
initialize if the gbm device creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Use the correct pointer types for cogl objects. This avoids warnings
when including the cogl headers doesn't result in all the cogl types
being typedefs to void.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.
This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.
Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
Sadly, GLib's autoptr cleanup macros cannot be detected by the C
pre-processor, because they generate a function. This means that we are
forced to bump up the dependency on GLib 2.49, in order to build against
a newer version of gdbus-codegen.
Starting from GLib 2.49, the gdbus-codegen tool automatically generates
the auto cleanup symbols for the GDBus proxy and skeleton interfaces.
Since we don't depend on a specific version of GLib we need to
conditionally generate the auto cleanup symbols in case an older version
of gdbus-codegen is used when building Mutter.
This commit unbreaks the build under GNOME Continuous, which has been
failing with:
usr/include/glib-2.0/glib/gmacros.h:415:43: error: redefinition of 'glib_autoptr_cleanup_Login1Session'
#define _GLIB_AUTOPTR_FUNC_NAME(TypeName) glib_autoptr_cleanup_##TypeName
^
[...]
/usr/include/glib-2.0/glib/gmacros.h:415:43: note: previous definition of 'glib_autoptr_cleanup_Login1Session' was here
./meta-dbus-login1.h:82:1: note: in expansion of macro 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
G_DEFINE_AUTOPTR_CLEANUP_FUNC (Login1Session, g_object_unref)
^
Wrap the existing laptop_display_is_on() method in a public function
that gnome-shell can use to query whether a builtin output is present
and enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=765267
While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible (i.e. any CoglError
that is not a malformed blend string).
https://bugzilla.gnome.org/show_bug.cgi?id=765058
The previous configuration might not apply because the number of
enabled outputs when trying to apply it might have changed. This isn't
a bug so we shouldn't assert. Instead, we can handle it by falling
back as we would if we didn't have a previous configuration to start
with.
https://bugzilla.gnome.org/show_bug.cgi?id=764286
On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.
Commit 4bebc5e5fa introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.
https://bugzilla.gnome.org/show_bug.cgi?id=763159
It indirectly triggers expensive operations in gnome-shell
(js/ui/keyboard.js), which turns out too expensive if we happen to operate
the shell simultaneously with 2 devices that will trigger the operations
there.
So just rate limit the signal emission, defer to an idle and just emit
the last device gotten. Worst that will happen is that we may possibly
emit the signal on the same device consecutively.
https://bugzilla.gnome.org/show_bug.cgi?id=753527
If we rely on getting back an input event with the warped pointer
coordinates, we might draw a frame with the old coordinates if we warp
during the paint phase. Avoid that by moving the cursor immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
In order to reuse some vector math for pointer confinement, move out
those parts to its own file, introducing the types old types
"MetaVector2" and "MetaLine2" outside of meta-barrier-native.c, as well
as introducing MetaBorder which is a line, with a blocking direction.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Add support for sending relative pointer motion deltas to clients who
request such events by creating wp_relative_pointer objects via
wp_relative_pointer_manager.
This currently implements the unstable version 1 from wayland-protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Instancing a gbm device without initializing EGL with it means that it
won't be able to import wl_drm buffers. Instead, let's re-use cogl's
gbm device which is already properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=761557
This fixes an issue analogous to bug 760330 for the X11 backend,
except on this backend we wouldn't crash accessing free'd memory.
Instead we're leaking watches since we steal them from the hash table
which means that when they're removed in
_meta_idle_monitor_watch_fire() they're no longer there and thus
they're never free'd.
https://bugzilla.gnome.org/show_bug.cgi?id=760476
Right now the XSync based idle monitoring code, will fetch all active
watches into a list, and then call their watch callbacks one by one
as necessary. If one watch callback invalidates another watch, the
list will contain free'd memory.
This commit makes sure to consult the hash table after ever call
of a watch callback, to ensure mutter never looks at freed memory.
Fixes crash reported on IRC by Laine Stump with his synergy setup.
https://bugzilla.gnome.org/show_bug.cgi?id=760330
We can know the rotation modes supported by the driver, so
export these as our supported modes, and ensure these modes
are honored on the CRTC primary plane upon apply_configuration().
It is worth noting however that not all hardware will be
capable of supporting all rotation modes (in fact, most of
them won't). A driver independent solution should be in
place to back up the rotation modes unsupported by the
drivers, so this is still a partial solution.
The cursor renderer has also been changed to default to
software-based rendering anytime the cursor enters a
rotated CRTC. Another solution would be actually rotating
the DRM cursor planes, but then it requires applying rotation on
these per-CRTC, and actually transforming the pointer position by
the output matrix. This brings marginal gains, so we use the
"sw" rendered cursor, which will be transformed together with
the primary plane.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
GDesktopTouchpadScrollMethod was used instead of GDesktopTouchpadClickMethod
which became visible now that the former has been removed from
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
When the touchpad is two-finger scrolling capable, always enable it.
When the touchpad only supports edge scrolling (usually older devices, and
usually smaller devices), allow disabling the edge scrolling.
This requires a newer gsettings-desktop-schemas as the scroll-method key
was removed, and the edge-scroll-enabled key added.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
The max potential number of logical monitors (i.e. MetaMonitorInfos)
is the number of CRTCs, not the number of outputs.
In cases where we have more enabled CRTCs than connected outputs we
would end up appending more MetaMonitorInfos to the GArray than the
size it was initialized with which means the array would get
re-allocated rendering invalid some MetaCRTC->logical_monitor pointers
assigned previously and thus ending in crashes later on.
https://bugzilla.gnome.org/show_bug.cgi?id=751638
On the wire, Wayland specifies the refresh rate in milliHz. Mutter sends
the refresh rate in Hz, which confuses clients, e.g. weston-info:
interface: 'wl_output', version: 2, name: 4
mode:
width: 2560 px, height: 1440 px, refresh: 0 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 5
mode:
width: 3200 px, height: 1800 px, refresh: 0 Hz,
flags: current preferred
and xrandr:
XWAYLAND0 connected 2560x1440+3200+0 600mm x 340mm
2560x1440@0.1Hz 0.05*+
XWAYLAND1 connected 3200x1800+0+0 290mm x 170mm
3200x1800@0.1Hz 0.03*+
Export the refresh rate in the correct units. For improved precision,
perform the KMS intermediate calculations in milliHz as well, and
account for interlaced/doublescan modes.
This is also consistent with what GTK+ expects:
timings->refresh_interval = 16667; /* default to 1/60th of a second */
/* We pick a random output out of the outputs that the window touches
* The rate here is in milli-hertz */
int refresh_rate = _gdk_wayland_screen_get_output_refresh_rate (wayland_display->screen,
impl->outputs->data);
if (refresh_rate != 0)
timings->refresh_interval = G_GINT64_CONSTANT(1000000000) / refresh_rate;
Where the 'refresh_rate' given is exactly what's come off the wire.
1000000000/60000 comes out as 16667, whereas divided by 60 is ...
substantially less.
https://bugzilla.gnome.org/show_bug.cgi?id=758653
On Odroid U2 (exynos4412) the drm device is not bound to pci.
Open the detection to platform device of the drm subsystem, exclusive of
control devices.
https://bugzilla.gnome.org/show_bug.cgi?id=754911
Failing to initialize Clutter isn't something it's useful to report
into automatic bug tracking systems or get a backtrace for - in fact,
the most common case is that DISPLAY is unset or points to a
non-existent X server. So simply exit rather than calling g_error().
https://bugzilla.gnome.org/show_bug.cgi?id=757311
g_error() is the wrong thing to do when, for example, we can't find the
DRM device, since Mutter should just fail to start rather than reporting
a bug into automatic bug tracking systems. Rather than trying to decipher
which errors are "expected" and which not, just make all failure paths
in meta_launcher_new() return a GError out to the caller - which we make
exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=757311
The qxl kms driver has a bug where the cursor gets hidden
implicitly after a drmModeSetCrtc call.
This commit works around the bug by forcing a drmModeSetCursor2
call after the drmModeSetCrtc calls.
This is pretty hacky and won't ever go upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=746078
Ubuntu ships a patch in the X server that makes the group switch
keybindings only work on key release, i.e. the X server internal group
locking happens on key release which means that mutter gets the
XKB_KEY_ISO_Next_Group key press event, does its XLockGroup() call
with a new index and then, on key release, the X server moves the
index further again.
We can work around this without affecting our behavior in unpatched X
servers by doing a XLockGroup() every time we're notified of the
locked group changing if it doesn't match what we requested.
https://bugzilla.gnome.org/show_bug.cgi?id=756543
We might get modes in XRROutputInfos that aren't in the
XRRScreenResources we get earlier. This always seems to be transient,
i.e. when it happens, the X server will usually send us a follow up
RRScreenChangeNotify where we then get a "stable" view of the world
again.
In any case, when these glitches happen, we end up with NULL pointers
in the MetaOutput->modes array which makes us crash later on. This
patch ensures that doesn't happen.
https://bugzilla.gnome.org/show_bug.cgi?id=756660
Calling queue_redraw() in _force_update() is not needed because
update_cursor() will do this when needed, i.e. when switching between
hardware cursor and texture cursor, or when drawing with texture cursor.
There is also no need to force _native_force_update() because
update_cursor() will cover this as well when needed. When not changing
cursor but only the gbm_bo, the "dirty" boolean on the gbm_bo will
trigger a redraw.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
This commits refactors cursor handling code and plugs in logic so that
cursor sprites changes appearance as it moves across the screen.
Renderers are adapted to handle the necessary functionality.
The logic for changing the cursor sprite appearance is done outside of
MetaCursorSprite, and actually where depends on what type of cursor it
is. In mutter we now have two types of cursors that may have their
appearance changed:
- Themed cursors (aka root cursors)
- wl_surface cursors
Themed cursors are created by MetaScreen and when created, when
applicable(*), it will extend the cursor via connecting to a signal
which is emitted everytime the cursor is moved. The signal handler will
calculate the expected scale given the monitor it is on and reload the
theme in a correct size when needed.
wl_surface cursors are created when a wl_surface is assigned the
"cursor" role, i.e. when a client calls wl_pointer.set_cursor. A
cursor role object is created which is connected to the cursor object
by the position signal, and will set a correct texture scale given what
monitor the cursor is on and what scale the wl_surface's active buffer
is in. It will also push new buffers to the same to the cursor object
when new ones are committed to the surface.
This commit also makes texture loading lazy, since the renderer doesn't
calculate a rectangle when the cursor position changes.
The native backend is refactored to be triple-buffered; see the comment
in meta-cursor-renderer-native.c for further explanations.
* when we are running as a Wayland compositor
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Use a specialized cursor renderer when running as a nested Wayand
compositor. This new renderer sets an empty X11 cursor and draws the
cursor as part of the stage using the generic cursor renderer drawing
path.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
This fixes build error caused by commit 614d6bd. We can simply remove
the usage of meta-wayland.c functions in non-wayland build because
META_BACKEND_X11_MODE_NESTED is only used in wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
There were lots of code handling the native renderer specific cases;
move these parts to the renderer. Note that this causes the X11 case to
always generate the texture which is a waste of memory, but his
regression will be fixed in a following commit.
The lazy loading of the texture was removed because it was eventually
always loaded anyway indirectly by the renderer to calculate the
current rect.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
There is nothing special about the private API which only consists of
getters for renderer specific backing buffer. Lets them to the regular
.h file and treat them as part of the normal API.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
