GHOST/Wayland Support #76428

New Issue

GHOST/Wayland support has been committed to master and is enabled for daily builds, this task is an overview of the remaining TODO's.

Note that these could be expanded into their own tasks, listing here for now.

Library Linking

dynamically load libwayland (e58e023e1a)

Integration

IME (text input) support (see: text-input-unstable-v3), See: D17030: [WIP] initial GHOST/Wayland IME support
Primary clipboard support b0eff51fb7

Input Devices

#104272 Touch-pad support for detecting inverted (natural) scroll events 98272e5bb2 (depends on Wayland v1.22 release).

Tablet support (pressure sensitivity, angle), 97f894881c
NDOF (3D mouse) support 8841bd9660
Detectable key repeat events (GHOST_TEventKeyData.is_repeat).
#98793 (Wayland clamps cursor movement failes with gnome-shell (fixed up-stream)), up-stream bug in gnome-shell, worked around in Blender.
#76429 (GHOST/Wayland event's don't correspond to physical keys)
#77311 (Mouse cursor stays in-place with Ghost/Wayland for operators that grab cursor input)
High resolution track-pad scroll events 30d9a6245f
Touch-pad gesture support (zoom, swipe, rotate.. etc). lower priority, not supported by Blender under X11. 8bb211a771

Display

Support for DPI detection (GHOST_GetDPIHint) 2770010224
Support fractional scaling (fractional-scale-v1) cde99075e8

Windowing

Support activating windows 3071ec486b
Support dialog windows (so they're always in-front GHOST_CreateDialogWindow, respecting parent windows).
#98612 (Window Decorations Not Present on GNOME - Wayland) 29755e1df8

OpenGL

Switch from GLEW to libepoxy, to support dynamic loading of either libOpenGL.so or libGL.so, patch: D15291 (see D12034 #312834).
#98462 (Save Screenshot (glReadPixels) fails under Wayland)
Enable EGL by default for X11 (This is trivial at this point. Just remove the USE_EGL ifdefs in GHOST_SystemX11.cpp and GHOST_WindowX11.cpp)
Support libOpenGL.so and EGL in OpenSubdiv and USD glLoader

Limitations

Wayland has constraints that might not be practical to work around.

#102985 (Wayland: Unable to lower windows)
#98928 (Wayland: Unable to access window position, finding the window under the cursor doesn't work)
#100276 (Wayland: Windows reset when reloaded on a multi-monitor configuration)
Window decorations look out of place (libdecor) see, #101176 and this merge-request .

Bugs

#100855 (GHOST/Wayland: Terminal Ctrl-C closes the window while Python is running) Low priority, needs further investigation.
#103059 (GHOST/Wayland: Huge cursor when using a graphics tablet in KDE) Low priority, needs further investigation.
#102999 ([Wayland] Incorrect UI scaling on high-resolution screen under GNOME 42.5 w/ fractional scaling) Fixed in GNOME 43, not clear how Blender would workaround the bug.

Other Bugs

Here are issues that are noticeable with Blender.

Gnome-shell doesn't scale custom cursors with Hi-DPI displays: https://gitlab.gnome.org/GNOME/mutter/-/issues/1215
#98927 (Cursor input "low resolution" with Hi-DPI in gnome-shell), reported to mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/2311

GHOST/Wayland support has been committed to master and is enabled for daily builds, this task is an overview of the remaining TODO's. Note that these could be expanded into their own tasks, listing here for now. **Library Linking** - [x] dynamically load libwayland (e58e023e1a) **Integration** - [ ] IME (text input) support (see: [text-input-unstable-v3](https://wayland.app/protocols/text-input-unstable-v3)), See: [D17030: [WIP] initial GHOST/Wayland IME support](https://archive.blender.org/developer/D17030) - [x] Primary clipboard support b0eff51fb7 **Input Devices** * [x] #104272 Touch-pad support for detecting inverted (natural) scroll events 98272e5bb24b865380ad580ce0354ccacb0fa52d (depends on Wayland v1.22 release). - [x] Tablet support (pressure sensitivity, angle), 97f894881c - [x] NDOF (3D mouse) support 8841bd9660 - [x] Detectable key repeat events (`GHOST_TEventKeyData.is_repeat`). - [x] #98793 (Wayland clamps cursor movement failes with gnome-shell (fixed up-stream)), up-stream bug in gnome-shell, worked around in Blender. - [x] #76429 (GHOST/Wayland event's don't correspond to physical keys) - [x] #77311 (Mouse cursor stays in-place with Ghost/Wayland for operators that grab cursor input) - [x] High resolution track-pad scroll events 30d9a6245f - [x] Touch-pad gesture support (zoom, swipe, rotate.. etc). *lower priority, not supported by Blender under X11.* 8bb211a771 **Display** - [x] Support for DPI detection (`GHOST_GetDPIHint`) 2770010224 - [x] Support fractional scaling (`fractional-scale-v1`) cde99075e87032d99d986182e98d9c367b22d417 **Windowing** - [x] Support activating windows 3071ec486bffd0fef180f221a85f0b15f07b7950 - [x] Support dialog windows (so they're always in-front `GHOST_CreateDialogWindow`, respecting parent windows). - [x] #98612 (Window Decorations Not Present on GNOME - Wayland) 29755e1df8 **OpenGL** - [x] Switch from GLEW to libepoxy, to support dynamic loading of either `libOpenGL.so` or `libGL.so`, patch: [D15291](https://archive.blender.org/developer/D15291) (see [D12034](https://archive.blender.org/developer/D12034)#312834). - [x] #98462 (Save Screenshot (glReadPixels) fails under Wayland) - [ ] Enable EGL by default for X11 (This is trivial at this point. Just remove the `USE_EGL` ifdefs in `GHOST_SystemX11.cpp` and `GHOST_WindowX11.cpp`) - [ ] Support `libOpenGL.so` and EGL in OpenSubdiv and USD `glLoader` ---- **Limitations** Wayland has constraints that might not be practical to work around. - [ ] #102985 (Wayland: Unable to lower windows) - [ ] #98928 (Wayland: Unable to access window position, finding the window under the cursor doesn't work) - [ ] #100276 (Wayland: Windows reset when reloaded on a multi-monitor configuration) - [ ] Window decorations look out of place (libdecor) see, #101176 and this [merge-request ](https://gitlab.gnome.org/jadahl/libdecor/-/merge_requests/43). **Bugs** - [x] #100855 (GHOST/Wayland: Terminal Ctrl-C closes the window while Python is running) *Low priority, needs further investigation.* - [ ] #103059 (GHOST/Wayland: Huge cursor when using a graphics tablet in KDE) *Low priority, needs further investigation.* - [ ] #102999 ([Wayland] Incorrect UI scaling on high-resolution screen under GNOME 42.5 w/ fractional scaling) *Fixed in GNOME 43, not clear how Blender would workaround the bug.* **Other Bugs** Here are issues that are noticeable with Blender. - [ ] Gnome-shell doesn't scale custom cursors with Hi-DPI displays: https://gitlab.gnome.org/GNOME/mutter/-/issues/1215 - [ ] #98927 (Cursor input "low resolution" with Hi-DPI in gnome-shell), reported to mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/2311

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @ideasman42

Added subscriber: @Alaska

Added subscriber: @christian.rauch

Regarding the modal/dialog windows: What is the semantic difference between being a child window and a dialog window?

When parentWindow is set, then this is also set as the parent window on wayland and the child window will always be on top of the parent window. This is for example used for the file "Open..." window, which will always stay on top of the main window.

Regarding the modal/dialog windows: What is the semantic difference between being a child window and a dialog window? When `parentWindow` is set, then this is also set as the parent window on wayland and the child window will always be on top of the parent window. This is for example used for the file "Open..." window, which will always stay on top of the main window.

If the window parent stays under the child window (file open dialog), this can be considered done.

Currently I don't have a very good setup for testing wayland, regular Blender doesn't run, only the animation player.

If the window parent stays under the child window (file open dialog), this can be considered done. Currently I don't have a very good setup for testing wayland, regular Blender doesn't run, only the animation player.

In #76428#924774, @ideasman42 wrote:
Currently I don't have a very good setup for testing wayland, regular Blender doesn't run, only the animation player.

What is your current setup? I am mostly testing with Ubuntu 20.04 on GNOME Shell with Wayland. This option should be available from the gdm login screen.

Alternatively, having a wayland option as an experimental built at https://builder.blender.org/download/branches/ would increase the testing variation a lot.

> In #76428#924774, @ideasman42 wrote: > Currently I don't have a very good setup for testing wayland, regular Blender doesn't run, only the animation player. What is your current setup? I am mostly testing with Ubuntu 20.04 on GNOME Shell with Wayland. This option should be available from the gdm login screen. Alternatively, having a wayland option as an experimental built at https://builder.blender.org/download/branches/ would increase the testing variation a lot.

Added subscriber: @HooglyBoogly

I tried testing this on my Intel GPU (running wayland) Fedora 32 laptop and I ran into compile errors when I turned WITH_GHOST_WAYLAND on. Otherwise this is standard make default settings.

--   Package 'wayland-client', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:467 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPkgConfig.cmake:647 (_pkg_check_modules_internal)
  build_files/cmake/platform/platform_unix.cmake:510 (pkg_check_modules)
  CMakeLists.txt:839 (include)

Am I missing something? Is another dependency required to build this?

Package libwayland-client-1.18.0-1.fc32.x86_64 is already installed.

I tried testing this on my Intel GPU (running wayland) Fedora 32 laptop and I ran into compile errors when I turned `WITH_GHOST_WAYLAND` on. Otherwise this is standard `make` default settings. ``` -- Package 'wayland-client', required by 'virtual:world', not found CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:467 (message): A required package was not found Call Stack (most recent call first): /usr/share/cmake/Modules/FindPkgConfig.cmake:647 (_pkg_check_modules_internal) build_files/cmake/platform/platform_unix.cmake:510 (pkg_check_modules) CMakeLists.txt:839 (include) ``` Am I missing something? Is another dependency required to build this? ``` Package libwayland-client-1.18.0-1.fc32.x86_64 is already installed. ```

In #76428#925682, @HooglyBoogly wrote:
I tried testing this on my Intel GPU (running wayland) Fedora 32 laptop and I ran into compile errors when I turned WITH_GHOST_WAYLAND on. Otherwise this is standard make default settings.
--   Package 'wayland-client', required by 'virtual:world', not found
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:467 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPkgConfig.cmake:647 (_pkg_check_modules_internal)
  build_files/cmake/platform/platform_unix.cmake:510 (pkg_check_modules)
  CMakeLists.txt:839 (include)
Am I missing something? Is another dependency required to build this?
Package libwayland-client-1.18.0-1.fc32.x86_64 is already installed.

You also have to install the development files (headers, etc.). In your case that should be sudo dnf install wayland-devel libxkbcommon-devel wayland-protocols-devel additional to the regular Blender development libraries.

> In #76428#925682, @HooglyBoogly wrote: > I tried testing this on my Intel GPU (running wayland) Fedora 32 laptop and I ran into compile errors when I turned `WITH_GHOST_WAYLAND` on. Otherwise this is standard `make` default settings. > > ``` > -- Package 'wayland-client', required by 'virtual:world', not found > CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:467 (message): > A required package was not found > Call Stack (most recent call first): > /usr/share/cmake/Modules/FindPkgConfig.cmake:647 (_pkg_check_modules_internal) > build_files/cmake/platform/platform_unix.cmake:510 (pkg_check_modules) > CMakeLists.txt:839 (include) > ``` > > Am I missing something? Is another dependency required to build this? > ``` > Package libwayland-client-1.18.0-1.fc32.x86_64 is already installed. > ``` You also have to install the development files (headers, etc.). In your case that should be `sudo dnf install wayland-devel libxkbcommon-devel wayland-protocols-devel` additional to the regular Blender development libraries.

Alright, those dependencies worked, although I had to add #include <stdexcept> in GHOST_SystemWayland.cpp to get it to compile on my machine.

I can look into it more with a debug build later, but with WITH_GHOST_WAYLAND I think I'm getting a hang on startup:

[hans@hans-fedora build_linux]$ ./bin/blender
Read prefs: /home/hans/.config/blender/2.90/config/userpref.blend
EGL Version 1.5
[destroyed object]: error 7: failed to import supplied dmabufs: Unsupported buffer format 808669784
EGL Version 1.5
found bundled python: /home/hans/Blender-Git/build_linux/bin/2.90/python

Alright, those dependencies worked, although I had to add `#include <stdexcept>` in `GHOST_SystemWayland.cpp` to get it to compile on my machine. I can look into it more with a debug build later, but with `WITH_GHOST_WAYLAND` I think I'm getting a hang on startup: ``` [hans@hans-fedora build_linux]$ ./bin/blender Read prefs: /home/hans/.config/blender/2.90/config/userpref.blend EGL Version 1.5 [destroyed object]: error 7: failed to import supplied dmabufs: Unsupported buffer format 808669784 EGL Version 1.5 found bundled python: /home/hans/Blender-Git/build_linux/bin/2.90/python ```

In #76428#927758, @HooglyBoogly wrote:
Alright, those dependencies worked, although I had to add #include <stdexcept> in GHOST_SystemWayland.cpp to get it to compile on my machine.

I added a commit to https://developer.blender.org/D7658 that fixes this.

I can look into it more with a debug build later, but with WITH_GHOST_WAYLAND I think I'm getting a hang on startup:

[hans@hans-fedora build_linux]$ ./bin/blender
Read prefs: /home/hans/.config/blender/2.90/config/userpref.blend
EGL Version 1.5
[destroyed object]: error 7: failed to import supplied dmabufs: Unsupported buffer format 808669784
EGL Version 1.5
found bundled python: /home/hans/Blender-Git/build_linux/bin/2.90/python

This is a known issue with the Intel driver. See: https://developer.blender.org/D6567#182240. In short: You have to call blender with MESA_LOADER_DRIVER_OVERRIDE=i965 blender.

> In #76428#927758, @HooglyBoogly wrote: > Alright, those dependencies worked, although I had to add `#include <stdexcept>` in `GHOST_SystemWayland.cpp` to get it to compile on my machine. I added a commit to https://developer.blender.org/D7658 that fixes this. > > I can look into it more with a debug build later, but with `WITH_GHOST_WAYLAND` I think I'm getting a hang on startup: > ``` > [hans@hans-fedora build_linux]$ ./bin/blender > Read prefs: /home/hans/.config/blender/2.90/config/userpref.blend > EGL Version 1.5 > [destroyed object]: error 7: failed to import supplied dmabufs: Unsupported buffer format 808669784 > EGL Version 1.5 > found bundled python: /home/hans/Blender-Git/build_linux/bin/2.90/python > ``` This is a known issue with the Intel driver. See: https://developer.blender.org/D6567#182240. In short: You have to call blender with `MESA_LOADER_DRIVER_OVERRIDE=i965 blender`.

That worked, thanks. I'm quite impressed by how much smoother this is for some things like moving the separation between areas.

How much feedback are you looking for at this point? I don't want to tell you stuff you already know.

That worked, thanks. I'm quite impressed by how much smoother this is for some things like moving the separation between areas. How much feedback are you looking for at this point? I don't want to tell you stuff you already know.

In #76428#928220, @HooglyBoogly wrote:
How much feedback are you looking for at this point? I don't want to tell you stuff you already know.

Basically everything that improves the backend and brings it closer to have it activated as the default choice when running upstream Blender on Wayland.

You can report any issues that you encounter, especially those things that are expected to work but don't in your compositor and distribution configuration. Even if it is a known but unreported issue, it would help to keep track of them as a dedicated issue that I can refer to.

On top of this, users can request any feature that they would like to see for the Wayland frontend. HiDPI and window decoration support is already on my TODO list.

> In #76428#928220, @HooglyBoogly wrote: > How much feedback are you looking for at this point? I don't want to tell you stuff you already know. Basically everything that improves the backend and brings it closer to have it activated as the default choice when running upstream Blender on Wayland. You can report any issues that you encounter, especially those things that are expected to work but don't in your compositor and distribution configuration. Even if it is a known but unreported issue, it would help to keep track of them as a dedicated issue that I can refer to. On top of this, users can request any feature that they would like to see for the Wayland frontend. HiDPI and window decoration support is already on my TODO list.

Besides window decoration and HiDPI, the main thing I noticed was that the panel animations were very slow when running with Wayland.
For example, when dragging a panel and letting it animate back to its original position, the animation seemed to only have a couple frames total.
Maybe GHOST_kEventTimer events aren't added properly? The panels use TIMER events to update.

As far as feature requests go, I've always wondered how possible it would be to support trackpad gestures on Linux. Maybe Wayland support helps with that?

Besides window decoration and HiDPI, the main thing I noticed was that the panel animations were very slow when running with Wayland. For example, when dragging a panel and letting it animate back to its original position, the animation seemed to only have a couple frames total. Maybe `GHOST_kEventTimer` events aren't added properly? The panels use `TIMER` events to update. As far as feature requests go, I've always wondered how possible it would be to support trackpad gestures on Linux. Maybe Wayland support helps with that?

In #76428#930236, @HooglyBoogly wrote:
Besides window decoration and HiDPI, the main thing I noticed was that the panel animations were very slow when running with Wayland.
For example, when dragging a panel and letting it animate back to its original position, the animation seemed to only have a couple frames total.
Maybe GHOST_kEventTimer events aren't added properly? The panels use TIMER events to update.

Can you open a dedicated "Task" with a list to reproduce this? I have a hunch of what is missing for that. At the moment, the process loop blocks until a new event has been received from the compositor.

As far as feature requests go, I've always wondered how possible it would be to support trackpad gestures on Linux. Maybe Wayland support helps with that?

I don't know how this can be implemented. There is an additional "touch" input, but I think this actually refers to touch screens. I also thought that touch gestures have to be supported by the toolkit, e.g. GTK/Qt or Blender's internal toolkit.

> In #76428#930236, @HooglyBoogly wrote: > Besides window decoration and HiDPI, the main thing I noticed was that the panel animations were very slow when running with Wayland. > For example, when dragging a panel and letting it animate back to its original position, the animation seemed to only have a couple frames total. > Maybe `GHOST_kEventTimer` events aren't added properly? The panels use `TIMER` events to update. Can you open a dedicated "Task" with a list to reproduce this? I have a hunch of what is missing for that. At the moment, the process loop blocks until a new event has been received from the compositor. > As far as feature requests go, I've always wondered how possible it would be to support trackpad gestures on Linux. Maybe Wayland support helps with that? I don't know how this can be implemented. There is an additional "touch" input, but I think this actually refers to touch screens. I also thought that touch gestures have to be supported by the toolkit, e.g. GTK/Qt or Blender's internal toolkit.

I'm not sure if this is a Blender or Gnome problem, but here's something else @christian.rauch In case you thought it was worth looking into.

In fullscreen mode (Window > Toggle Window Fullscreen) Blender doesn't take up the entire screen. This doesn't happen with X11.

I'm not sure if this is a Blender or Gnome problem, but here's something else @christian.rauch In case you thought it was worth looking into. In fullscreen mode (`Window > Toggle Window Fullscreen`) Blender doesn't take up the entire screen. This doesn't happen with X11. ![Screenshot from 2020-05-24 16-40-40.png](https://archive.blender.org/developer/F8551215/Screenshot_from_2020-05-24_16-40-40.png)

In #76428#937840, @HooglyBoogly wrote:
In fullscreen mode (Window > Toggle Window Fullscreen) Blender doesn't take up the entire screen. This doesn't happen with X11.

I don't see this issue with GNOME or Weston on Ubuntu 20.04. Does directly starting in fullscreen mode (blender -W) also produce this issue?

> In #76428#937840, @HooglyBoogly wrote: > In fullscreen mode (`Window > Toggle Window Fullscreen`) Blender doesn't take up the entire screen. This doesn't happen with X11. > ![Screenshot from 2020-05-24 16-40-40.png](https://archive.blender.org/developer/F8551215/Screenshot_from_2020-05-24_16-40-40.png) I don't see this issue with GNOME or Weston on Ubuntu 20.04. Does directly starting in fullscreen mode (`blender -W`) also produce this issue?

Added subscriber: @1ace

The HiDPI issue (last point) has been solved by D11368.

The HiDPI issue (last point) has been solved by [D11368](https://archive.blender.org/developer/D11368).

Added subscriber: @alvaroperez

Added subscriber: @vilim

Added subscriber: @SreckoMicic

Hello, when I compile with wayland the title bar does not appear. I've googled but can't find anything about it. Sorry if the problem is mine, since it also happens to me with other applications. I use gnome in arch. Regards and thanks for everything!

In #76428#1375651, @alvaroperez wrote:
Hello, when I compile with wayland the title bar does not appear. I've googled but can't find anything about it. Sorry if the problem is mine, since it also happens to me with other applications. I use gnome in arch. Regards and thanks for everything!

This is because Blender does not have client-side decorations yet. See #98612 for a discussion on this.

@ideasman42 Can you add this issue (#98612) to the list (probably under "Windowing")?

> In #76428#1375651, @alvaroperez wrote: > Hello, when I compile with wayland the title bar does not appear. I've googled but can't find anything about it. Sorry if the problem is mine, since it also happens to me with other applications. I use gnome in arch. Regards and thanks for everything! This is because Blender does not have client-side decorations yet. See #98612 for a discussion on this. @ideasman42 Can you add this issue (#98612) to the list (probably under "Windowing")?

Thank you for the quick reply @christian.rauch I was looking for title bar and omitted window decoration

@ideasman42 The issue with cursor scaling in GNOME is only relevant when the cursor scale is not provided manually. GNOME does upscale window surfaces automatically (without interpolation) when no scale is provided to match the display scale. Since there is no interpolation, those surfaces would look pixelated. While this does not look nice, it would at least allow interaction with the window. Otherwise, you would need to interact with a window of 25% scale on a 400% scale display. This is not happening with cursor surfaces (they stay small), and this is what the GNOME issue that you reference is about. If the GNOME issue is fixed, the cursor would still look blurry.

Blender does set the cursor buffer scale via update_cursor_scale when the cursor_surface_enter and cursor_surface_leave events are triggered. I gave this a try on a 2x scale display and this works in principle. I noticed, however, that the scale does not get applied immediately. I have to leave and enter the window surface again to have the scale properly applied. You can also see that the scale does not get properly applied to the window surfaces when running blender --window-maximized on an e.g. 2x scale display. The window will be shown at 1/2 the expected size.

In summary, this is an issue on the client-side. We have to make sure that Blender gathers and sets the surface scales before rendering the window or surface for the first time.

@ideasman42 The issue with cursor scaling in GNOME is only relevant when the cursor scale is not provided manually. GNOME does upscale window surfaces automatically (without interpolation) when no scale is provided to match the display scale. Since there is no interpolation, those surfaces would look pixelated. While this does not look nice, it would at least allow interaction with the window. Otherwise, you would need to interact with a window of 25% scale on a 400% scale display. This is not happening with cursor surfaces (they stay small), and this is what the GNOME issue that you reference is about. If the GNOME issue is fixed, the cursor would still look blurry. Blender does set the cursor buffer scale via `update_cursor_scale` when the `cursor_surface_enter` and `cursor_surface_leave` events are triggered. I gave this a try on a 2x scale display and this works in principle. I noticed, however, that the scale does not get applied immediately. I have to leave and enter the window surface again to have the scale properly applied. You can also see that the scale does not get properly applied to the window surfaces when running `blender --window-maximized` on an e.g. 2x scale display. The window will be shown at 1/2 the expected size. In summary, this is an issue on the client-side. We have to make sure that Blender gathers and sets the surface scales before rendering the window or surface for the first time.

@christian.rauch Cursors using the theme seem to work OK, but I couldn't - under any conditions get the cursor to be up-scaled for Blender's custom cursors such as the knife tool in edit-mode.

The scale value is just ignored in this case.

The same is true for Xwayland.

In #76428#1375653, @christian.rauch wrote:
@ideasman42 Can you add this issue (#98612) to the list (probably under "Windowing")?

Added.

@christian.rauch Cursors using the theme seem to work OK, but I couldn't - under any conditions get the cursor to be up-scaled for Blender's custom cursors such as the knife tool in edit-mode. The scale value is just ignored in this case. The same is true for Xwayland. > In #76428#1375653, @christian.rauch wrote: > @ideasman42 Can you add this issue (#98612) to the list (probably under "Windowing")? Added.

Added subscriber: @Benni-Merz

First of all thanks for the window decoration and for everything in general, I just compiled in wayland again for that very reason. What I just discovered is that the AccentGrave (`) key doesn't work and I can't access the view navigation pie menu. It only happens to me in wayland. When inserting it manually in the keymap settings it says unsupported key. I don't know what connection it has with wayland. Putting another key if it works.

Hi @alvaroperez thanks for the feedback, could you report a bug please? The AccentGrave key is working on my system, however for X11 there are some keyboard layout spesific workarounds we'll probably need to support for wayland too.

Edit this has been resolved b8cc181808.

Hi @alvaroperez thanks for the feedback, could you report a bug please? The AccentGrave key is working on my system, however for X11 there are some keyboard layout spesific workarounds we'll probably need to support for wayland too. --- *Edit* this has been resolved b8cc181808.

Added subscriber: @smeikx

This issue was referenced by a296b8f694

This issue was referenced by a296b8f694d1a93d40da78312758580f69b43be7

Added subscriber: @Memento

Should support for the fractional_scale_v1 protocol be added to the TODO list?

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143

Should support for the `fractional_scale_v1` protocol be added to the TODO list? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143

@eszlari added, although this is mainly needed for GNOME (KDE/WLROOTS based compositors are working already without fractional_scale_v1). It seems GNOME merged support 2 weeks ago:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394 so I'll wait until this makes it into a stable release of GNOME.

@eszlari added, although this is mainly needed for GNOME (KDE/WLROOTS based compositors are working already without `fractional_scale_v1`). It seems GNOME merged support 2 weeks ago: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2394 so I'll wait until this makes it into a stable release of GNOME.

@ideasman42 Yesterday, March 22 2023, GNOME 44 was released, now it is waiting for the many distros to adapt it too.

(KDE/WLROOTS based compositors are working already without fractional_scale_v1)

"Working" in the sense that they will render only in integer scale and then downscale and thus wasting resources.

> (KDE/WLROOTS based compositors are working already without `fractional_scale_v1`) "Working" in the sense that they will render only in integer scale and then downscale and thus wasting resources.

(KDE/WLROOTS based compositors are working already without fractional_scale_v1)

"Working" in the sense that they will render only in integer scale and then downscale and thus wasting resources.

You're right, this looking into this it wasn't working as well as I'd assumed from basic usage. Committed support for fractional_scale_v1 cde99075e8.

> > (KDE/WLROOTS based compositors are working already without `fractional_scale_v1`) > > > "Working" in the sense that they will render only in integer scale and then downscale and thus wasting resources. You're right, this looking into this it wasn't working as well as I'd assumed from basic usage. Committed support for `fractional_scale_v1` cde99075e87032d99d986182e98d9c367b22d417.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

GHOST/Wayland Support #76428