GHOST/Wayland Support #76428

New Issue

Campbell Barton · 2020-05-05T03:20:53+02:00

Campbell Barton commented

2020-05-05 03:20:53 +02:00

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

Support platform native "message-box" (GHOST_System::showMessageBox).
Support display server reconnecting (new feature, not yet supported by main-line MESA), see KWIN/Restarting
IME (text input) support (a38a49b073).
dead-key support for keyboard input (57a5c6c4be).
Primary clipboard support (b0eff51fb7).
Image clipboard support (692de6d380).

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 fails 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

Display (Cursor)

Animated cursor support 3a7c618b87.
Cursor shape integration (support cursor themes, size & animated cursors) PR: !115701 - on hold for now.

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
#113795: Proposal to support client-side-decorations (CSD).

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)
#113558 (Wayland: Unable to position newly created 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 . Supported in libdecor v0.2.0.

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.

Bugs with LibDecor

#109194 Window decoration size doesn't match Blender window size.
#108308 Crash on startup with LibDecor on Wayland.
#107797 Resizing window causes crash on Wayland.

Bugs with GPU Drivers

NVidia
- #110327 Only 3D View-port region is transparent on Wayland (NVidia + Nouveau)

Bugs with Other Components

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
Gnome-shell doesn't receive tablet input for new windows #107778 https://gitlab.gnome.org/GNOME/mutter/-/issues/2658
#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** - [ ] Support platform native "message-box" (`GHOST_System::showMessageBox`). - [ ] Support display server reconnecting (new feature, not yet supported by main-line MESA), see [KWIN/Restarting](https://invent.kde.org/plasma/kwin/-/wikis/Restarting) - [x] IME (text input) support (a38a49b073f582a0f6ddcca392f2760afdc4d5ed). - [x] dead-key support for keyboard input (57a5c6c4bea40e4a43a52dbe5a1b8c61d3e8544f). - [x] Primary clipboard support (b0eff51fb73cfd9def696e3ede5ff23817f35784). - [x] Image clipboard support (692de6d380c7860601b28ee0873f33452dde86f8). **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 fails 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 **Display (Cursor)** - [x] Animated cursor support 3a7c618b87c779c04a7f0eec69670d0155b2ab75. - [ ] Cursor shape integration (support cursor themes, size & animated cursors) PR: !115701 - on hold for now. **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 - [ ] #113795: Proposal to support client-side-decorations (CSD). **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) - [ ] #113558 (Wayland: Unable to position newly created 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) - [x] Window decorations look out of place (libdecor) see, #101176 and this [merge-request ](https://gitlab.gnome.org/jadahl/libdecor/-/merge_requests/43). Supported in libdecor v0.2.0. **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.* **Bugs with LibDecor** - [ ] #109194 Window decoration size doesn't match Blender window size. - [ ] #108308 Crash on startup with LibDecor on Wayland. - [ ] #107797 Resizing window causes crash on Wayland. **Bugs with GPU Drivers** - NVidia - #110327 Only 3D View-port region is transparent on Wayland (NVidia + Nouveau) **Bugs with Other Components** 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 - [ ] Gnome-shell doesn't receive tablet input for new windows #107778 https://gitlab.gnome.org/GNOME/mutter/-/issues/2658 - [ ] #98927 (Cursor input "low resolution" with Hi-DPI in gnome-shell), reported to mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/2311

Campbell Barton commented

2020-05-05 03:20:53 +02:00

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

Campbell Barton commented

2020-05-05 03:20:53 +02:00

Added subscriber: @ideasman42

Alaska commented

2020-05-05 04:14:41 +02:00

Added subscriber: @Alaska

Christian Rauch commented

2020-05-05 12:07:34 +02:00

Added subscriber: @christian.rauch

Christian Rauch commented

2020-05-05 12:07:34 +02:00

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.

Campbell Barton commented

2020-05-05 15:50:04 +02:00

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.

Christian Rauch commented

2020-05-06 18:19:19 +02:00

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.

Hans Goudey commented

2020-05-07 03:44:42 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2020-05-07 03:44:42 +02:00

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. ```

Christian Rauch commented

2020-05-07 14:45:08 +02:00

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.

Hans Goudey commented

2020-05-09 17:09:46 +02:00

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 ```

Christian Rauch commented

2020-05-09 19:18:29 +02:00

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`.

Hans Goudey commented

2020-05-10 17:48:35 +02:00

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.

Christian Rauch commented

2020-05-10 21:42:09 +02:00

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.

Hans Goudey commented

2020-05-12 21:00:34 +02:00

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?

Christian Rauch commented

2020-05-12 21:58:21 +02:00

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.

Hans Goudey commented

2020-05-24 22:50:26 +02:00

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)

Christian Rauch commented

2020-05-25 01:31:08 +02:00

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?

Eric Engestrom commented

2020-08-18 07:07:03 +02:00

Added subscriber: @1ace

Christian Rauch commented

2021-06-03 19:34:27 +02:00

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).

Alvaro Perez commented

2022-04-26 22:26:38 +02:00

Added subscriber: @alvaroperez

Vilim commented

2022-05-16 16:17:28 +02:00

Added subscriber: @vilim

Srecko Micic commented

2022-05-16 23:14:07 +02:00

Added subscriber: @SreckoMicic

Alvaro Perez commented

2022-06-16 18:25:31 +02:00

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!

Christian Rauch commented

2022-06-16 18:34:12 +02:00

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")?

Alvaro Perez commented

2022-06-16 18:41:09 +02:00

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

Christian Rauch commented

2022-06-16 20:14:32 +02:00

@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.

Campbell Barton commented

2022-06-16 22:51:48 +02:00

@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.

Benni Merz commented

2022-06-20 14:37:24 +02:00

Added subscriber: @Benni-Merz

Alvaro Perez commented

2022-06-24 18:07:38 +02:00

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.

Campbell Barton commented

2022-06-25 05:16:40 +02:00

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.

smeikx commented

2022-07-13 08:56:39 +02:00

Added subscriber: @smeikx

blender-admin commented

2022-08-15 14:58:04 +02:00

This issue was referenced by a296b8f694

This issue was referenced by a296b8f694d1a93d40da78312758580f69b43be7

Anton Raves commented

2022-08-15 17:20:51 +02:00

Added subscriber: @Memento

Campbell Barton added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

GHOST/Wayland Support #76428