My proof is the fact that every time I sit down in front of a wayland compositor (I've tried enlightenment and kwin) I run into problems. A problem consistent across all compositors I've tried is responsiveness on the desktop. kwin_x11 is "snappier", more responsive than kwin_wayland. Simple tasks such as alt+tab or dragging a window across the screen are slower on wayland compositors. I'ver tried to adjust animation settings but it doesn't quite fix it.

Maybe this is specific to my system. There could be an issue with how it is packaged in Slackware, or maybe a hardware specific bottleneck. Either way, the burden of proof is on the wayland team. You need to demonstrate that it is better and if someone disputes your claim you can start troubleshooting.

FWIW, OSK support for kwin_x11 is much better than kwin_wayland. As I recall trying to get the OSK to even display on wayland was resulting in a situation that could trigger seizures. Literally, not figuratively.

Old enough to have seen this shit happen several times and new enough to still be annoyed by it.

I have to say that all packages for SLACKWARE are generally set up for SLACKWARE, and often differently than the same based packages for any other distribution. This is oth a wonderful advantage for SLACKWARE, and a vulnerability. Any performance issue a package has under SLACKWARE is unlikely to receive developer attention unless #1 they develop on slackware and can replicate it, or #2 it is also reported on other and more directly supported distributions.

I have seen many issues that arise ONLY on slackware, and I have seen them solved on slackware. I have the highest regard for the maintainer and the community. That said, there is a great chance that issues observed ONLY on slackware are not caused by Wayland (or X.Org) itself. There are also version issues, because slackware software often updates LONG after One bottom line to consider all other distributions, so it can have issues that have been solved everywhere else.

I would like very much to know what version of Wayland you are runnung, if you do not mind reporting that.
I also asked if you could point to any benchmarks to support your conclusions, and if you have any I still want to see that.

1 members found this post helpful.

Possibly good question. I depend on kernel patches, good firewall configs and sane internet activity and don't worry about much else, at least on a non-commercial machine. That said even given there's likely more hacker scammers in 2024 than there was around 2010, I did run a 24/7 globally accessible Minecraft gaming server back then an for roughly 2 years and never had one unscheduled reboot nor any successful compromise attempt, not for the lack of any since games tend to attract boys and young men who imagine they are Johnny Lee Miller as "Zero Cool" with Angelina Jolie impressed by their "skilz". 8^P

Well if GRUB2 receives security updates it would stand to reason that so should LILO/ELILO, but if LILO/ELILO aren't even in maintenance mode; then you are still taking a risk. Also the better hacker movie was Sneakers - Hackers was just too flashy and goofy even for 90s tech; Sneakers is the better movie.

Yeah Hackers is dumb, but it has Angelina Jolie in her prime which will always make it worth watching IMO . Blackhat with Chris Hemsworth was surprisingly very good at depicting hacking and computer tech, or at least as good as movie can be without being boring.

Last time I took a serious look at it was with Slackware 15.0, which is probably a tad out of date. It was an intel x86 tablet with a 3000x2000 display so I was trying to find a way to get qtvirtualkeyboard working with Global Scaling in Plasma5. It was a shitshow and a half. Most of the issues arise with getting the OSK to function at all, and then when you add scaling into the mix everything just falls apart. It mostly worked in X11, but plasma5 doesn't handle global scaling correctly when running under X. Which funny enough isn't actually an X issue, they just never bothered to finish the feature before starting work on the wayland version.

I'll be honest, I don't know how to benchmark the display latency issue on wayland and I don't actually know if it is wayland causing it. It's like the microstuttering issue when using SLI - There's a small seemingly benign performance problem that drives some, but not all users up a wall. Same thing happened with Beryl/Compiz desktops. Or like webapps, you know how people complain about Teams or Slack being slow and unresponsive.... yeah let me know when you figure out how to quantify that.

Maybe I'm making my point poorly, but in my line of work there is a huge difference between the software used to perform a task, and whether the task has been performed. Wayland isn't fixing anything. No user is seeing an improvement. If anything, the only changes a normal user is seeing right now is the chaotic discrepencies in functionality between the different environments and a huge amount of confusion as to where to report a bug. In some cases simply raising a complaint results in people tossing around things like "works on my system" or "must be a slackware problem". A lot of it doesn't really appear wayland specific.

Using Qt5 OSK support in Slackware 15.0 as an example...
under kwin_x11:

• Setting env variables to enable qtvirtualkeyboard works as expected
• global scaling kind of works - some desktop elements don't get the hint (e.g. panel stays small)
• qtvirtualkeyboard mostly works but fails to focus on the input box
• Enabling global scaling with qtvirtualkeyboard fails hard. OSK can't handle the artificial resolution and the Qt code for this makes no sense to me.

under kwin_wayland:

• setting environment variables for qtvirtualkeyboard doesn't make sense. IIRC required a weird hack and gives errors.
• global scaling works beautifully. No problems found
• qtvirtualkeyboard fails catastrophically. When focus is assigned the OSK starts rapidly opening/closing like a strobe light.
• unable to verify global scaling + OSK for the above reason
• messing with settings in kwin_wayland then switching over to kwin_x11 tends to break stuff. The config files don't translate back and forth so you need to test with fresh .kde and .config folders and never go back and forth. Something to look out for when user says "it don't work".

See the problem? I ran into other crap with apps not handling things and I gotta be honest, this isn't a wayland vs X problem. Stuff breaks one way under X, then a completely different way under Wayland. WTF??? If you fixed all this shit for kwin_wayland then honestly people might switch but seriously, there's a lot of crap just broken to the point where performance doesn't matter. I was able to rip a function out of Qt5 that made the OSK play nicely but the QT/KDE world has its own spaghetti code problem so I never really got into the bug reports for all those weird little issues. On an opinionated note, I don't understand why it's so hard to fix this stuff in the X11 version.

I've been meaning to give this another go with -current. Lately I've been working more on figuring out how to trim the slackware install down since this tablet has a tiny little eMMC chip so I don't want to be dumping the entire 9GB install onto it. Google discontinued the Pixel Slate so once it breaks... it breaks



EDIT: to answer your question... slackware-current ships the following wayland related packages. For a given bug or performance issue I honestly don't know which of these to blame. When X sucks we blame X, when wayland sucks we blame... something...

2 members found this post helpful.

The versions look good. Your list of related packages is far smaller, but I am testing several things right now.
My kernel is 6.7 but it should not be that.
I am running Intel HD Graphics 520 GPU driver ( I avoid NVIDIA like the plague ), that COULD be related.

When I read the tech benchmark comparisons I am not seeing what you report, but you clearly see an issue. This will bug me until I break something, so now I have to take off some time to install Slackware on something to test this. If I can figure out what can cause these symptoms, and more importantly how to avoid them, I will document here on LQ.

Sway and hyprland are tiling WMs and so are most of the other non-DE ones. Enlightenment is stacking but it's already more like a DE than a WM. I'm sure I can't be the only person here who prefers stacking windows. What's with wayland that it seems to have problems with this model?

1 members found this post helpful.

I'm on a few different AMD systems so all amdgpu/mesa for me. It's been while since I bothered to try wayland stuff so I'll fiddle with it again and see if it still feels slow. This isn't an area where I care too much so when it sucks, I just go back to X and don't bother root causing which specific component is bottlenecking. Could easily be mesa or something, not wayland but it all has to work together.

The qtvirtualkeyboard stuff was more of a slap in the face. If you set QT_IM_MODULE=qtvirtualkeyboard in your session then it should pop up whenever you give focus to a text input box in a QT application. I'll have to plug the tablet in and update because I haven't messed with it since around 2022 or so.

HA. Still does it (EDIT: on my lenovo AMD laptop). Granted this is on 15.0, will try on the newer versions in -current when I get home.

If you add "env QT_IM_MODULE=qtvirtualkeyboard" to the Exec line in /usr/share/wayland-sessions/plasmawayland.desktop it will launch the session with the OSK active. Once the desktop loads, just open the
System Settings app. On 15.0 the virtual keyboard turns into an unusable strobe light until the window is closed. Woooooo!

If this has been fixed, great! I'll check on -current later and see if it reproduces on the versions I gave above.


I don't know if this does anything different, but you can do it quick 'n dirty from a Konsole window. This way if the OSK gets stuck it doesn't force you to restart plasma.
Some apps act weird when this is set, and that's unrelated to wayland. BUT the fact that a given app acts differently on Wayland vs X is a real WTF moment. I gotta record a video of this before someone fixes it...

That model is not a model supported by either X.Org or Wayland, it is supported by the DE or Window Manager. The only reason there is not one like that for Wayland is because we have not written it yet. YET!

Something a bit like fluxbox running wayland native would be interesting to see, and might possibly be quite popular when Firefox and Libreoffice become wayland native. Plus a file manager and a terminal emulator.

Best of luck.

Who needs a file manager? A wayland xterm emulator does exist. It's called wterm.

Everyone who wants to copy 10 files from a 20 files folder, from his computer to an USB key, with white spaces and capital letters in less than 30 minutes :-)

1 members found this post helpful.