KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

[oiaohm]

Nope, developers cannot talk to libinput when using wayland, this is intentional, because "keyloggers".

No libinput is libinput. evdev is locked the same way be it wayland compositor or X11 server bare metal. Also the old x11 edev driver also locks it the same way as current day libinput. Only way to override the lock is have the right capabilities what most have done by having process run as root.

do let me know how a proposal to allow keyloggers on wayland works out, you seem optimistic.

No this is why raw evdev access from applications is so rare. Because they are basically system wide keyloggers.

inputfd is something different. When a process losses focus the direct input access it has can be revoked under inputfd and re-granted when it gains focus again.
This is using kernel level privilege controls over file handles.

KDE is switching to gamescope for their wayland compositor? that's pretty big news.
Or are you advocating abandoning KDE and everyone switching to SteamOS?

I have told you about this enough times. KDE developer working on Wayland robustness. Why is he testing changing Wayland compositors on the fly. That right KDE developers are very aware that one size fits all is most likely wrong.

KDE will keep they kwin compositor but they also want the means to use gamescope or any other compositor for any case where that compositor is better than theirs. Also robustness will allow applications to be suspended to disc so removing their GPU/CPU usage when you are doing high performance task without losing where you are up-to.

Where this gets ultra fun xwayland already support wayland robustness. So yes you can start xwayland under gamescope kill gamescope and connect to to KDE kwin. Yes this trek can make X11 applications using raw evdev access work under kwin wayland today.

xwayland adds even more latency, and only supports applications that use the X11 protocol for device io.

That in fact true for the bare metal x11 server as well that it only support input devices by the X11 protocol. Only difference here is by default X11 exposes some meta data on what evdev items are being used. Xwayland can be made expose this metadata and gamescope has option to.

Of course you miss that the input stack in X11 server bare metal is in fact deeper than in gamescope+xwayland on the wayland side so your X11 bare metal server does in in fact have higher latency than a Wayland solution optimized for gaming.

Interesting point gamescope on the steamdeck and steamos does not have the option for direct evdev enabled at all because too few of applications use it.

https://wiki.winehq.org/Hid

/dev/hidraw
is different beast.
Yes allowing applications hidraw access is the same under Wayland and X11 no difference here at this time. Yes using hidraw to access game controllers and the like bipass wayland and x11 completely at this stage. Future inputfd may change that with proper security being done so application cannot have hidraw access when they don't have focus.

Keylogging/input logging when application does not have focus is a very big issue here. It a problem with hidraw that Wayland compositor and X11 bare metal server don't control.

mSparks basically you are clueless on this topic.

The there biggest problems that cause mouse issues with Wayland.
1) Wayland Compositor not having input processing in it own thread.
2) Hardware mouse cursor not working right this is a driver bug. Yes this one things go bad if you enabled hwcursor under x11 bare metal as well. There is environment var to disable plane that causes this. Yes Nvidia hardware is also known for advertising hwcursor support when it does not work. Wayland compositors default with this on does cause a few problems. Between stutter to slow mouse movement to no mouse cursor at all because hardware accelerated mouse cursor is not working correctly when the GPU driver advertised it support it.
3)GPU and CPU scheduler issues.

Like it or not is these are 3 problems not the garbage you are going on about. The idea that raw input has something todo with it does not make sense. Gamescope developer made the feature to allow raw evdev to work then disabled it because nothing uses it or at least nothing anyone plays any more.

Modern Games don't use raw evdev on the devices libinput claims like it or not. So nothing libinput claims interferes with them. Games that did this of using raw evdev on keyboard and mice you are talking pre 2000 games and rare ones at that. Linux users don't like rootkits game makers learnt fairly quickly their game sales would tank if they used raw evdev on keyboard and mice the items libinput claims under X11 bare metal or Wayland compositor.

Game-controllers in evdev libinput under X11 baremetal and Wayland compositors are not claimed/locked at this time.

One of the realities here you want low input lag for keyboards and mice with games under Linux you need Wayland inputfd to succeed so that raw input can be provided to applications from keyboards and mice without being keylogger/rootkit.

[mSparks]

No libinput is libinput. evdev is locked the same way be it wayland compositor or X11 server bare metal. Also the old x11 edev driver also locks it the same way as current day libinput. Only way to override the lock is have the right capabilities what most have done by having process run as root.

So all those people who said wayland is needed to prevent keyloggers were wrong?

or you are...

either way, if wayland isn't offering any benefit over xorg-server there is no point in adopting it.

KDE developer working on Wayland robustness.

The whole premise of this thread is a KDE developer saying they have effectively finished developing wayland and the only thing left is for 3rd parties to adopt it.

Seems again and again like you disagree with that as much as I do.

Like it or not is these are 3 problems not the garbage you are going on about. The idea that raw input has something todo with it does not make sense.

They may well be 3 other problems, and this may well be wayland fragmentation related,
But you seem oblivious to my experience, and that of many others who have tried recent wayland versions of KDE and gnome.
The high input latency makes them unusable.
Before you were blaming nvidia which was nonsense. Not multithreading the input stack would definitely explain why it is so bad, still not as good as interrupt based tho.

It has nothing to do with liking or disliking it. Its 100% about whether wayland is a good investment of time and money from my perspective.

And right now all wayland seems to offer is expense, high project delay risks and the probability of being completely abandoned in the not to distant future, well before it is ready to replace X11, for a significantly degraded user experience.

Surely you can see that is very far from a compelling offering for 3rd parties to invest time and money on?

[oiaohm]

So all those people who said wayland is needed to prevent keyloggers were wrong?

No they were not. evdev-libinput under X11 bare metal and Wayland compositors is identical. This is not where keyloggers are prevented.

X11 protocol itself you can write keyloggers. Your application wants a trigger on a hot key it can ask the X11 input device by X11 protocol to send your application all input no matter what. More applications doing this more times the X11 bare metal server need to duplicate the input message the more input latency you end up with.

Keyloggers under X11 are a latency nightmare. X11 Xinput idea of a raw device is not that raw. Its not a raw evdev item.

"libinput: kernel → libevdev → libinput → xf86-input-libinput → X server → X client"
Remember this I quoted before. Where is a X11 keylogger implemented. Its not kernel, its not libevdev its not libinput and its not xf86-input-libinput X11 keylogger is in the Xinput stack inside the X server itself. So there are bits in the X server that are not in that simple form.

So every X11 keylogger you have for hotkeys and the like the worse your X11 input latency comes with bare metal X11. Yes why the global hotkeys xdg-portal will be a good thing for X11 users as more applications use it instead of adding keylogger after keylogger slowing down the X11 input stack.

Wayland simple on the input side does not implement the code to have a keylogger in the wayland protocol.

You are wanting to fix X11 input latency issues you are wanting to-do the following.
1) prevent programs creating unlimited keyloggers that slow down the input stack. You wish to force applications to share keyloggers so you don't end up with your stack filled up with keyloggers.
2) create some system to allow applications to have true raw input device access in controlled way. xdg-desktop-portal to allow this under X11 now appears dead with only wayland applications with inputfd getting this feature.

Raw passing evdev access is the lowest latency option under Linux. But currently we have no system under X11 or Wayland to use this option cleanly.

https://github.com/flatpak/xdg-desktop-portal/issues/536

Yes flatpak allowing all device access on lots of applications is to allow applications to open up joysticks/controllers evdev that libinput never locks unless it told to use one as a mouse

Problem comes how to know when you should revoke the evdev access. X11 is not really designed for this.

The whole premise of this thread is a KDE developer saying they have effectively finished developing wayland and the only thing left is for 3rd parties to adopt it.

The KDE developer doing robustness is funded to work on gnome and other solutions after the Qt items are done. KDE developers are getting to the point they are needing the 3rd parties to find the sharp edged. KDE developers are running out of sharp edges to fix and have the problem that they have Wayland protocols of competing/incompatible designs to solve issues that they need feedback on this is where 3rd parties come in.

The KDE developers did not say they were finished with the statement you are just reading extra into it.

Before you were blaming nvidia which was nonsense. Not multithreading the input stack would definitely explain why it is so bad.

Its not nonsense. Nvidia has Hardware mouse cursor issues. Then you have issues where xwayland 3d acceleration is not working correctly resulting on game self rendered mouse cursors having issues with nvidia that you don't see with AMD and Intel... There are a stack of mouse issues with Wayland that are Nvidia unique because Nvidia drivers are currently garbage so disrupt the CPU scheduler when using DMABUF. Nvidia drivers is a particular problem child here.

https://blogs.gnome.org/shell-dev/2021/01/21/threaded-input-adventures/

Gnome still having thread locks in the wrong places. I put this under problem 1 this is that the threaded input is not correctly isolated. Yes the big kernel lock kind of problem all over again. What happens when you have legacy single threaded code and attempt to make it multi threaded you end up with a over all lock that stalls everything.

mSparks the mouse movement issues you have with KDE and Gnome with Wayland have different causes even if they look the sameish.

Nothing in the wayland protocol says that input latency under Wayland even with xwayland should be slower than bare metal X11. In fact input latency should be better with wayland and if input latency is not better you have some from of implementation issue. Yes every full investigated bug of input latency issues with wayland have end up showing this over and over again.

Its really easy to say I tried gnome/kde ... but did you have the skills or spend the time to track down where the problem really was coming from. No you did not instead you have been making up wild incorrect guesses.

Worse you also fail to notice that one of the things that can screw up input latency under X11 bare metal is all the applications that a user can have loaded that have global short cuts because they are all hooking in their own keylogger so ruining users input latency. Keyloggers are not just a security nightmare they are a input latency nightmare as well.

[mSparks]

"libinput: kernel → libevdev → libinput → xf86-input-libinput → X server → X client"
Remember this I quoted before.

indeed, the only real problem with it is xorg server doesn't need or use libinput at all.

libinput is a fairly new development

https://www.phoronix.com/news/xf86-input-libinput-1.0

With even less adoption than wayland, and very likely the cause of all the input system on wayland being broken.
3rd parties are compiling against xf86-input-evdev instead.

https://www.reddit.com/r/kde/comments/13qoood/use_evdev_as_mouse_driver_in_wayland/

[oiaohm]

indeed, the only real problem with it is xorg server doesn't need or use libinput at all.

So you don't want working modern touch pads on laptops thank you for playing.

xf86-input-evdev does not support touch pads.

Choice for touchpads under X11 baremetal is
xf86-input-synaptics
xf86-input-libinput
Also quirks with different gamer keyboards and mice are only corrected by libinput. Yes xf86-input-synaptics is not being updated and has not been updated to support modern touch-pads.

Again out of your depth. For lots of users getting away from libinput equals their hardware does not work.

https://www.phoronix.com/news/libinput-1.23-Released

Also that issue is before libinput got custom acceleration profiles. As you said libinput is new. Do note the people complaining about libinput have not been doing hardware latency measurements. So is the problem with libinput latency or just the acceleration profile. Yes evdev and libinput used on for a mouse do result in two different acceleration profiles.

Next inputfd(wayland) or the xdg-desktop-portal for input device(if it could be made work) would give you raw hardware access like you have under windows.

The reality is xf86-input-evdev has you still going through the slow X11 input stack. For gaming compared to windows both xf86-input-evdev and xf86-input-libinput are slow. Even the X11 xserver input stack alone is slow compared to direct input that games use under windows.

X11 server like it or not is not built for gaming/high performance input. True raw evdev access has to be worked out to make Linux gaming input competitive with windows.

[mSparks]

X11 server like it or not is not built for gaming/high performance input.

like I told you multiple times, from my testing

nanoseconds on xorg, milliseconds on wayland,
From other user reports
"In Wayland/xwayland is indeed hard to tell since it already introduces Inputlag. But in xorg is night and day"
"I am using synaptics. I’ve tried libinput on each of them and found it unusable."
"but as soon as we move towards Wayland-only (wine Wayland for example) I'm afraid that I become unable to use evdev for a better input lag and gaming experience."

But we don't need to argue that, FC40 adoption is going to clearly demonstrate how well it works for people. Maybe a miracle will happen between now and then and FC40 will be usable, only then will anyone consider adopting it.

wayland is very far from a compelling offering for 3rd parties to invest time and money on

agreed.

[oiaohm]

like I told you multiple times, from my testing

That was not repeatable on AMD hardware in configurations that work.

l"In Wayland/xwayland is indeed hard to tell since it already introduces Inputlag. But in xorg is night and day"
"I am using . So is the problem with libinput latency or just the acceleration profile.. I’ve tried libinput on each of them and found it unusable."
"but as soon as we move towards Wayland-only (wine Wayland for example) I'm afraid that I become unable to use evdev for a better input lag and gaming experience."

Not one in fact a measurement.

So is the problem with libinput latency or just the acceleration profile?
So those quotes not answered this. Synaptic allows setting custom input acceleration profiles per device and deal with quirky devices had a lot of preprogrammed acceleration profiles. Guess what libinput only got that this year means to set custom acceleration profile matching what the synaptic driver had. Yes you can fell like you have a lot of inputlag when all it is that the acceleration profile is wrong. Yes wrong acceleration profile you have cases of having to do longer movements that take more time to get the same screen movement.(feels a hell lot like input lag when there is no input lag)

Yes lack of pointer acceleration on flat profile and too dynamic on the adaptive profile with libinput is another problem why the custom profile has had to be added. Yes this bug can fool people into they have input lag when they don't.

Also notice Wayland/Xwayland comment is in general. This does not work when you wake up different Wayland compositors have different bugs.

Wine directly on Wayland removes the xinput stack that xwayland has to provide for X11 compatibility.

https://gitlab.gnome.org/GNOME/mutter/-/issues/334#note_346785

There is a elephant in the room. The parties who have gone and measured the input lag with hardware with wayland compositors have found something very shocking to people who make the argument you do mSparks. X11 bare metal even with evdev is in fact slower than gnome/xwayland from 4 years ago on working hardware.

Wayland input stack side is not slow as long as the compositor you are using has threaded for input processing. Rendering side has had a few problems causing everything to fell lot slower than it really is at getting the input information to the application..

Person preferring evdev over libinput on X11 bare metal can be nothing more than liking a different acceleration profile on the device.

Remember how people say I don't like Wayland because I cannot disable the compositor. Good question here why do you tolerate X11 bare metal server?

https://github.com/libsdl-org/SDL/tree/main/src/video/kmsdrm

Linux native games using SDL you can in fact use those without the overhead of X11 or Wayland because they can directly output and directly get output from evdev no X11 server or Wayland compositor in the way. Wait you are not use to this this does not work with Nvidia because your drivers are busted..

This is the problem with the argument about latency for a person with Nvidia. The lowest latency option does not work with Nvidia hardware on Linux because the Nvidia drivers are broken.

Yes I would love to see wine with direct KMS/evdev support.. Wayland application is simpler to port to a direct KMS/evdev application than X11 application. Yes proper method to switch to desktop to application direct output/input mode and back would be really nice as well.

X11 mind set problem is we must be able to disable the compositor to improve game performance then completely miss that X11 bare metal server not matter how you slice it is still a compositor. Graphics card drivers requiring X11 to function have been hindrance to getting most performance on Linux for a long time.

[mSparks]

That was not repeatable on AMD hardware in configurations that work.

I tested on AMD, intel, nvidia and in VMs on all of them. nvidia worked THE BEST of the three, but all three were far inferior on wayland than X11, with input latency that didn't meet the fairly tight requirements for the software we run on them.

So is the problem with libinput latency or just the acceleration profile?

The problem is, using wayland introduces a ton of latency and input lag, a problem that either doesn't even seem to be acknowledged, or blamed on actually capable developers, not least because none of the people promoting it actually use it. Chances of a problem that isn't believed to exist getting fixed would seem extremely unlikely dont you think?

This does not work when you wake up different Wayland compositors have different bugs.

Nah, that would imply wayland is fragmented, and you already convinced everyone that isn't the case.

Remember how people say I don't like Wayland because I cannot disable the compositor.

Wayland devs already caved on that one aiui, but only for full screen applications.

Good question here why do you tolerate X11 bare metal server?

Because there isn't a better alternative, Same reason you "tolerate" having a day job.

[oiaohm]

I tested on AMD, intel, nvidia and in VMs on all of them. nvidia worked THE BEST of the three, but all three were far inferior on wayland than X11, with input latency that didn't meet the fairly tight requirements for the software we run on them.

You never showed those test results in a formal bug report against the used Wayland compositor right???

The problem is, using wayland introduces a ton of latency and input lag, a problem that either doesn't even seem to be acknowledged, or blamed on actually capable developers, not least because none of the people promoting it actually use it. Chances of a problem that isn't believed to exist getting fixed would seem extremely unlikely dont you think?

Flawed argument still. If you don't have bug report where you have shown the correct data of course the problem is not going to get fixed.

Nah, that would imply wayland is fragmented, and you already convinced everyone that isn't the case.

This presumes X11 is not fragmented. Every different X11 compositor combination with X11 results in different latency times due to issues in implementations.

Wayland compositors simple show the same issues X11 compositors of old showed where each one has a different performance profile. Every Wayland compositor benchmarks in latency better than X11 + X11 compositor even allowing for xwayland overhead.

You keep on saying Wayland introduces latency. There is no evidence that Wayland protocol design is to blame. There is lots of evidence that different Wayland compositor implementations have issues. There is lots of evidence that different GPU drivers have major issues that using Wayland compositor triggers. Remember the issues Wayland compositors trigger in GPU drivers adversely effect SDL and other applications that can also go direct KMS/evdev. Remember how I said you need a direct KMS/evdev in your bench-marking lowest latency graphical Linux applications don't use X11 or Wayland and this predates Wayland existing.

Nvidia themselves admits their drivers are broken when using Wayland so of course when the drivers are broken you should expect garbage performance when using Wayland on Nvidia solution.

mSparks in my eyes you saying wayland has a problem is your excuse so you don't have to do a formal bug report to a Wayland compositor only to find out opps this is not a Wayland fault but this is a gnome/kde/... implementation fault or is just simple pure driver fault.

Does not change the case that embedded for cases of tight latency requirements go direct. SDL developer for games also wants to go direct and is behind inputfd in wayland protocol.

I showed the retroarch data before that showed for them on KDE Wayland that current there is no performance advantage using X11 over Wayland. Particularly when you could have the composited desktop for the same cost as bare metal X11 without compositor.

Really if you have a real issue with wayland why are you here trying to convince people not to try it instead of doing a correct bug report.

[mSparks]

You never showed those test results in a formal bug report against the used Wayland compositor right???

MY tests determine whether I will adopt something, they are generally not public, the next step is to look how wide the problem is, a cursory glance on the web shows it isn't isolated:
"In Wayland/xwayland is indeed hard to tell since it already introduces Inputlag. But in xorg is night and day"
"I am using synaptics. I’ve tried libinput on each of them and found it unusable."
"but as soon as we move towards Wayland-only (wine Wayland for example) I'm afraid that I become unable to use evdev for a better input lag and gaming experience."

Flawed argument still. If you don't have bug report where you have shown the correct data of course the problem is not going to get fixed.

You have that the wrong way round, bug reports come AFTER something is superior to what it theoretically replaces. I would file xorg bug reports, except I am not aware of any worth my time, let alone that of someone else.

This presumes X11 is not fragmented. Every different X11 compositor combination with X11 results in different latency times due to issues in implementations.

It's not.
xorg-server everywhere on linux. quartz on windows and mac.

If a compositor causes problems, just turn it off.

There is no evidence that Wayland protocol design is to blame.

There is, it uses cpu cycles instead of interrupts, and adds significant logic to IO in the name of "security" (something that has no business being part of a display server).

Nvidia themselves admits their drivers are broken when using Wayland

Two or three years ago. All nividias known bugs are well and truly fixed - more so than AMD, they do also list lots of show stopper bugs that are deficiencies in either wayland or the implmentation of the compositors. But they aren't issues they will devote any time to fixing.

Really if you have a real issue with wayland

The only issue I have with wayland is it offers nothing and "breaks everything", e.g.

https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

I like Fedora, this stupidity is going to turn it into mandrake linux or sunOS, and they were killed by issues far less serious than wayland is bringing into Fedora.