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
Before, it used to be in the screen, but now,
meta_cursor_reference_from_theme can never fail. Move it to where we
load the images from the cursor name.
Since mutter has two X connections and does damage handling on the
frontend while fence triggering is done on the backend, we have a race
between XDamageSubtract() and XSyncFenceTrigger() causing missed
redraws in the GL_EXT_X11_sync_object path.
If the fence trigger gets processed first by the server, any client
drawing that happens between that and the damage subtract being
processed and is completely contained in the last damage event box
that mutter got, won't be included in the current frame nor will it
cause a new damage event.
A simple fix for this would be XSync()ing on the frontend connection
after doing all the damage subtracts but that would add a round trip
on every frame again which defeats the asynchronous design of X
fences.
Instead, if we move fence handling to the frontend we automatically
get the right ordering between damage subtracts and fence triggers.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
While we shouldn't normally receive crossing events for any windows
except the stage when running nested, we do in case we hold a pointer
grab - just ignore those events instead of taking down the user's
session.
If GL advertises this extension we'll use it to synchronize X with GL
rendering instead of relying on the XSync() behavior with open source
drivers.
Some driver bugs were uncovered while working on this so if we have
had to reboot the ring a few times, something is probably wrong and
we're likely to just make things worse by continuing to try. Let's
err on the side of caution, disable ourselves and fallback to the
XSync() path in the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.
Let's fall back to the stringified product code and serial number in
that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752673
There's a chance the icon will be animated, so store the XcursorImages
instead of the individual XcursorImage, and handle that as a nimages=1
special case.
API to "tick" a cursor animation, and retrieve current frame timing
information has been added.
https://bugzilla.gnome.org/show_bug.cgi?id=752342
Tracking back from the monitor to the output every time we need to
figure out the scale of a window on a monitor is inconvenient, so
propagate the scale from the output to the monitor it is associated
with.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Enable a user to test and debug multi output configurations on Wayland
without having the available hardware by enabling some basic
configuration of the dummy monitor manager.
Currently available configuration options are:
MUTTER_DEBUG_NUM_DUMMY_MONITORS - to set the number of monitors
MUTTER_DEBUG_DUMMY_MONITOR_SCALES - to configure the monitor scales
See src/backends/meta-monitor-manager-dummy.c for detailed description
of the available configuration parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=747089
Before submitting a new scroll mode, click method or sendevents mode check if
the value is supported by the device. This avoids BadValue errors when setting
two-finger scrolling on single-finger touchpad devices since we can't easily
handle BadValue (see 9747277b)
https://bugzilla.gnome.org/show_bug.cgi?id=750816
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We should not be setting random output properties like this.
Use the function we just introduced to only set the underscan flag when
it's actually supported.
So that clients such as the control center can decide to hide an
underscanning checkbutton when the output does not support it.
Support in the KMS / native backend to come later...
It seems that fglrx sometimes gives us absolute junk when requesting the
outputs, and if we don't trap errors, we'll just crash when trying to
configure a junk output. Use xcb so errors simply get ignored.
For enter / leave events, which we use in the UI code, we need to make
sure that these coordinates are root-relative as well, otherwise the
cursor when entering frames might be incorrect.
If we're running as a nested compositor, we must not attempt to
passive grab on the root window, and we should be setting the
touch event mask on the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=751036
This way, we won't be hit with BadValue errors if we set it to a value
outside the X device's range. This can happen for touchpads without
two-finger scrolling, for instance.
Instead of selecting the first drm mode as the preferred mode, select the
first drm mode marked as preferred. If there are no modes marked as
preferred, revert to the old behaviour and select the first mode.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
Read the drm layout properties suggested_X, suggested_Y and
hotplug_mode_update and transfer them to the meta layer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
The monitors info structure is created from the tiled outputs
and this is used as the central storage for info about a monitor
as opposed to the output state.
It appears at least the EDID mm w/h is for the whole monitor and
not per tile.
this just adds backend support for retrieving the tile
information from X11 (randr 1.5) and native backends.
It stores the tiling information into the output struct.
This makes gnome-settings-daemon turn on the backlight and
gnome-shell's screen shield animate.
Note that on X sessions, gnome-settings-daemon uses the same upower
property to force an innocuous key event into the X server so that the
idle time gets reset since Xorg doesn't do this itself on lid events.
https://bugzilla.gnome.org/show_bug.cgi?id=749076
We'll need to get the value of some properties. Fail if the number of
items returned is less than we expect and warn if it exceeds it so
that we can easily find out if items are added to a property later and
fix it.
Some DRM drivers have added a consistent set of properties that
allow compensating for the overscan that some TVs do, without the
user being able to disable.
There is copy&pasted code in set_scroll_button, which is apparently
wrong, because it is trying to set scroll method instead of the scroll
button...
https://bugzilla.gnome.org/show_bug.cgi?id=747967
Since 8769b3d55, the checks performed on which update_* function was
called for each device got quite more lax, leading to failed asserts
on code that assumed the previous behavior.
Change update_[mouse|touchpad|trackball]_* to bail out early if the
device received has not the right type, and remove the asserts.
https://bugzilla.gnome.org/show_bug.cgi?id=747886
This seems nicer/tidier than the current X11 (center on the span of all
monitors) or native (so close to the activities corner it's hard not
to trigger it) platform behaviors.
This code also takes over the native-specific pointer warping that
happens when the pointer was over a removed output.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
This function returns the monitor_info index corresponding to the given
coordinates, or -1 if none is found at that point. The native backend
has been changed in places where it could make use of this function.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
clutter currently never emits activated or deactivated signals on
the stage object when using the EGL backend. Since the stage never
gets activated, accessibility tools, like orca, don't work.
This commit makes mutter take on the responsibility, by tracking
when the stage gains/loses focus, and then synthesizing stage
CLUTTER_STAGE_STATE_ACTIVATED state events.
A limitation of this approach is that clutter's own notion of
the stage activeness won't reflect mutter's notion of the
stage activeness. This isn't a problem, in practice, and can
be addressed in the medium-term after making changes to
clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=746670
The enums are swapped currently, because for edge scroll is enabled two finger
scroll and similary for two finger scroll is enabled edge scroll, what is
apparently wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=746870
On startup, the cursor is kept hidden if there's any touchscreen available.
If the device that was last interacted is removed, we check on available
pointing devices though, so we don't possibly hide the pointer if there are
further mice/touchpads/etc.
Devices being added don't update cursor visibility, we wait for the user
interacting with those instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
On X11, calling this function on meta_display_handle_events() will not catch
mouse events happening over clients, so poke directly in the backend for
XI_DeviceChanged events, which mutter will get on device switches.
The code has been slightly refactored so we deal with XIEvents at a single
handle_input_event() function.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
This function can be used to trigger changes depending on the device type
that is currently emitting the events. So far, it is used to switch cursor
visibility on/off on touchscreen interaction.
A "last-device-updated" signal has also been added, in order allow hooking
other behavior changes (eg. OSK) when the last device changes.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
The initial pointer position is set by clutter. At the moment it
is the point 16x16 on the screen. But this point is not always
in the visible area on monitors (the monotors can be arranged in
many different ways).
https://bugzilla.gnome.org/show_bug.cgi?id=745752
Otherwise the pointer might be "lost" outside the visible area. Note
that the constraining code only ensures the pointer doesn't leave the
visible area but if the pointer is already outside because the rug was
pulled under it then it doesn't do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=745121
DRM objects like connectors and encoders might change at any time, in
particular they might become invalid between drmModeGetResources() and
getting the actual objects in which case they'll be NULL. Be defensive
against that.
Note that, if this happens, we should get another udev event soon
which will cause us to update our state.
https://bugzilla.gnome.org/show_bug.cgi?id=745476
To make the nested compositor mode work again after "backends/native:
Calculate the output scale in here", set the scale when creating the
dummy output.
https://bugzilla.gnome.org/show_bug.cgi?id=745401
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
When running as a dispay server pointer barriers are a server side
feature and requires no client interaction of any sort. This patch
implements pointer barriers that can be used when running as a display
server on the native backend. Running as a display server using the X11
backend is currently not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
For each device that can be mapped (touchscreens, tablets), the output
will be fetched from settings and matched with the currently connected
ones. If a match is found, the device matrix will be found out from the
output configuration and set on the device.
This is also updated both individually for newly connected devices, and
collectively on output configuration changes.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This goes through modifying XI2 device properties, either common ones (eg.
set on every device) or those specific to the libinput X11 driver. Keyboard
repeat/rate are set through core and XKB APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This object internally keeps track of the relevant input configuration,
and goes through its vmethods in order to apply the configuration on the
backend-specific devices.
So far, only mouse/touchpad settings are actually attached to GSettings
changes. ::set_matrix(), meant for tablets/touchscreens, is not hooked
yet.
One caveat is that meta_input_settings_create() may return NULL if the
backend does not own the windowing system (wayland nested on X11 being
the one case), and thus device settings can't be changed freely.
https://bugzilla.gnome.org/show_bug.cgi?id=739397
This patch removes the X11 specific code from MetaBarrier and creates an
abstraction layer MetaBarrierImpl. The existing X11 implementation is
moved to a new GObject MetaBarrierImplX11 implementing the abstract
interface MetaBarrierImpl which is instantiated by MetaBarrier when
supported.
While at it, move it to backends/ and properly name the files.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
EDID parsing has been refactored to a common meta_output_parse_edid()
function, which ensures the extracted information is the same on both KMS
and X11 backend, so it can be used consistently on eg. settings values.
https://bugzilla.gnome.org/show_bug.cgi?id=742882
