Xorg update adds touchpad gestures and variable refresh support (2021) | Hacker News Reader

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

lists.x.org

110 pointsirthomasthomas64 comments

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

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

Recent and related:

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

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

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.

Wine doesn't work on Wayland period. You need wine-wayland and that only does games not regular windows programs

Also all tiling window managers will need to be rewritten from scratch basically as Wayland's architecture is very different, which sucks.

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

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.

Did Xorg ever claim it was no longer being developed, or was that just something someone said in a blog post?

I found this:

https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...

> So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.

> ...

> So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes. But xserver is more than xfree86. Xwayland, Xwin, Xephyr, Xvnc, Xvfb: these are projects with real value that we should not give up. A better way to say it is that we can finally abandon xfree86.

---

I think that to the extent there's confusion, it's because a lot of people (myself included) don't understand the project structure of Xorg. I honestly still don't know what the distinction is between these projects, I just know that around this time people started saying that it was time to switch to Wayland.

> So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes

This seems a bit like developer hubris to me, a bit like when commercial developers are overconfident in deprecating things without understanding usage in the field. It's somewhat blind to actual usage. It isn't dead in that sense.

Now, the maintainer might not want to do it, and that's within their rights. But it's possible that somebody will step up to do any maintenance work. Which would probably be minimal but not zero.

The rumor is that it was abandoned 3 years ago due to resistance from upstream developers that are focused on Wayland. This could be true, since apparently, most of these changes had been done already, but not rolled out. So an independent developer, Povilas Kanapickas took up the challenge of releasing it. Well done, that man. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

Note, if you welcome this development, donations are equally welcome, and will probably lead directly to more such development.

Here is the author's Patreon: https://www.patreon.com/p12tic

Huh, there seem to be some activity in the repo over the last year from several people. Not an amazing amount but it's going forward it seems

Debian is definitely not a good distribution to test Wayland in its current state. A lot of packages are quite a few stable version behind, and the whole Wayland ecosystem is moving really quickly (for example, Gnome 3.38 instead of Gnome 41)

Staying on x11 makes more sense unless using Debian unstable or testing.

I'm on Debian unstable. Giving wayland a chance once per month on intel and nvidia cards. It seems usable on Intel although many minor X11 habits are broken (like selection), but totally unusable on nvidia (black screen). X11 is still way to go, as 13 year in development is not enough for Wayland.

Nvidia just fixed its driver this year, and it's still not in great shape. You can only blame Nvidia for that.

We have quite different experiences I guess. On my side I just see that the recurring graphical issues that I had with X11 are fixed. Everything is super smooth, no tearing and really stable. Bonus points some of the side initiatives also improved a lot the ecosystem, like Pipewire.

Currently running Gnome from a Wayland session with Nvidia's 510.39.01 drivers without issue. It's not Wayland that's not ready yet, it's the ecosystem around it.

While the first commit on the Wayland git was in 2008, it's client and server APIs weren't considered stable until 2013 and then DE support for it only really picked up in 2016 since they were built around X11 from the beginning.

If you were an Nvidia user then your options for DEs were limited to the ones that supported EGLStreams and you didn't get XWayland hardware acceleration or support for Webrender in Firefox until Nvidia started support DMA-buf in June of last year. Nvidia didn't support GBM until October of this year but it had an annoying memory leak which caused issues with programs not wanting to launch of launching as black squares. On top of that, the code that compositors and XWayland used to detect whether to use GBM or EGLStreams didn't work at first and XWayland windows launched as transparent so they needed to be updated. It wasn't until these beta drivers, which came out this month, that I'm able to do everything I'm supposed to be able to do in a Wayland session and the major hurdles in Wayland adoption on Nvidia have been removed. Kwin already removed it's EGLStreams backend because it never worked well to begin with and the drivers will only improve from now on.

Selecting text with left clicks and pasting it with a middle click is a major feature of X11 IMHO. As a developer I copy and paste text all the time usually the X11 way, because if I select it's already in the clipboard and Ctrl-C is useless. I'm using a laptop with touchpad so I don't have to move my hands away from the keyboard. If I had to use a mouse then maybe I'd use Ctrl-C/V.

I also Ctrl-C/Ctrl-V files between directories in the file browser but not every week. I can also drag and drop them (move or copy). Everything other use of the clipboard happens less than once per month.

If left click / middle click doesn't work between all Wayland applications I can wait until all toolkits support it or X11 is removed from Linux.

I've been hearing this for years. I've got another machine with a rolling release distro (Arch) and it isn't any better. Until it is more mature I won't be using Wayland.

It isn't just the weird bugs. It not being able to share and/or record my screen. Everything works fine with X11, nothing works properly with Wayland. For I know there is some way of faffing with it to get it to work but what I have now works perfectly and I see no reason to change.

Screen recording and sharing works as well and it has been for a while.

No it doesn't. I literally tried every program I could find and almost none of them work with wayland. The only thing that works is the useless hidden gnome screen recorder than records the whole screen (and not a portion of it).

Slack, Discord and a bunch of other programs also don't work. They work fine in X11. I can screen share a window in wayland but not the whole screen. I frequently need to share the whole screen (when teaching people how to certain tasks).

The fact that I had to spend well over an hour trying to find something that works means it isn't ready. The existing software works perfectly in X11 and I see no point in trying wayland again anytime soon.

As someone who uses a graphics tablet (Wacom) I'm glad Xorg is somehow actively developed again or I would just switch to Mac/Windows.

I tried Wayland for around four years (GNOME, sway, KDE), almost daily. I have a multiple monitor setup. I always had to switch back to Xorg for several reasons, like:

- iBus CJK support was horrible. Languages like English, Russian or Spanish don't need that but Japanese/Chinese needs it. Things like the suggestions window was completely broken (misplaced and disappeared randomly). I used several tricks to work around it but it was quite uncomfortable.

- Wine refusing to work half of the time (even with the Virtual Desktop)

- VSync not working with games (making my GPU go 100%)

- Applications crashing for no apparent reason.

- XWayland crashing completely... Even the whole compositor would crash randomly making me lose all my work.

- But the worst thing was the drawing tablet. It was completely broken. Things like pen sensibility (quite important to get details right), screen locking (it's useless to draw with less than half of the tablet!) and top buttons.

I used Wayland since it was really smooth with an old Intel GPU. The Xorg experience was quite unstable (I couldn't find the right compositor configuration). One day I was quite fed up, got a new rig with an AMD GPU and removed Wayland completely. Compared with Wayland, even with its quirks, Xorg just works.

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?

Last time I tried (admittedly a couple years ago) this was not possible with wayland

This sounds vary familiar to Synergy. If you're familiar with that project, would you say this (x2x) is better?

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.

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

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.

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

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

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/

Golden times.

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.

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

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

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.

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

I seem to have missed that, thank you. The distro I was using didn't come with any of that stuff, and me being on an Nvidia card I didn't stick around long enough to read the wiki.

Sway has had support for both of those for years.

Tray: https://github.com/swaywm/sway/releases/tag/0.14.0

Screenshot: https://github.com/swaywm/sway/releases/tag/0.10

Gnome 3 is so bad that it drove my family members, who I had managed to switch to Linux painlessly over ten years ago, back to using Windows.

It's just an awful, painfully dim UX. The Tyranny of the Designer is on full display.

With HiDPI finally getting mature in MATE I may be able to convince them to return. But I suspect the nightmare that is Snap will keep them away.

With extensions it was possible to get a functional desktop up and running, but nothing short of a hassle. GNOME 40 is just a desolate wasteland of poor design decisions by comparison, if your family thought GNOME 3 was bad, they'd be flabbergasted by the newer releases.

Guess what happens when you reimplement everything from scratch again every few years? Functionality is lost and never regained. Just one more rewrite and it'll all be awesome, right?

I think the problem is Freedesktop. It is a shill for RedHat and GNOME (actually created by somebody who works for both) so every project gets railroaded by whatever those two want, rather than what users want or what is simpler design. The result is a lot of garbage that just makes users' lives worse.

What really scares me is that in Wayland programs must do their own window management. I realy hate when a program decides that it shall change position or shape on the screen or when it decides to draw on the titlebar making window operations like maximizing a pain.

Have you heard about GNOME's Client-Side Decorations Initiative? The gist is that GNOME does not want to implement/maintain window decorations (title bars, minimize/maximize buttons) in their Wayland compositor, so instead (in typical GNOME fashion) they want every other Linux desktop app to add code to draw decorations themselves (in whichever style they want).

https://wiki.gnome.org/Initiatives/CSD

Then why do they want clients to use Gnome (indtead of other libraries) ? When every program does what he wants why do we need a "Desktop environment " ?

Despite being one of the most powerful, well-funded projects in the desktop Linux space, the GNOME devs runs a notorious "my way or the highway" policy that consistently makes it increasingly difficult for smaller teams to develop their own desktops. Components like libadwaita, Flatpak, Wayland, and GTK4 only further contribute to this initiative. Don't just take my word for it though, ask anyone on Linux developing desktop apps: GNOME has been driving a wedge between developers for a while now.

Now you're starting to understand why some of us don't want to have Gnome anywhere near our Linux desktops when every bit of functionality that we actively use gets deprecated and removed. I loved my Linux desktop back in the early '00s when Gnome and Enlightenment provided configurable window decorations and transparent terminals, but all that configurability in Gnome has been hidden and then ripped out over the past 20 years of "progress".

Three cheers for ostracizing your userbase and shrinking your development team down to an authoritarian handful of members that doesn't care about your opinions!

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.

I don't think that's ever going to happen because XWayland exists.

Weston has always had an x11 backend.

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.

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.

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.

"why not let me continue to use X11?"

You CAN continue to use X11. There just isn't much point for most applications especially since XWayland lets you run X11 applications in a Wayland session. Wayland is more efficient than X11. Phoronix recently did benchmarks with games in both and Gnome's and KDE's Wayland sessions outperformed the Xorg session while using less power even though those applications were using XWayland.

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

That isn't how any of this works. Weston's X11 backend, just like the X11 backend of all DEs, relies on Xorg. There's nothing worthwhile from a Weston's X11 backend to implement into Xorg.

"Do we need an IPv4 vs IPv6 battle again?"

I mean the same people who worked on Xorg work on Wayland.They didn't come up with it for no reason. X is a protocol from 1983 and has been on version 11 since 1987. It predates GPUs, OpenGL, compositors, and multi-core desktop CPUs. They actually explain the rationale behind Wayland and what's wrong with X11 in the Wayland FAQ.

https://wayland.freedesktop.org/faq.html

If you look at the ideas that were drafted for X12, you can see that Wayland is pretty in line with it. https://www.x.org/wiki/Development/X12/?action=diff

"Moreover, those «program X uses Wayland, but bla-bla-bla... set this environment variable to use X11 backend» are frustrating."

I don't know how else you would like that work.

10 years later where is Wayland...

Note this update was released 3 months ago.

Yeah, but the release from this month is fairly boring:

* https://lists.x.org/archives/xorg/2022-January/060861.html

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.

It depends on laptop and distro. A lot of new laptops don't work with slow release distros like ubuntu/debian.

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.

(September 2021)

Reply on news.ycombinator.com