When running as a native compositor, we can just do that. However, the
previous code must stay for whenever it's run as a X11 client.
Additionally, the fallback switch{} that transforms clutter 1-indexed
buttons into input.h event codes had to be adapted to the change introduced
in clutter commit 83b738c0e, where the 4-7 button range is kept clear for
compatibility with the X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758239
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
If a client only ever sets the hint on window creation we'd never pick
the value. Also, include override redirect windows since the hint is
relevant to them too.
https://bugzilla.gnome.org/show_bug.cgi?id=758544
The X11 part of the GDK backend takes into account the scaling factor of its
window when resizing the underlying X11 objects. We need to do the same for
Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=755245
This is now stored as platform data in the ClutterEvent, so can
be retrieved with the clutter_evdev_event_get_event_code() call
that's been added to the evdev backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
Device managers can now implement the ClutterEventExtender interface
that allows them to set their own data to events, make the backend call
those implementations if the device manager implements the interface.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
This normally belonged to the ClutterBackend, however there's device
managers (eg. evdev) that are somewhat detached from the backend, so
need to bridge this somehow.
This allows device managers to implement these bits that were usually
responsibility of the ClutterBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=758238
On X11 those were skipped, so additional pointer buttons would come up
as button >= 8 events. Do here the same, so we remain compatible across
backends.
https://bugzilla.gnome.org/show_bug.cgi?id=758237
When managing window, we queue showing the window.
Under wayland, if we commit surface quickly enough,
the showing is unqueued and commit procedure takes care
of mapping and placing the window. In the oposite case,
queue is processed before client sets all we need and
then we have wrong size of window, which leads to broken placement.
Therefore force placement in queue only if the window should already
be mapped. If it is not mapped, we don't care where it is anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751887
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
The default theme started to use them in GTK+ commit 371f50, so
we need to update the style contexts to keep matching the style
of client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=757101
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
If we get EACCES from drmPageFlip we're not going to get
a flip event and shouldn't wait for one.
This commit changes the EACCES path to silently ignore the
failed flip request and just clean up the fb.
https://bugzilla.gnome.org/show_bug.cgi?id=756926
In a HiDPI environment, all gtk+ apps will report a 2 x 2 size
increment to avoid odd size. But that does not mean they are
resizing in cells like terminals, so they resize popup should
not be shown.
Ideally, we should ignore <= scale x scale increments, but in
practice scale is 1 or 2, and even in a lo-dpi setting a 2 x 2
increment makes little sense so let's keep the patch simple.
https://bugzilla.gnome.org/show_bug.cgi?id=746420
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
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
