9 ms·

Xorg update adds touchpad gestures and variable refresh support (2021)

110 points by irthomasthomas 5y ago

davidkunz 5y ago
In KDE, you could add mouse gestures across your desktop (KHotkeys), I used that feature to enable mouse gestures for all browsers 13 years ago: https://store.kde.org/p/1081269/ https://store.kde.org/p/1081269/ Golden times.
- mkdirp 5y ago
  These feature changes are not mouse gestures, this is about touchpad gestures. Mouse gestures are nice, but they're not great to perform using a touchpad.
sva_ 5y ago
(September 2021)
Macha 5y ago
Note this update was released 3 months ago.
- upofadown 5y ago
  Yeah, but the release from this month is fairly boring: * https://lists.x.org/archives/xorg/2022-January/060861.html https://lists.x.org/archives/xorg/2022-January/060861.html
YEwSdObPQT 5y ago
I am glad Xorg is development is continuing. However I don't understand the status of the project, I was under the impression it was simply just being maintained rather than actively developed. Personally I have been unimpressed with Wayland. Configuration, Stability and the ability to easily record my screen makes me stick with Xorg over Wayland (I am using an AMD GPU with Debian 11).
- mmcdermott 5y ago
  That matches my experience as well. I'll do a fresh distro install and not notice at first if it defaults to Wayland, then I'll run into something. It might be crashe or app compatibility (I had a game on Wine once that crashed on Wayland but not X11), but it drives me to switch things over to X11.
  - ugjka 5y ago
    Wine doesn't work on Wayland period. You need wine-wayland and that only does games not regular windows programs
  - nextos 5y ago
    Also all tiling window managers will need to be rewritten from scratch basically as Wayland's architecture is very different, which sucks.
    - CyberShadow 5y ago
      It's worse than that. Window managers simply cannot exist in Wayland, because the compositor is the only actor which can also do window management. This coupling is one of the biggest design faults of Wayland. The platform-specific functionality is no longer encapsulated in a stand-alone piece of software - the compositor now must do everything, because Wayland trusts only it to do anything privileged. This leads to less choice and more restrictions. If you wanted to get X11 running on e.g. your phone, you would get the Xorg server Android app, then run the window manager you want, then run the applications you want. This is not possible in Wayland: there would need to be one per-platform app per compositor / window manager, so you would need e.g. Weston for Linux, Weston for Android, Weston for iOS, sway for Linux, sway for Android, sway for iOS, ...
      - porkloin 5y ago
        For this exact reason I think we're going to see a lot more development of DE-specific tiling window management solutions, like Pop Shell, PaperWM, Material Shell, etc., are doing for Gnome. They all just leverage the Gnome Shell extension system, but are inextricably dependent on Gnome.
drran 5y ago
When Xorg will have native support for Wayland protocol (as extension)? I want to use both Xorg clients and Wayland clients, but without Wayland limitations.
- ZiiS 5y ago
  Weston has always had an x11 backend.
- titaniumtown 5y ago
  I don't think that's ever going to happen because XWayland exists.
- CyberShadow 5y ago
  I think a big part of Wayland's limitations is in its protocol, and are "by design". Getting Wayland to have feature-parity with X would require extending the protocol, and then implementing those extensions in both compositors and clients. Because major Wayland compositor projects are unlikely to want to adopt or maintain such extensions, getting client applications to support them would also be a tough sell.
- myownfriend 5y ago
  If Xorg could have the functionality of Wayland (mixed refresh rates, mixed DPI scaling, and the performance benefits) then Wayland wouldn't exist. Things like global cursor coordinates, screen capture, and window automation are intended to or already are being done through things like xdg-desktop-portals which ask for user for permission before an application is allowed to do these things.
  - drran 5y ago
    If I need none of those, but need variable refresh rate for higher FPS in games, and if I trust my system because I use none flatpacks or snaps, then why not let me continue to use X11? Why not just integrate Weston X11 backend into Xorg and then let application developers to drop support for X11 completely, while letting me keep using X11? Do we need an IPv4 vs IPv6 battle again? Moreover, those «program X uses Wayland, but bla-bla-bla... set this environment variable to use X11 backend» are frustrating.
irthomasthomas 5y ago
Sorry, there's actually a newer announcement from October that I couldn't see before. https://lists.x.org/archives/xorg/2021-October/060799.html https://lists.x.org/archives/xorg/2021-October/060799.html >Notable changes since 1.20 include: - The meson support is now fully mature. While autotools support will still be kept for this release series, it will be dropped afterwards. - Glamor support for Xvfb. - Variable refresh rate support in the modesetting driver. - XInput 2.4 support which adds touchpad gestures. - DMX DDX has been removed. - X server now correctly reports display DPI in more cases. This may affect rendering of client applications that have their own workarounds for hi-DPI screens.
jancsika 5y ago
One thing I like about X is I can run x2x over ssh to move my mouse pointer and keyboard control from my laptop to my rpi-hooked-to-a-TV. So I can watch stuff on the TV, and when I want to choose a new thing I just mouse past the edge of my laptop screen and now I'm mousing and typing on the rpi. Is this currently possible under Wayland with stock Ubuntu and stock Raspbian?
- edgyquant 5y ago
  Last time I tried (admittedly a couple years ago) this was not possible with wayland
- pak9rabid 5y ago
  This sounds vary familiar to Synergy. If you're familiar with that project, would you say this (x2x) is better?
  - biomcgary 5y ago
    I loved Synergy, but it has gone commercial, so I use Barrier, which forked from one of the last free commits. Works well across Linux, Windows, and Mac OS.
    - jancsika 5y ago
      From Barrier's github repo[1]: > We will also have our eye on Wayland when the time comes. Every time I've inquired about $simple_x11_thing for Wayland I find smells like this one. Does Barrier work under Wayland, or not? 1: https://github.com/debauchee/barrier https://github.com/debauchee/barrier
Thaxll 5y ago
10 years later where is Wayland...
varispeed 5y ago
IDK touch pad support seems so buggy in Linux. Often times the cursor will jump randomly or disappear altogether and then all you can do is reboot and pray it won't happen again. No errors logged anywhere and if you try to find a solution, it's just people trying random things that don't work. If I sum the time spent on trying to get touchpad to work it's probably going to be a good work week with no results. Now my touchpad been okay for two months, but you never know when it again will start acting funny.
- allisdust 5y ago
  It depends on laptop and distro. A lot of new laptops don't work with slow release distros like ubuntu/debian.
- irthomasthomas 5y ago
  Weird, I have used a lot of different laptops and Linux combos and can't say I have ever had touchpad problems, fortunately. In fact, I am frequently delighted at how truly plug-n-play hardware is on Linux now.
smoldesu 5y ago
I'm so happy that Xorg is still being maintained, the more I read about Wayland, the happier I become to stay on Xorg. If you really want to erode your faith in open-source software, open up the bug tracker for Wayland and click through the closed issues, some of them[0] are fairly reasonable requests that are met with hostility and disinterest by the developers. I'm starting to understand what people mean when they say that Wayland is a self-serving project by the GNOME developers, too. Do we need a status tray API? Nah, GNOME doesn't use it. Should we add stable screenshot interfaces? Nope, GNOME already made one. And here we are, 10 years later, and there's only 3 desktop environments that use Wayland (GNOME, Plasma and Sway), two of which aren't even complete. I understand the "we aren't remaking x11" argument, but that's not an excuse to design a worse window server and give a middle finger to the rest of the desktop environments and window managers that people want to use. GNOME's continued attempts to divide the Linux community with pointless middleware and poorly designed software is starting to bite them in the ass. Most people I know these days have no intention of switching to Wayland any time soon, which is a shame since x11 really sucks; it shouldn't be this hard to design a successor to software that's as bad as Xorg. [0] https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233
- folkrav 5y ago
  This intrigued me: > (GNOME, Plasma and Sway), two of which aren't even complete Which ones are you referring to as non complete? I think it's pretty obvious for Plasma, but the other...?
  - smoldesu 5y ago
    I tried Sway a few months ago and it's still missing rudimentary features like screenshotting and tray icons. I'm not sure if the situation has improved yet, but if Sway is trying to be a drop-in replacement for i3 then they've still got work to do.
    - boudin 5y ago
      Screenshots works in Sway, it has been there for years. Tray icons as well (it depends of the bar you use though, but it works with the included bar swaybar and waybar). you can use grim + slurp for screenshots https://github.com/emersion/grim https://github.com/emersion/grim but Flameshot works as well (for example). Edit: you should have a look at the wiki: https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway
ncmncm 5y ago
Notably, QubesOS has demonstrated that a secure X environment is possible. In Qubes, an isolated VM "dom0" operates the physical display, input devices, and desktop widgets. Apps run in VMs, which each maintain a private X server. Storage for windows in each such X is mapped to address space in dom0. dom0 copies updates to this memory to the physical display. Input events that occur with the pointer in a window are sent to that window's corresponding X server. The limitation is that the app VMs have no access to a GPU. Some people manage to get a GPU assigned to an app VM, but GPUs generally have DMA access to all of physical memory, so this compromises security if code operating the GPU is not trusted. There has been work on virtualizing access to the GPU, particularly in the SpectrumOS development effort.
- hulitu 5y ago
  > The limitation is that the app VMs have no access to a GPU. Some people manage to get a GPU assigned to an app VM, but GPUs generally have DMA access to all of physical memory, so this compromises security if code operating the GPU is not trusted. Well the code executing on the GPU is trusted. What is not trusted is code running in the browser. The problem is that Wayland instead of not trusting the clients which shall not be trusted (browser), trusts only one client at a time. So you have security against local programs (which shall be trusted) but no security against remote code running in the browser.
  - ncmncm 5y ago
    Where did the code executing on the GPU come from? By definition, nothing running in the app VM is trusted; that is the whole point of fencing off the app in a VM. The VM is safe against remote code running in the browser only until the remote code finds a hole in the browser security, i.e. for about a millisecond. Once the browser is compromised, the remote attacker can run anything they want in the GPU, if the VM has access to one. (Maybe they need a privilege escalation first, but those are a dime a dozen.)
dang 5y ago
Recent and related: Xorg-Server 21.1.0 - https://news.ycombinator.com/item?id=29016318 https://news.ycombinator.com/item?id=29016318 - Oct 2021 (164 comments)

In KDE, you could add mouse gestures across your desktop (KHotkeys), I used that feature to enable mouse gestures for all browsers 13 years ago: https://store.kde.org/p/1081269/ https://store.kde.org/p/1081269/ Golden times.

mkdirp 5y ago
These feature changes are not mouse gestures, this is about touchpad gestures. Mouse gestures are nice, but they're not great to perform using a touchpad.

sva_ 5y ago

(September 2021)

Macha 5y ago

Note this update was released 3 months ago.

upofadown 5y ago
Yeah, but the release from this month is fairly boring: * https://lists.x.org/archives/xorg/2022-January/060861.html https://lists.x.org/archives/xorg/2022-January/060861.html

YEwSdObPQT 5y ago

I am glad Xorg is development is continuing. However I don't understand the status of the project, I was under the impression it was simply just being maintained rather than actively developed. Personally I have been unimpressed with Wayland. Configuration, Stability and the ability to easily record my screen makes me stick with Xorg over Wayland (I am using an AMD GPU with Debian 11).

mmcdermott 5y ago
That matches my experience as well. I'll do a fresh distro install and not notice at first if it defaults to Wayland, then I'll run into something. It might be crashe or app compatibility (I had a game on Wine once that crashed on Wayland but not X11), but it drives me to switch things over to X11.
- ugjka 5y ago
  Wine doesn't work on Wayland period. You need wine-wayland and that only does games not regular windows programs
- nextos 5y ago
  Also all tiling window managers will need to be rewritten from scratch basically as Wayland's architecture is very different, which sucks.
  - CyberShadow 5y ago
    It's worse than that. Window managers simply cannot exist in Wayland, because the compositor is the only actor which can also do window management. This coupling is one of the biggest design faults of Wayland. The platform-specific functionality is no longer encapsulated in a stand-alone piece of software - the compositor now must do everything, because Wayland trusts only it to do anything privileged. This leads to less choice and more restrictions. If you wanted to get X11 running on e.g. your phone, you would get the Xorg server Android app, then run the window manager you want, then run the applications you want. This is not possible in Wayland: there would need to be one per-platform app per compositor / window manager, so you would need e.g. Weston for Linux, Weston for Android, Weston for iOS, sway for Linux, sway for Android, sway for iOS, ...
    - porkloin 5y ago
      For this exact reason I think we're going to see a lot more development of DE-specific tiling window management solutions, like Pop Shell, PaperWM, Material Shell, etc., are doing for Gnome. They all just leverage the Gnome Shell extension system, but are inextricably dependent on Gnome.

drran 5y ago

When Xorg will have native support for Wayland protocol (as extension)? I want to use both Xorg clients and Wayland clients, but without Wayland limitations.

ZiiS 5y ago
Weston has always had an x11 backend.
titaniumtown 5y ago
I don't think that's ever going to happen because XWayland exists.
CyberShadow 5y ago
I think a big part of Wayland's limitations is in its protocol, and are "by design". Getting Wayland to have feature-parity with X would require extending the protocol, and then implementing those extensions in both compositors and clients. Because major Wayland compositor projects are unlikely to want to adopt or maintain such extensions, getting client applications to support them would also be a tough sell.
myownfriend 5y ago
If Xorg could have the functionality of Wayland (mixed refresh rates, mixed DPI scaling, and the performance benefits) then Wayland wouldn't exist. Things like global cursor coordinates, screen capture, and window automation are intended to or already are being done through things like xdg-desktop-portals which ask for user for permission before an application is allowed to do these things.
- drran 5y ago
  If I need none of those, but need variable refresh rate for higher FPS in games, and if I trust my system because I use none flatpacks or snaps, then why not let me continue to use X11? Why not just integrate Weston X11 backend into Xorg and then let application developers to drop support for X11 completely, while letting me keep using X11? Do we need an IPv4 vs IPv6 battle again? Moreover, those «program X uses Wayland, but bla-bla-bla... set this environment variable to use X11 backend» are frustrating.

irthomasthomas 5y ago

Sorry, there's actually a newer announcement from October that I couldn't see before. https://lists.x.org/archives/xorg/2021-October/060799.html https://lists.x.org/archives/xorg/2021-October/060799.html >Notable changes since 1.20 include: - The meson support is now fully mature. While autotools support will still be kept for this release series, it will be dropped afterwards. - Glamor support for Xvfb. - Variable refresh rate support in the modesetting driver. - XInput 2.4 support which adds touchpad gestures. - DMX DDX has been removed. - X server now correctly reports display DPI in more cases. This may affect rendering of client applications that have their own workarounds for hi-DPI screens.

jancsika 5y ago

One thing I like about X is I can run x2x over ssh to move my mouse pointer and keyboard control from my laptop to my rpi-hooked-to-a-TV. So I can watch stuff on the TV, and when I want to choose a new thing I just mouse past the edge of my laptop screen and now I'm mousing and typing on the rpi. Is this currently possible under Wayland with stock Ubuntu and stock Raspbian?

edgyquant 5y ago
Last time I tried (admittedly a couple years ago) this was not possible with wayland
pak9rabid 5y ago
This sounds vary familiar to Synergy. If you're familiar with that project, would you say this (x2x) is better?
- biomcgary 5y ago
  I loved Synergy, but it has gone commercial, so I use Barrier, which forked from one of the last free commits. Works well across Linux, Windows, and Mac OS.
  - jancsika 5y ago
    From Barrier's github repo[1]: > We will also have our eye on Wayland when the time comes. Every time I've inquired about $simple_x11_thing for Wayland I find smells like this one. Does Barrier work under Wayland, or not? 1: https://github.com/debauchee/barrier https://github.com/debauchee/barrier

Thaxll 5y ago

10 years later where is Wayland...

varispeed 5y ago

IDK touch pad support seems so buggy in Linux. Often times the cursor will jump randomly or disappear altogether and then all you can do is reboot and pray it won't happen again. No errors logged anywhere and if you try to find a solution, it's just people trying random things that don't work. If I sum the time spent on trying to get touchpad to work it's probably going to be a good work week with no results. Now my touchpad been okay for two months, but you never know when it again will start acting funny.

allisdust 5y ago
It depends on laptop and distro. A lot of new laptops don't work with slow release distros like ubuntu/debian.
irthomasthomas 5y ago
Weird, I have used a lot of different laptops and Linux combos and can't say I have ever had touchpad problems, fortunately. In fact, I am frequently delighted at how truly plug-n-play hardware is on Linux now.

smoldesu 5y ago

I'm so happy that Xorg is still being maintained, the more I read about Wayland, the happier I become to stay on Xorg. If you really want to erode your faith in open-source software, open up the bug tracker for Wayland and click through the closed issues, some of them[0] are fairly reasonable requests that are met with hostility and disinterest by the developers. I'm starting to understand what people mean when they say that Wayland is a self-serving project by the GNOME developers, too. Do we need a status tray API? Nah, GNOME doesn't use it. Should we add stable screenshot interfaces? Nope, GNOME already made one. And here we are, 10 years later, and there's only 3 desktop environments that use Wayland (GNOME, Plasma and Sway), two of which aren't even complete. I understand the "we aren't remaking x11" argument, but that's not an excuse to design a worse window server and give a middle finger to the rest of the desktop environments and window managers that people want to use. GNOME's continued attempts to divide the Linux community with pointless middleware and poorly designed software is starting to bite them in the ass. Most people I know these days have no intention of switching to Wayland any time soon, which is a shame since x11 really sucks; it shouldn't be this hard to design a successor to software that's as bad as Xorg. [0] https://gitlab.freedesktop.org/wayland/wayland/-/issues/233 https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

folkrav 5y ago
This intrigued me: > (GNOME, Plasma and Sway), two of which aren't even complete Which ones are you referring to as non complete? I think it's pretty obvious for Plasma, but the other...?
- smoldesu 5y ago
  I tried Sway a few months ago and it's still missing rudimentary features like screenshotting and tray icons. I'm not sure if the situation has improved yet, but if Sway is trying to be a drop-in replacement for i3 then they've still got work to do.
  - boudin 5y ago
    Screenshots works in Sway, it has been there for years. Tray icons as well (it depends of the bar you use though, but it works with the included bar swaybar and waybar). you can use grim + slurp for screenshots https://github.com/emersion/grim https://github.com/emersion/grim but Flameshot works as well (for example). Edit: you should have a look at the wiki: https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway

ncmncm 5y ago

Notably, QubesOS has demonstrated that a secure X environment is possible. In Qubes, an isolated VM "dom0" operates the physical display, input devices, and desktop widgets. Apps run in VMs, which each maintain a private X server. Storage for windows in each such X is mapped to address space in dom0. dom0 copies updates to this memory to the physical display. Input events that occur with the pointer in a window are sent to that window's corresponding X server. The limitation is that the app VMs have no access to a GPU. Some people manage to get a GPU assigned to an app VM, but GPUs generally have DMA access to all of physical memory, so this compromises security if code operating the GPU is not trusted. There has been work on virtualizing access to the GPU, particularly in the SpectrumOS development effort.

hulitu 5y ago
> The limitation is that the app VMs have no access to a GPU. Some people manage to get a GPU assigned to an app VM, but GPUs generally have DMA access to all of physical memory, so this compromises security if code operating the GPU is not trusted. Well the code executing on the GPU is trusted. What is not trusted is code running in the browser. The problem is that Wayland instead of not trusting the clients which shall not be trusted (browser), trusts only one client at a time. So you have security against local programs (which shall be trusted) but no security against remote code running in the browser.
- ncmncm 5y ago
  Where did the code executing on the GPU come from? By definition, nothing running in the app VM is trusted; that is the whole point of fencing off the app in a VM. The VM is safe against remote code running in the browser only until the remote code finds a hole in the browser security, i.e. for about a millisecond. Once the browser is compromised, the remote attacker can run anything they want in the GPU, if the VM has access to one. (Maybe they need a privilege escalation first, but those are a dime a dozen.)

dang 5y ago

Recent and related: Xorg-Server 21.1.0 - https://news.ycombinator.com/item?id=29016318 https://news.ycombinator.com/item?id=29016318 - Oct 2021 (164 comments)