summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump version to 3.22.43.22.4Florian Müllner2017-04-112-1/+15
| | | | Update NEWS.
* xwayland: Fix lockfile size confusionDaniel Stone2017-04-111-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | Similarly to Weston (where this code originated), there were two errors in the X11 lockfile handling. Firstly, after reading 11 characters from the lock file (which could have been placed by any process), there was no guarantee of NUL-termination, meaning strtol could've theoretically run off the end of the string. Secondly, whilst writing the new lock, the trailing NUL byte was not correctly accounted for. The size passed as an input to snprintf takes the maximum size of the string including the trailing NUL, whilst the return (and the input to write) gives the actual size of the string without the trailing NUL. The code did attempt to check the return value, however snprintf returns the size of the _potential_ string written, before snprintf culls it, so this was off by one, and the LF was not being written. Signed-off-by: Daniel Stone <daniels@collabora.com> https://bugzilla.gnome.org/show_bug.cgi?id=774613
* frames: use correct variable in for loop assignmentShantanu Goel2017-04-111-1/+1
| | | | | | | | | | | | | | | | | | | update_context_styles is using the wrong variable when advancing to the next key in the hash table which can cause an infinite loop if # of variants is ever greater than 1. This problem was originally reported here: https://github.com/linuxmint/Cinnamon/issues/5254 The following patch was commited in Mint: https://github.com/linuxmint/muffin/commit/6120bdde This patch is just a shorter version of the Mint patch and they deserve all the credit for the idea. https://bugzilla.gnome.org/show_bug.cgi?id=780254
* xwayland: Raise the dnd window each timeOlivier Fourdan2017-03-111-1/+1
| | | | | | | | | | | If the dnd window ends up lower in the overall stack than the window it's supposed to fence, the drop might end up in some other window underneath the expected target window. Maps and raises the dnd window each time it's shown so that it's always placed above. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=779800
* xwayland: Use timestamp from XdndPosition/Drop on XConvertSelectionCarlos Garnacho2017-03-111-1/+6
| | | | | | | | QT apps reject DnD if the timestamp received in the SelectionRequest event isn't the same it gave in XdndPosition/Drop client messages. Bookkeeping and using it in XConvertSelection makes it happy again. https://bugzilla.gnome.org/show_bug.cgi?id=779757
* xwayland: Check MetaDndBridge focus_window when updating X11 proxy windowCarlos Garnacho2017-03-111-3/+3
| | | | | | | | | | | | | | We are keeping accounting of the focus window as seen by the DnD bridge right here, so use it instead of the MetaWaylandDragGrab focus as it may lag behind the real focus (i.e. till the drag source notices the window and sends XdndEnter to it). This leads to the window trying to be repositioned more often than necessary when the drag source takes long to send the XdndEnter client message, and maybe not repositioned at all if the pointer leaves the surface while no XdndEnter message was received. https://bugzilla.gnome.org/show_bug.cgi?id=763246
* xwayland: Release xdnd grabs ASAPCarlos Garnacho2017-03-111-3/+24
| | | | | | | | | | | | | | We currently wait for the selection being cleared by the drag source, which might not happen on not quite educated clients. This may leave a stuck XDND grab in the compositor side. We can actually do a bit better, and clear the grab if: 1) The drag source sent XdndDrop to the wayland drag destination. 2) There's no accepting drag destination and all pointer buttons are released. 3) As usual, whenever the drag source clears the selection data https://bugzilla.gnome.org/show_bug.cgi?id=763246
* Update Scottish Gaelic translationGNOME Translation Robot2017-03-071-140/+157
|
* clutter-clone: Unset source when source actor is destroyedRui Matos2017-03-061-0/+12
| | | | | | | Otherwise we might be holding on to a source actor that's no longer fully functioning and cause crashes if for example we try to paint it. https://bugzilla.gnome.org/show_bug.cgi?id=779483
* Update Icelandic translationSveinn í Felli2017-03-021-2396/+688
|
* Bump version to 3.22.33.22.3Florian Müllner2017-02-162-1/+25
| | | | Update NEWS.
* wayland: Fix buildCarlos Garnacho2017-02-161-9/+5
| | | | Missing s/MetaLogicalMonitor/MetaMonitorInfo/ when backporting 6e272229
* wayland/keyboard: Avoid a division by zeroRui Matos2017-02-161-1/+5
| | | | | | | We don't further sanitize the values since the protocol allows for everything as long as it's non-negative. https://bugzilla.gnome.org/show_bug.cgi?id=776919
* meta-input-settings: Avoid setting key repeat delay or interval to 0Rui Matos2017-02-161-0/+3
| | | | | | Since doing so causes either errors or misbehavior. https://bugzilla.gnome.org/show_bug.cgi?id=776919
* MetaInputSettings: allow edge scrolling without 2fg capable devicesRui Matos2017-02-164-1/+75
| | | | | | | We should only force edge scrolling off if two finger is enabled *and* we actually have two finger capable devices. https://bugzilla.gnome.org/show_bug.cgi?id=778554
* wayland: Update tool cursor scale when crossing monitorsCarlos Garnacho2017-02-152-0/+25
| | | | | | This makes tool cursors properly scaled on hidpi. https://bugzilla.gnome.org/show_bug.cgi?id=778474
* wayland: Keep pointer to cursor sprite on MetaWaylandTabletToolCarlos Garnacho2017-02-152-1/+6
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=778474
* backends: extend tablet device checksCarlos Garnacho2017-02-151-4/+15
| | | | | | | | | | | | 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 (backported from master for https://bugzilla.gnome.org/show_bug.cgi?id=775635)
* keybindings: fix erratic raise_or_lower behaviorJose Marino2017-02-071-1/+1
| | | | | | | | | | | Function "handle_raise_or_lower (src/core/keybindings.c)" is called when running 'raise-or-lower' on a window. This function iterates through all the windows in the stack to determine if our window is already on top or obscured. The problem is that the window stack includes windows in another workspaces and also windows that are minimized. https://bugzilla.gnome.org/show_bug.cgi?id=705200
* Use eglGetPlatformDisplayAdam Jackson2017-02-072-4/+68
| | | | | | | | | | Different libEGL will do different things for eglGetDisplay since it has to guess what kind of display it's been handed. Better to just use the API that makes it explicit. Signed-off-by: Adam Jackson <ajax@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=772422
* wayland: fix copy/pasto sending tool removed on rings/stripsPeter Hutterer2017-02-072-2/+0
| | | | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> https://bugzilla.gnome.org/show_bug.cgi?id=778262
* MetaCursorRendererNative: Always force set hw cursor the first timeJonas Ådahl2017-02-071-9/+15
| | | | | | | | The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
* Update zh_CN translationMandy Wang2017-02-051-14/+13
|
* monitor-manager: Get monitor info scale from main output tileJonas Ådahl2017-02-031-0/+1
| | | | | | | We didn't ever set the monitor info scale for tiled outputs; lets do that by taking it from the main output. https://bugzilla.gnome.org/show_bug.cgi?id=777470
* compositor: Avoid thaw on inconsistent effect_completed callsCarlos Garnacho2017-01-261-1/+7
| | | | | | | | | | | | | If the meta_window_actor_effect_completed() triggers inconsistent accounting, there's also high chances that the thaw call will be unexpected at this time too, which will lead to a g_error(). This makes mutter more lenient to effect_completed() calls of the right type (i.e. those triggering freeze/thaw) being performed more times than necessary in the upper parts. A warning will be issued, but the process won't abort. https://bugzilla.gnome.org/show_bug.cgi?id=777691
* clutter/evdev: Dispatch libinput before generating key repeat eventsRui Matos2017-01-253-0/+14
| | | | | | | | | | | | | | | | | | | | Since both the libinput event source and the key repeat timer have the same priority, the order in which both handlers are called is arbitrary if both sources are ready on the same poll return. This means that sometimes we generate key repeats when there's already a real key event queued on libinput that would cancel the repeat timer if only it was processed before. One solution would be lowering the repeat timer source priority a notch lower than the libinput source but that would mean that a steady stream of events from libinput (e.g. pointer device motion) would prevent any key repeats to happen. Instead, we can fix this problem by trying to dispatch libinput from the key repeat timer and checking if the timer source has been destroyed before generating more key repeats. https://bugzilla.gnome.org/show_bug.cgi?id=774989
* clutter/evdev: Avoid losing key repeat timestamp resolutionRui Matos2017-01-251-3/+1
| | | | | | | | | Commit 9214d5029c630e6ed8fd9793f6bcb0a0ae451576 changed the notify* API to use microseconds and we already have a microsecond time source here so we can use the timestamp directly without losing resolution at this layer. https://bugzilla.gnome.org/show_bug.cgi?id=774989
* backends: Calculate output scale correctly on vertical transformsCarlos Garnacho2017-01-251-5/+19
| | | | | | | | | | | | | The code calculating the output scale involves calculations around pixel and mm sizes, however we do compare post-transformation pixel sizes to untransformed mm sizes, which breaks the DPI calculations. Fix this by transforming back pixel sizes back to untransformed. While we're at it, actually compare the output height to HIDPI_MIN_HEIGHT instead of its width, it seems right according to the #define name and comment. https://bugzilla.gnome.org/show_bug.cgi?id=777687
* wayland/xdg-shell: Scale window menu coordinatesJonas Ådahl2017-01-031-2/+4
| | | | | | | | | When the monitor the surface is on has a scale other than 1, the coordinate of the window menu popup position needs to be scaled, as it is reported in logical pixels, while the stage is still in physical pixels. https://bugzilla.gnome.org/show_bug.cgi?id=776055
* wayland: Preserve the event mask on the root windowOlivier Fourdan2016-12-151-4/+9
| | | | | | | | | | | | | | | | | | | | | A window manager must select the SubstructureRedirect mask on the root window to receive the MapRequest from the X11 clients and manage the windows. Without this event mask set, a window manager won't be able to map any new window. The Wayland selection code in mutter can change/clear the event mask on the requestor window from a XSelectionRequest event when the window is not managed by mutter/gnome-shell. A rogue or simply buggy X11 client may send a XConvertSelection() on the root window and mutter will happily change/clear its own event mask on the root window, effectively turning itself into a regular X11 client unable to map any new X11 window from the other X11 clients. To avoid this, simply check that the requestor window is not the root window prior to change/clear the event mask on that window. https://bugzilla.gnome.org/show_bug.cgi?id=776128
* wayland: Ensure we don't focus xdg_popups iff they're non-grabbingRui Matos2016-12-132-18/+16
| | | | | | | | | | | | | | | | | | | Commit 4295fdb892d4474b68e98aa783b725f99c1a2d3a made us skip focusing all xdg_popups instead of just non-grabbing ones as intended. This means that when unmanaging a window we might select a xdg_popup window to focus (in meta_stack_get_default_focus_window() ) but then since we don't actually focus it we go on unmanaging the focused window which triggers an assertion, as it should. To avoid this and still fixing bug 771694 we can make use of the MetaWindow->input property for non-grabbing xdg_popup windows since their semantics, in this regard, are the same as no input X11 windows. This way, when unmanaging a focused window while a xdg_popup is up, we'll either give focus to the xdg_popup or not select the popup at all to be focused if it's non-grabbing. https://bugzilla.gnome.org/show_bug.cgi?id=775986
* MetaRendererNative: Flush all pending swap notifies on idleRui Matos2016-12-071-6/+16
| | | | | | | | | | | | | | | | | | | | | | | 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
* meta-monitor-config: Initialize MetaConfiguration's properlyRui Matos2016-11-211-1/+1
| | | | | | | We weren't initializing the ref count which means we could either be leaking or end up using free'd memory. https://bugzilla.gnome.org/show_bug.cgi?id=774135
* constraints: Don't early out of custom rule if window can't fitJonas Ådahl2016-11-211-4/+0
| | | | | | | Still go through the rules. For example a tall menu might still be positioned better, and/or shrunk to a better size if applicable. https://bugzilla.gnome.org/show_bug.cgi?id=771297
* meta-input-settings-x11: Don't try setting unavailable scroll methodsRui Matos2016-11-161-4/+20
| | | | | | Since doing so causes BadValue X errors. https://bugzilla.gnome.org/show_bug.cgi?id=771744
* Bump version to 3.22.23.22.2Florian Müllner2016-11-102-1/+22
| | | | Update NEWS.
* compositor: End a wayland popup grab when starting a compositor grabRui Matos2016-11-021-0/+8
| | | | | | | | | | | | Wayland popup grabs, unlike other grab types, can be safely cancelled so there's no reason to deny compositor grab requests if a wayland popup is on. In particular, this allows entering the overview via a keybinding or locking the screen while a wayland popup has a grab which is something that's been advertised as a wayland improvement over X. https://bugzilla.gnome.org/show_bug.cgi?id=771235
* MetaInputSettings: fix two finger preference over edge scrolling logicRui Matos2016-11-023-99/+44
| | | | | | | | | | | | | | | | | | 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
* MetaInputSettingsNative: allow unsetting click and scroll methodsRui Matos2016-11-021-14/+4
| | | | | | | | | 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
* stack: Stack docks below other windows on fullscreen monitorsRui Matos2016-11-022-3/+11
| | | | | | | | | | | | | | Commit fcc7501eb8dab5c1749e5421e31311fd14fd73f0 had the side-effect of stacking fullscreen windows below docks which went unnoticed since we don't use docks in GNOME anymore. Instead of re-introducing the fullscreen layer, which we don't need otherwise, we can fix this issue by ensuring we stack docks below all other windows when the monitor they're on is marked fullscreen. This has the added benefit that the visibility rule for 3rd party docks becomes the same as gnome-shell's chrome. https://bugzilla.gnome.org/show_bug.cgi?id=772937
* Update zh_CN translationYunQiang Su2016-10-301-132/+153
|
* Update zh_CN translationliushuyu2016-10-301-577/+364
|
* wayland: do not explicitly focus xdg_popupOlivier Fourdan2016-10-271-0/+14
| | | | | | | | | | | The keyboard focus semantics for non-grabbing xdg_shell v6 popups is pretty undefined. Same applies for subsurfaces, but in practice, subsurfaces never receive keyboard focus, so it makes sense to do the same for non-grabbing popups. https://bugzilla.gnome.org/show_bug.cgi?id=773210
* window: Do not unfocus on new windowOlivier Fourdan2016-10-271-21/+1
| | | | | | | | | | | | | | | mutter would remove focus from a toplevel when showing one of its transient window which is not on top and not focused. When using xdg_popup without grab as allowed in xdg_shell v6, the popup wouldn't be focused, and if an intermediate event occurs before the popup is shown, it's not placed on top either, which could randomly trigger a loss of focus in the corresponding toplevel window. Remove that special case, it doesn't make much sense to globally unset focus when mapping a new window. https://bugzilla.gnome.org/show_bug.cgi?id=773210
* wayland: apply size hints after placing the windowOlivier Fourdan2016-10-191-5/+6
| | | | | | | Otherwise the window will be shown initially in the wrong position then moved quickly as soon as it's made visible, which is confusing. https://bugzilla.gnome.org/show_bug.cgi?id=772729
* wayland: Don't cancel the pointer grab on compositor grabsJonas Ådahl2016-10-191-2/+0
| | | | | | | | | | | | | | | | | | | | | We shouldn't cancel the pointer grab when there is a compositor grab, since that'd break things like drag-n-drop via the overview and alt-tabs. The original reason for cancelling the pointer grab on compositor grabs was to avoid a re-entry when a compositor grab was activated while there was an active pointer constraint grab. The re-entry would happen when the compositor grab cleared the pointer focus. Clearing the focus would trigger the pointer constraint to be deactivated, which would end its grab. Ending the grab would reset the grab to the default one, which could focus the same surface again, triggering the constraint to re-enable before it finished disabling. This is now avoided because the default grab handler is now aware of compositor grabs, and won't override the cleared pointer focus until the compositor grab ends. https://bugzilla.gnome.org/show_bug.cgi?id=772914
* wayland/pointer: Don't set focus while during compositor grabJonas Ådahl2016-10-191-0/+14
| | | | | | | | Teach the default grab about compositor grabs (i.e. display->event_route) so that it can avoid setting a pointer focus when after the compositor grab actively unset the pointer focus. https://bugzilla.gnome.org/show_bug.cgi?id=772914
* wayland/pointer-constraints: Don't include window frame in regionJonas Ådahl2016-10-191-0/+22
| | | | | | | | | | When Xwayland confines, the surface dimensions will include the server side window manager decorations. We don't want the decorations to be included in the constraint region so intersect the calculated input region with the parts of the buffer rect that is not part of the window frame. https://bugzilla.gnome.org/show_bug.cgi?id=771859
* wayland/pointer-constraints: Unify requirements for enablementJonas Ådahl2016-10-191-18/+26
| | | | | | | | | | | | | | Put the conditions for enabling a pointer constraint in a helper function, and use that in both maybe_enable() and maybe_remove(). The constraint region checking is still only done in maybe_enable() however. This changes the conditions for maybe disabling the constraint on focus change and other trigger points, namely it makes constraints by Xwayland not disable when they shouldn't due to the constraining window being an override-redirect window. https://bugzilla.gnome.org/show_bug.cgi?id=771859
* wayland/pointer-constraints: Disable or remove when grab is cancelledJonas Ådahl2016-10-191-13/+39
| | | | | | | | | When the grab is cancelled, for example because of an Alt-tab, VT switch etc, disable or remove (depending on the constraint type) the constraint. This avoids a re-entry issue when the focus is returned and the focus listener tries to re-enable a disabled constraint. https://bugzilla.gnome.org/show_bug.cgi?id=771859
View Lorry Controller Status