- 19 Jul, 2021 1 commit
-
-
- 29 Aug, 2020 12 commits
-
-
Issue 405 relates to mismapped keys injected by gnome-remote-desktop. It seems to be because a keyval (keysym) may be in the keymap more than once. We currently run through each keycode, trying from lowest level to highest level and stop as soon as we find a hit, which means that if the key symbol is in a lower level of a later keycode, we mis-pick the earlier one with the higher level (hence the far less common greek_OMEGA rather than common AT symbol). This patch swaps the order of the loops (so we loop through the levels from lowest to highest, and at each level run through the keycodes. We make sure we only go as high as the highest level for all keys (by figuring out the maximum on the first level's run through). This resolves the issues being experienced and ensures it is possible to type characters like @. It is slightly less efficient in the worst case, in that we keep figuring out the maximum for each key multiplied by the maximum number of levels (rather than 1), but in the common case is probably more efficient (because there's a whole bunch of higher levels we never have to try if we hit the right keycode first). Fixes #405. GNOME/mutter#405
-
The X server, including Xwayland, can be compiled with different X11 extensions enabled at build time. When an X11 extension is built in the X server, it's usually also enabled at run time. Users can chose to disable those extensions at run time using the X server command line option "-extension". However, in the case of Xwayland, it is spawned automatically by the Wayland compositor, and the command line options are not configurable by users. Add a new setting to disable a selected set of X extension in Xwayland at startup, without needing to rebuild Xwayland. Of course, if Xwayland is not built with a given extension support in the first place (which is the default for the security extension for example), that option has no effect. GNOME/mutter!1405
-
Delay the addition and removal of devices using ClutterDeviceEvent's so that they are processed following the libinput event order, and that we don't have to flush the events on removal. GNOME/mutter!1371
-
When a device is removed from the seat the events that this device may have emitted just before being removed might still be in the stage events queue, this may lead a to a crash because: Once the device is removed, we dispose it and the staling event is kept in queue and sent for processing at next loop. During event processing we ask the backend to update the last device with the disposed device The device is disposed once the events referencing it, are free'd The actual last device emission happens in an idle, but at this point the device may have been free'd, and in any case will be still disposed and so not providing useful informations. To avoid this, once a device has been added/removed from the seat, we queue ClutterDeviceEvent events to inform the stack that the device state has changed, preserving the order with the other actual generated device events. In this way it can't happen that we emit another event before that the device has been added or after that it has been removed. Fixes: GNOME/mutter#1345
-
Clutter device events are special events coming from the backend when an input device is added or removed. When such events are processed, we should make the seat to handle them by calling vfunc that can be implemented by each backend and eventually emitting the appropriate signal. If a device is removed, we can also safely dispose it, as it can be considered stale at this point. GNOME/mutter!1371
-
Add clutter device added and removed events to allow processing of them as it happens in the backends, queuing them and performing actions in order. This allows not to loose any event that is performed just before removing or disabling a device, and still process the events in order in the event queue. GNOME/mutter!1371
-
When a device is removed we perform some actions such as stopping the "::last-device-changed" signal emission and unsetting the current device. And we want to be sure that these actions happen after all the device-removed operations are sorted out. Related to: GNOME/mutter#1345 GNOME/mutter!1371
-
When removing a device that has been just marked as the last in use, we may try to notify that a NULL device is the last one. This is not supported, as both update_last_device() and the clients of the "::last-device-changed" signal are assuming that the last device is always a valid ClutterInputDevice. So let's avoid erroring, and stop the idle when clearing the current device. Related to: GNOME/mutter#1345 GNOME/mutter!1371
-
-
-
A GAppInfo is not guaranteed to have a filename or an application (or rather a desktop ID). Add a check for application_id to be non-NULL before trying to call sn_launcher_set_application_id, which would crash otherwise. GNOME/mutter!1392
-
-
- 28 Aug, 2020 4 commits
-
-
PipeWire reuses buffers, and buffer metadatas, when streaming. When the cursor is moved to outside the stream, the cursor meta also needs to be updated, otherwise it'll use the cursor position of whatever is in the buffer. Don't bail out when cursor is outside the stream, and ensure to record a metadata-only frame. This only applies to metadata streams. GNOME/mutter!1417
-
As per PipeWire docs, 0 means "invalid cursor", however the function to unset the cursor was setting it to 1, which means "this is totally set and valid cursor". This is likely bad copy-paste from the function immediately below introduced by 9be189da. Fixes GNOME/mutter#1341 GNOME/mutter!1417
-
This may stir some pain in 32bit arches. Fixes: GNOME/mutter#1395
-
-
- 26 Aug, 2020 5 commits
-
-
Robert Mader authored
If we returned early in one of the checks but already assigned the surface role, we'd later run into a double-free and crash. Just do the checks at the beginning. Also add a missing return statement that was left out in commit 88ff196f and tighten the parent surface check. GNOME/mutter!1415
-
Aurimas Černius authored
-
Robert Mader authored
The spec allows `parent_resource` to be `NULL`, requiring the parent surface to get specified by some other protocol. Send a protocol error with some meaningful explanation instead of crashing. GNOME/mutter!1408
-
Robert Mader authored
Like in most similar places we can not assume to get a valid window when calling `meta_wayland_surface_get_window` as it e.g. might be unmapped already. Calling `get_popup` on an unmapped window is a client bug, thus post a protocol error when this happens. Closes GNOME/mutter#1174 Closes GNOME/mutter#1293
-
Robert Mader authored
Without this calling wl_seat.release would crash Mutter. GNOME/mutter!1409
-
- 25 Aug, 2020 2 commits
-
-
Pascal Nowack authoredCurrently, the maximum size for a mouse pointer bitmap for screen casting is 64x64 pixels. However, this limit is hit way too often as it is way too low and results in crashes in either gnome-remote-desktop or mutter. For example: The a11y settings in g-c-c allow setting a larger pointer bitmap in order to increase the visibility of the mouse pointer. With the current limit of 64x64 pixels it is not possible to use the larger variants of the default mouse pointer bitmap, without experiencing any crash. Another way to hit the limit is when display scaling is used or some game uses a custom (large) mouse pointer bitmap. The VNC backend in gnome-remote-desktop does not seem to have a maximum pointer bitmap size. The RDP backend on the other hand has a maximum pointer bitmap size at 384x384. Use this size (384x384) as maximum size instead of the current 64x64 size for mouse pointer bitmaps to avoid crashes in mutter and gnome-remote-desktop and to ensure that bigger mouse pointer bitmaps can be used. GNOME/mutter!1414
-
Marek Černocký authored
-
- 24 Aug, 2020 1 commit
-
-
Florian Müllner authored
Update NEWS.
-
- 23 Aug, 2020 3 commits
-
-
Robert Mader authored
Just as we do in similar places. This avoids crashes under certain circumstances. GNOME/mutter!1411
-
-
-
- 22 Aug, 2020 1 commit
-
-
- 20 Aug, 2020 2 commits
-
-
Matej Urbančič authored
-
-
- 19 Aug, 2020 1 commit
-
-
- 17 Aug, 2020 3 commits
-
-
There might be pending flip callbacks to process; we shouldn't release the buffers until we have received the callback. Fixes GNOME/mutter#1378 GNOME/mutter!1407
-
The onscreens are set on construction now, so no need to wait for it to be set after. GNOME/mutter!1407
-
-
- 16 Aug, 2020 1 commit
-
-
- 15 Aug, 2020 2 commits
-
-
Piotr Drąg authored
-
-
- 14 Aug, 2020 1 commit
-
-
- 13 Aug, 2020 1 commit
-
-
It is linear config manager created when ensuring configuration. However, the switch config is not set as LINEAR, but left as UNKNOWN. This leads switch mode OSD always shows "Join Displays" icon, rather than the next icon which is "External Only" after connect an external display and press Super+P once at first time since mutter starts. This patch moves switch config setting into meta_monitor_config_manager_create_linear() (and the sibling functions) to well prepare the monitors config and avoid missing settings. This is a regression introduced by 149e4d69. Fixes: GNOME/mutter#1362
-
