Comments

• 

  over 7 years ago by fcrozat | Reply

  Current status of Wayland regressions (partially based on Fedora25 status page at https://fedoraproject.org/wiki/Wayland_features ) * requirement: switch to libinput * Color temperature control (partially fixed in GNOME 3.24, display calibration protocol is still under discussion upstream). * remote display: some people at RH started working on implementing it in mutter in Q1 2016 (with VNC) but they never released their prototype and worked on some other part of Wayland support. This is a blocker to make Wayland by default on SLE * Wacom tablet configuration support: will be available in GNOME 3.24. * Accessibility (keyboard): Under X, key repeat and AccessX features (sticky keys, slow keys, bounce keys, toggle keys, etc) are implemented in the X server. Under Wayland, GTK+ currently implements key repeat on the client-side. There is a branch which adds the AccessX features, but implementing these client-side is not ideal, and leads to some regressions. Moving it to the compositor is not trivial, because we then need to 'neuter' the AccessX implementation in xwayland. * accessibility (mouse): Mouse accessibility features such as hover-to-click need to be reimplemented in the compositor. In contrast to keyboard accessibility, these features are implemented outside the X server for X (in mousetweaks), so this is a bit simpler wrt to xwayland. * accessibility (device controller): Orca has a feature called 'mouse review' which relies on the at-spi-registryd deviceeventcontroller interface to 'remote control' the pointer. To provide this functionality under Wayland, mutter needs to provide a device controller interface and at-spi-registryd needs to use it. After discussing this with Jonas, this should be a D-Bus interface, it doesn't need to be a Wayland protocol. * Outputs on secondary GPUs: Laptops where the external outputs are only connected to a secondary GPU needs to be supported in some form. These work under X currently using reverse prime. (not sure of the current status) * Remove X11 requirement in mutter: Currently, mutter will start Xwayland at startup unconditionally because it still depends on "X11 backend to GTK+ for various things within Mutter and GNOME Shell, such as theme drawing and input methods. I think we'd need to eliminate the use of GTK+ for input methods, then have some no-backend mode to use GTK+ for theme drawing without actually opening a connection to a display server". Not a big problem, we just have a X server running in the background. * Nvidia driver support: we need to enable VNGL in Mesa (see Wayland mesa FATE) * Clipboard manager: Under X11, gnome-settings-daemon offers an api to store the contents of the clipboard when the selection owner exits, and continues to make the clipboard contents available. Weston has a simple functionality, but without the optimization to only store the clipboard contents on exit. Mutter does not currently offer this. * Restarting gnome-shell: Under X11, gnome-shell can be restarted at will without losing the current session (using Alt F2 → "r"). Similarly, the user session under X11 can survive a crash in gnome-shell as the session manager will automatically restart it. nder Wayland, being the Wayland compositor as well, gnome-shell cannot be restarted without restarting the entire user session. Using Alt F2 → "r" states that "Restart is not available on Wayland". As a result, if gnome-shell crashes under Wayland, the entire user session is terminated unexpectedly. * Active grabs in Wayland and Xwayland: Under X11, applications can have active grabs on either the pointer or the keyboard. Applications such as virtual machine viewers use this feature. By design (and on purpose), Wayland doesn't allow clients to have an active grab so it's a bit complicated for Xwayland to translate these to the Wayland compositor. A possibility would be to use a Wayland protocol to inform the compositor that a Wayland or Xwayland application requests an active grab. The compositor would then either allow or deny the grab, possibly inform/ask the user and provide visual feedback when a grab is active. * Running graphical applications as root is not authorized by default: our current X11 policy when running under wayland doesn't autorize root gui applications in a user session. This can be workarounded using xhost +SI:localuser:root. This is problematic for YaST2. YaST2 should be updated to no longer run its UI as root and use polkit to get root credentials when needed.

×
Edit Comment 2442
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Current status of Wayland regressions (partially based on Fedora25 status page at https://fedoraproject.org/wiki/Wayland_features ) * requirement: switch to libinput * Color temperature control (partially fixed in GNOME 3.24, display calibration protocol is still under discussion upstream). * remote display: some people at RH started working on implementing it in mutter in Q1 2016 (with VNC) but they never released their prototype and worked on some other part of Wayland support. This is a blocker to make Wayland by default on SLE * Wacom tablet configuration support: will be available in GNOME 3.24. * Accessibility (keyboard): Under X, key repeat and AccessX features (sticky keys, slow keys, bounce keys, toggle keys, etc) are implemented in the X server. Under Wayland, GTK+ currently implements key repeat on the client-side. There is a branch which adds the AccessX features, but implementing these client-side is not ideal, and leads to some regressions. Moving it to the compositor is not trivial, because we then need to 'neuter' the AccessX implementation in xwayland. * accessibility (mouse): Mouse accessibility features such as hover-to-click need to be reimplemented in the compositor. In contrast to keyboard accessibility, these features are implemented outside the X server for X (in mousetweaks), so this is a bit simpler wrt to xwayland. * accessibility (device controller): Orca has a feature called 'mouse review' which relies on the at-spi-registryd deviceeventcontroller interface to 'remote control' the pointer. To provide this functionality under Wayland, mutter needs to provide a device controller interface and at-spi-registryd needs to use it. After discussing this with Jonas, this should be a D-Bus interface, it doesn't need to be a Wayland protocol. * Outputs on secondary GPUs: Laptops where the external outputs are only connected to a secondary GPU needs to be supported in some form. These work under X currently using reverse prime. (not sure of the current status) * Remove X11 requirement in mutter: Currently, mutter will start Xwayland at startup unconditionally because it still depends on "X11 backend to GTK+ for various things within Mutter and GNOME Shell, such as theme drawing and input methods. I think we'd need to eliminate the use of GTK+ for input methods, then have some no-backend mode to use GTK+ for theme drawing without actually opening a connection to a display server". Not a big problem, we just have a X server running in the background. * Nvidia driver support: we need to enable VNGL in Mesa (see Wayland mesa FATE) * Clipboard manager: Under X11, gnome-settings-daemon offers an api to store the contents of the clipboard when the selection owner exits, and continues to make the clipboard contents available. Weston has a simple functionality, but without the optimization to only store the clipboard contents on exit. Mutter does not currently offer this. * Restarting gnome-shell: Under X11, gnome-shell can be restarted at will without losing the current session (using Alt F2 → "r"). Similarly, the user session under X11 can survive a crash in gnome-shell as the session manager will automatically restart it. nder Wayland, being the Wayland compositor as well, gnome-shell cannot be restarted without restarting the entire user session. Using Alt F2 → "r" states that "Restart is not available on Wayland". As a result, if gnome-shell crashes under Wayland, the entire user session is terminated unexpectedly. * Active grabs in Wayland and Xwayland: Under X11, applications can have active grabs on either the pointer or the keyboard. Applications such as virtual machine viewers use this feature. By design (and on purpose), Wayland doesn't allow clients to have an active grab so it's a bit complicated for Xwayland to translate these to the Wayland compositor. A possibility would be to use a Wayland protocol to inform the compositor that a Wayland or Xwayland application requests an active grab. The compositor would then either allow or deny the grab, possibly inform/ask the user and provide visual feedback when a grab is active. * Running graphical applications as root is not authorized by default: our current X11 policy when running under wayland doesn't autorize root gui applications in a user session. This can be workarounded using xhost +SI:localuser:root. This is problematic for YaST2. YaST2 should be updated to no longer run its UI as root and use polkit to get root credentials when needed.
 
×
Reply to fcrozat
Current status of Wayland regressions (partially based on Fedora25 status page at https://fedoraproject.org/wiki/Wayland_features ) * requirement: switch to libinput * Color temperature control (partially fixed in GNOME 3.24, display calibration protocol is still under discussion upstream). * remote display: some people at RH started working on implementing it in mutter in Q1 2016 (with VNC) but they never released their prototype and worked on some other part of Wayland support. This is a blocker to make Wayland by default on SLE * Wacom tablet configuration support: will be available in GNOME 3.24. * Accessibility (keyboard): Under X, key repeat and AccessX features (sticky keys, slow keys, bounce keys, toggle keys, etc) are implemented in the X server. Under Wayland, GTK+ currently implements key repeat on the client-side. There is a branch which adds the AccessX features, but implementing these client-side is not ideal, and leads to some regressions. Moving it to the compositor is not trivial, because we then need to 'neuter' the AccessX implementation in xwayland. * accessibility (mouse): Mouse accessibility features such as hover-to-click need to be reimplemented in the compositor. In contrast to keyboard accessibility, these features are implemented outside the X server for X (in mousetweaks), so this is a bit simpler wrt to xwayland. * accessibility (device controller): Orca has a feature called 'mouse review' which relies on the at-spi-registryd deviceeventcontroller interface to 'remote control' the pointer. To provide this functionality under Wayland, mutter needs to provide a device controller interface and at-spi-registryd needs to use it. After discussing this with Jonas, this should be a D-Bus interface, it doesn't need to be a Wayland protocol. * Outputs on secondary GPUs: Laptops where the external outputs are only connected to a secondary GPU needs to be supported in some form. These work under X currently using reverse prime. (not sure of the current status) * Remove X11 requirement in mutter: Currently, mutter will start Xwayland at startup unconditionally because it still depends on "X11 backend to GTK+ for various things within Mutter and GNOME Shell, such as theme drawing and input methods. I think we'd need to eliminate the use of GTK+ for input methods, then have some no-backend mode to use GTK+ for theme drawing without actually opening a connection to a display server". Not a big problem, we just have a X server running in the background. * Nvidia driver support: we need to enable VNGL in Mesa (see Wayland mesa FATE) * Clipboard manager: Under X11, gnome-settings-daemon offers an api to store the contents of the clipboard when the selection owner exits, and continues to make the clipboard contents available. Weston has a simple functionality, but without the optimization to only store the clipboard contents on exit. Mutter does not currently offer this. * Restarting gnome-shell: Under X11, gnome-shell can be restarted at will without losing the current session (using Alt F2 → "r"). Similarly, the user session under X11 can survive a crash in gnome-shell as the session manager will automatically restart it. nder Wayland, being the Wayland compositor as well, gnome-shell cannot be restarted without restarting the entire user session. Using Alt F2 → "r" states that "Restart is not available on Wayland". As a result, if gnome-shell crashes under Wayland, the entire user session is terminated unexpectedly. * Active grabs in Wayland and Xwayland: Under X11, applications can have active grabs on either the pointer or the keyboard. Applications such as virtual machine viewers use this feature. By design (and on purpose), Wayland doesn't allow clients to have an active grab so it's a bit complicated for Xwayland to translate these to the Wayland compositor. A possibility would be to use a Wayland protocol to inform the compositor that a Wayland or Xwayland application requests an active grab. The compositor would then either allow or deny the grab, possibly inform/ask the user and provide visual feedback when a grab is active. * Running graphical applications as root is not authorized by default: our current X11 policy when running under wayland doesn't autorize root gui applications in a user session. This can be workarounded using xhost +SI:localuser:root. This is problematic for YaST2. YaST2 should be updated to no longer run its UI as root and use polkit to get root credentials when needed.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview