- Mar 01, 2018
-
-
Administrator authored
-
- Feb 07, 2018
-
-
Jonas Ådahl authored
This was done by the clutter X11 backend before prior to introducing MetaRenderer, but during that work, enabling of said extension was lost. Let's turn it on again. https://bugzilla.gnome.org/show_bug.cgi?id=739178
-
Jonas Ådahl authored
We don't introspect CoglRenderer, so we shouldn't introspect API using it either. https://bugzilla.gnome.org/show_bug.cgi?id=739178
-
- Feb 01, 2018
-
-
Carlos Garnacho authored
Opening and closing the device may result into XI2 grabs being cut short, resulting into pad buttons being rendered ineffective, and other possible misbehaviors. This is an XInput flaw that fell in the gap between XI1 and XI2, and has no easy fix. It pays us for mixing both versions, I guess... Work this around by keeping the XI1 XDevice attached to the ClutterInputDevice, this way it will live long enough that this is not a concern. Investigation of this bug was mostly carried by Peter Hutterer, I'm just the executing hand. #7 Closes: #7
-
- Jan 27, 2018
-
-
- Jan 23, 2018
-
-
Using 800x600 as minimum logical size is very 4:3 thinking, while a lot of modern devices are 16:9. The specific reason for this commit is to allow 1.5 scaling at mini-laptops (clamshell devices) with e.g. a 5.5" 1280x720 screen. Given that this device has a keyboard, one obviously is not holding it very close to ones eyes and at 220 dpi that means the text is too small at scale 1.0. For one real world example of such a device see: https://en.wikipedia.org/wiki/GPD_Win https://bugzilla.gnome.org/show_bug.cgi?id=792765
-
- Jan 21, 2018
- Jan 18, 2018
-
-
Olivier Fourdan authored
Issuing a shortcut inhibit request for a surface without a window set will lead to a crash when trying to show the shortcut inhibitor dialog. In such a case, it's safer to deny the request. https://bugzilla.gnome.org/show_bug.cgi?id=792599
-
- Jan 12, 2018
-
-
Jonas Ådahl authored
It's "libinput Tapping Drag Enabled", not "libinput TappingDrag Enabled". https://bugzilla.gnome.org/show_bug.cgi?id=775755
-
Jonas Ådahl authored
We might receive touch events for unknown touch points, for example when starting mutter while touching the screen (resulting in no touch-down event ever being received). Avoid crashing when this happens by just dropping these events on the floor. https://bugzilla.gnome.org/show_bug.cgi?id=791371
-
- Jan 09, 2018
-
-
Wayland clients using the wl_shell interface were never receiving mouse input. It meant they also couldn't be raised with a click. This was because the call to meta_wayland_surface_set_window for wl_shell surfaces did nothing while surface->window == window already. As such, it never called clutter_actor_set_reactive() and the wl_shell window remained a non-reactive actor. Just make sure surface->window isn't already set before calling meta_wayland_surface_set_window so it can actually do what it's meant to. https://bugzilla.gnome.org/show_bug.cgi?id=790309
-
- Dec 31, 2017
-
-
Matej Urbančič authored
-
- Dec 22, 2017
-
-
Georges Basile Stavracas Neto authored
Raising and lowering windows in tandem without a proper grouping mechanism ended up being more annoying than functional. This reverts commit e76a0f56.
-
- Dec 21, 2017
-
-
Carlos Garnacho authored
If input happens to be grabbed somewhere along the shell, and ungrabbed while a touch operation is ongoing, the wayland bits will happily start sending wl_touch.update events from an undeterminate point, without clients having ever received wl_touch.down for that id. Consider those touches grabbed for the entirety of their lifetime, if wl_touch.down wasn't received by the client, no other events will. https://bugzilla.gnome.org/show_bug.cgi?id=776220
-
- Dec 20, 2017
-
-
Marco Trevisan authored
When capture_view* functions are called with the paint flag set to TRUE, we need to setup the framebuffer, however this was happening after setting up the viewport, while the viewport needs the framebuffer to be valid when calling cogl_set_viewport. https://bugzilla.gnome.org/show_bug.cgi?id=791809
-
Jonas Ådahl authored
The reason why multiple keycodes could be mapped to a single keysym was to support having both KEY_FAVORITES and KEY_BOOKMARK map to XF86Favorites. However, iterating through all layout levels adding all key codes has severe consequences on layouts with levels that map things like numbers and arrow. The result is that keybindings that should only have been added for keycodes from the first level, are replaced by some unexpected keycode where the same keysym was found on another level. An example of this is the up-arrow key and l symbol. Normally you'd find both the up-arrow symbol and the l symbol on the first level and be done with it. However, on the German Neo-2 layout, layout level 4 maps the KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow. Which ever gets to take priority is arbitrary, but for this particular case KEY_E incorrectly mapped to up-arrow instead of the l symbol, causing the keyboard shortcut Super+l, which would normally lock the screen, to trigger the workspace-up (Super+up-arrow) key binding. https://bugzilla.gnome.org/show_bug.cgi?id=789300
-
- Dec 15, 2017
-
-
Rui Matos authored
This tries to avoid wayland clients getting disconnected for binding to a wl_output that we already destroyed which is a known protocol race condition, see https://phabricator.freedesktop.org/T7722 . https://bugzilla.gnome.org/show_bug.cgi?id=789070
-
- Dec 14, 2017
-
-
Benjamin Berg authored
The recent commit 6dd28bd2 "poll() on KMS fd on EAGAIN" backported error handling code that does not apply to the gnome-3-26 branch. https://bugzilla.gnome.org/show_bug.cgi?id=791024
-
- Dec 11, 2017
-
-
Benjamin Berg authored
When drmHandleEvent() returns an error and errno is set to EAGAIN, instead of ending up in a busy loop, poll() the fd until there is anything to read. This is a simple backport of commit 406359bb. https://bugzilla.gnome.org/show_bug.cgi?id=791024
-
- Dec 01, 2017
-
-
Marco Trevisan authored
When the top window actor is destroyed, we need to make sure that all its references are removed or it could be picked again in next windows sync, causing crashes. Since the window might or might not be destroyed when removed (depending weather animations are in progress over it or not), it's just safer to wait it to be destroyed before cleaning up any of its reference. https://bugzilla.gnome.org/show_bug.cgi?id=791006
-
- Nov 30, 2017
-
-
Jonas Ådahl authored
We only counted configured monitors and whether the config was applicable (could be assigned), howeverwe didn't include disabled monitors when comparing. This could caused incorrect configurations to be applied when trying to use the previous configuration. One scenario where this happened was one a system with one laptop screen and one external monitor that was hot plugged some point after start up. When the laptop lid was closed, the 'previous configuration' being the configuration where only the laptop panel was enabled, passed 'is-complete' check as the number of configured monitors were correct, and the configuration was applicable. Avoid this issue by simply comparing the configuration key of the previous configuration and the configuration key of the current state. This correctly identifies a laptop panel with the lid closed as inaccessible, thus doesn't incorrectly revert to the previous configuration. https://bugzilla.gnome.org/show_bug.cgi?id=788915
-
Jonas Ådahl authored
When deriving the list of disabled monitors when creating new monitors configs, don't include the laptop panel if the lid is currently closed, as we consider the laptop panel nonexistent when the laptop lid is closed when it comes to configuration. The laptop panel connector(s) will either way be appropriately disabled anyway, as the field listing disabled monitors in the configuration do not affect actual CRTC/connector assignments. https://bugzilla.gnome.org/show_bug.cgi?id=788915
-
- Nov 29, 2017
-
-
- Nov 26, 2017
-
-
- Nov 25, 2017
-
-
Aurimas Černius authored
-
- Nov 22, 2017
-
-
Rui Matos authored
There's no good reason to allow this and it allows g-c-c to properly show that such a configuration doesn't work. https://bugzilla.gnome.org/show_bug.cgi?id=790336
-
- Nov 17, 2017
-
-
While the X11 backend gets its font settings from XSettings, the native backend did not use any user font preferences till now. So all shell fonts were rendered with grayscale un-hinted, which some people describe as "blurry text in Wayland sessions". Although it's somewhat confusing using the "xsettings" schema on eglnative, this is consistent with what GTK does already for its Wayland backend. It is also documented here: https://wiki.gnome.org/Initiatives/Wayland/GTK%2B#XSettings https://wiki.gnome.org/Initiatives/Wayland/gnome-settings-daemon#xsettings No more blurry shell text in Wayland sessions. https://bugzilla.gnome.org/show_bug.cgi?id=645433
-
Carlos Garnacho authored
Unused variable definition. The fixup didn't make it to the previous commit.
-
Carlos Garnacho authored
We must emit ::dnd-leave to pair the ::dnd-enter that shall be emitted whenever the plugin grab begins, otherwise we leave listeners unable to clean up if the plugin begins and ends a grab while there is an ongoing DnD operation. https://bugzilla.gnome.org/show_bug.cgi?id=784545
-
-
- Nov 15, 2017
-
-
-
Marek Cernocky authored
-
- Nov 14, 2017
-
-
- Nov 13, 2017
-
-
- Nov 11, 2017
-
-
- Nov 10, 2017
-
-
Piotr Drąg authored
-
Piotr Drąg authored
-
Olivier Fourdan authored
gnome-control-center uses this to list the keybindings, without this users cannot change the default key combo to restore shortcuts. https://bugzilla.gnome.org/show_bug.cgi?id=789386
-
Olivier Fourdan authored
Change the default key combo to re-enable normal keyboard shortcuts processing while a shortcut inhibitor is in effect to Super+Escape as primary system modifier key should be Super. This should reduce the risk of potential conflict with other shortcuts. https://bugzilla.gnome.org/show_bug.cgi?id=789386
-