Xorg development effort slowing in favour of Wayland
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One good thing about Xorg is that you can configure it manually with xorg.conf.
Wayland's supposed to do all that automagically which is great when it works, but as soon as something unpredictable happens you're left with no configuration option.
Then you get depend on wayland developers' good will instead of writing your workaround in configuration file, which is kind of a downside I guess.
I use Plasma on Wayland daily. I also use it on X.Org, less often but more than weekly. I have made many minor configuration changes to Plasma/KDE settings on both, but have not had to manually adjust xorg.conf. I see a difference in the way settings work between them, but no difference in the settings themselves (the KDE team has done GREAT work on that). In both cases I can use the settings to achieve what I need to get what I want from Plasma. (When I need something leaner than Plasma I drop to fluxbox on x.org or tinyx and EVERYTHING gets out of my way!)
IF I could find, on my hardware, any cases where the difference between the two was important or even inconvenient, I would not be running both so often. What I observe is that, for me, they both just work really well.
I expect things will get better with time. (Yes, for both Wayland and X.org, and certainly for the WM/DE applications that ride on them.) They are good enough already now that I have NO complaints.
I use Plasma on Wayland daily. I also use it on X.Org, less often but more than weekly. I have made many minor configuration changes to Plasma/KDE settings on both, but have not had to manually adjust xorg.conf..
Plasma's all science fiction to me, I mostly use blackbox with xfce4 panel, and xfwm4 as fallback..
The xorg.conf file was and still is very helpful to me, and additionally the nvidia driver docs still rely heavily on that file.
Lack of configuration file, and reliance on automated detection of display settings is doomed on any system with custom workarounds already in place.
Just saying, xorg.conf allows to specify an EDID binary for one example, allows to bind a key combination to restart X server for another example, and there's hundreds of use cases.
What happens when wayland freezes, is there a key combination to restart it? I don't know much about it, but I've read nvidia's legacy hardware doesn't like it for some reason.
Plasma's all science fiction to me, I mostly use blackbox with xfce4 panel, and xfwm4 as fallback..
The xorg.conf file was and still is very helpful to me, and additionally the nvidia driver docs still rely heavily on that file.
Lack of configuration file, and reliance on automated detection of display settings is doomed on any system with custom workarounds already in place.
Just saying, xorg.conf allows to specify an EDID binary for one example, allows to bind a key combination to restart X server for another example, and there's hundreds of use cases.
What happens when wayland freezes, is there a key combination to restart it? I don't know much about it, but I've read nvidia's legacy hardware doesn't like it for some reason.
The last time X.Org froze on me was 2008. Wayland has NEVER frozen on me. It might be because I avoid Nvidia.
Does anyone have a way that will cause X.Org to freeze so I can run some tests?
I've had random lockups/crashes under Xorg for a long time. It happens randomly, from 2-3 days to 2-3 weeks or more. First I blamed Mesa, then I blamed amdgpu, now I think it might be Xorg because I've been using Wayland for 12 days of uptime and the same thing hasn't happened. I don't know how you'd test this because I think it's specific to Radeon. I've given up on trying to fix it. Here's what one of them looks like:
In this time, Wayland (mostly Labwc, some Sway) has been pretty stable except for 2-3 times (on different days) that I flopped to the text console (via ctrl-alt-1) and found it static, colored lines and unreadable. The display didn't crash and I had to go back to the GUI. After a few tries it righted itself. I've had no screen tearing and the graphics are clear & crisp but, like I said before, almost everything has to be done in a new way and many applications don't behave properly.
It turns out Labwc was responsible for my tablet not working, but version 0.7.1 released in the last few days fixes this; it works under Sway. Tiling compositors aren't my thing (your desktop looks like Midnight Commander) so I'm back with Labwc. After waybar, swaybg, bemenu, and wofi I have a decent desktop. Unfortunately, I can't include the screen shot because LQ image uploads haven't worked for me for weeks now (something about a missing "security token"). To bring the topic back to Wayland and Slackware, adding the Wayland stuff in will allow new and old to exist for years to come, side by side, and leave it to the admin to use what he wants. We still have people that use ifconfig, python2, ip4, and iptables.
We shake our fists at newness but in reality computer science is a fast moving target.
Last edited by jayjwa; 03-04-2024 at 11:49 AM.
Reason: labwc 0.7.1 adds tablet support
The last time X.Org froze on me was 2008. Wayland has NEVER frozen on me. It might be because I avoid Nvidia.
Does anyone have a way that will cause X.Org to freeze so I can run some tests?
It's unfortunate, but they are the largest GPU vendor around here.
And TBH, I went to store, asked for cheapest GPU on the shelf and that is what they gave me for 100 eurobucks.
I could've asked for AMD, but I don't really need gaming GPU (I mostly just use audio/video and virtualization so it'd be a waste of money).
Buying a used one is out of the question, since they are all abused by cryptominers and then sold as "barely used" lol.
About the freeze; yeah it can happen that X goes haywire while video decoding, and not necessarily when you expect it to happen. It's random.
Edit/more info:
To be clear, it's not a cheap hardware fault: because I have other systems, and decades experience with custom made systems.
On the same machine, win7 64bit with driver 391.35, never froze, decodes fine, not one glitch.
On the same machine, unsupported 32bit slackware-14.2, 390.157, xorg-server-1.18.3, mesa-11.2.2, ffmpeg-5.1.3. works fine, decodes all video fine.
On the same machine, slackware64-15.0, driver 470.223.02, xorg-server-1.20.14, mesa-21.3.5, ffmpeg-6.1.1, sometimes freezes when decoding and/or resizing, but when X restarted does not freeze again in the same scenario.
On the same machine, slackware64-15.0, driver 470.239.06, nothing yet, new kernel and new driver's only been out for a day or two so I can't tell/didn't test quite enough yet.
I often use nouveau on that machine, but it can't decode videos properly, especially h264 and x265, displays artifacts, etc. And those formats are more and more popular every day.
And BTW, vmware has not yet listed nouveau as supported driver, so I guess in that case it's either binary driver or a forcible override which is unsupported upstream.
So, with all that considered, my guess would be Xorg bug, and I can't simply 'move to wayland' because it lacks Xorg features. Wayland doesn't support stuff I've depended on for a long time.
i.e. specifying an EDID binary on xorg.conf is the only way to use full resolution on some VGA lcd monitors, and lacking an EDID binary causes X screen not support anything above the vesa standard 1024x768 on these monitors.
Do you see where this is going, how can I support wayland adoption when it basically will force me to downgrade from 1680x1050 into 1024x768?
I'd rather have a random freeze every now and then, if we're being perfectly honest here.
I've had random lockups/crashes under Xorg for a long time. It happens randomly, from 2-3 days to 2-3 weeks or more. First I blamed Mesa, then I blamed amdgpu, now I think it might be Xorg because I've been using Wayland for 12 days of uptime and the same thing hasn't happened.
...
In this time, Wayland (mostly Labwc, some Sway) has been pretty stable except for 2-3 times (on different days) that I flopped to the text console (via ctrl-alt-1) and found it static, colored lines and unreadable. The display didn't crash and I had to go back to the GUI. After a few tries it righted itself. I've had no screen tearing and the graphics are clear & crisp
@jayjwa, I also get unreadable display with "coloured lines" in one case when switching ttys, but found a workaround. Our situations aren't the same, but I'm noting my workaround here in case it might be adaptable to your situation.
And if anyone knows of an actual fix, please point out a reference or post here.
I multiboot with two installations of Slackware64 on the same disk.
- 15.0, runlevel 4 into KDE Plasma (X11) on tty 7 of 7. No problem switching between ttys.
- -current, runlevel 4 into KDE Plasma (Full Wayland) on tty 8 of 8. However, tty7 shows an unresponsive KDE login screen (cursor moves, clicking anywhere does nothing.) The unreadable display with coloured lines happens when I switch from the GUI to one of the first 6 ttys and then try to switch back to the GUI on tty8. This happens every time.
The workaround: after switching to one of ttys 1 to 6, switching back to tty7 first, then to tty8. This works immediately and reliably. Even if I forget and switch straight back to 8, I can clear it up by switching to 7 then back to 8.
This problem seems unrelated to the black screen and computer lockup problem I recently described in another thread. Both problems seem to be connected to older Radeon graphics, but whether mesa or a kernel upgrade have anything to do with them this time (as seems to have been in past black screen incidents), I can't tell.
About Wayland, aside from this oddity, it mostly works for me with my limited use of Slackware -current, but I have seen applications not working under Wayland on other Linuxes. I've also seen some of those resolved.
Reading elcore's comments about EDID settings - that's an essential feature for me.
I have an old Nvidia card on Slackware 15.0. with nvidia's 390.x driver. I'm running dual monitors - one off the HDMI port, and one off the VGA port. The VGA port runs through a KVM switch, as that monitor is the one I'll use for my laptop or old Winblows desktop.
Periodically, the VGA monitor will not properly identify through the KVM, and in the past I had to unplug the monitor from the KVM and connect it directly to the video card to get it working again at full resolution. Storing and using the EDID settings in xorg.conf fixed that. This problem appeared after upgrading to 15.0. (The same problem can happen on my Windows laptop, and bypassing the KVM temporarily has been the only solution.)
The McDonald's approach to software - "We do it all for you" - leaves a bad taste when the automation fails and there is no way to tell the software what it needs to do. Replacing working hardware due to malfunctioning software is also not a desirable solution.
... having a network-aware display has never come up. I again can just point to RDP or VNC if you need something similar, ...
I have still not tried any form of wayland compositor, and really should not post any more comments until I have (I just need to get a Round Tuit) , but ...
I am interested in learning in two main areas :
. usage patterns and implications for wayland
. how do slackers in particular set up their graphical-display infrastructure and operation (DE, Window Manager, etc) and (as I wrote in the first append here "Are any slackers concerned ..."
I have learned plenty about the first, wayland, but I am unclear about the second. In particular Jeebizz' comment above. Is this the consensus? May I outline how I operate and then ask if I am the only slacker doing anything like it? or are others doing some (or all) of the same?
I can understand that if a slacker has only a single linux system, and never runs any linux Virtual Machine under that host system, (or has several isolated instances of that single linux system), then the question of a network-aware display doesn't arise.
For myself, I have a number of linux systems all sitting near each other in one room, some self-contained with their own monitor, some with no monitor, and numerous VM's, some of which are linux. Why I operate like this can be summarised as chaotic, unplanned, evolution, plus a containable amount of hacking and just trial-and-error. But not relevant. What is relevant is that some are far more important to me than others, and all the important ones run slackware. And all are interconnected via a simple ethernet switch, plus (for some) an internet route.
One of the most important features of the linux ecosystem for me can be summarised as "every windowing/graphical application respects the DISPLAY environment variable". For me, it is a marvellous and useful fact that every single application that I have come across which runs under linux, and writes output to a windowing system, understands and respects DISPLAY. Of course, for most of them, this is because they use some standard toolkit e.g. gtk, Qt, or (in ancient times) Athena/libXaw, Motif,...). But, the fact is, I can depend on such a protocol to have every single application everywhere on my LAN display its output on my one high-res monitor sitting conveniently in front of me. (The only exception being needing to interoperate with a camera built-in to a different machine).
What about RDP / VNC? Are they the answer? I use them too, VNC extensively, and they are useful, but all fall down on mouse support, especially use of selections and Clipboard. For some scenarios, e.g. running emacs on a remote machine running xvncserver and vnc'ing to the xvncserver, I can get around some of the deficiencies with emacs key-bindings, but most apps don't provide such customizability. vnc is fine for such simple duties as running the console of a VirtualBox VM, but for any X-windows app in that VM, I export DISPLAY to my monitor.
So, for me, being able to export DISPLAY=MyXorgHost:0 everywhere is a cornerstone. How many other slackers also do? And (I wish I already knew from testing) what is the equivalent, if any, in the wayland way?
Now, for those who are concerned about network security, which is everyone : What is the concern with Xorg? I believe the main concern is that, if the Xorg server is started to listen on tcp, then it listens on 0.0.0.0:6000, open to the world, and xauth provides insufficient protection. And clearly the scale of potential damage is greater if Xorg runs as root, which I do. linux iptables firewalling provides some defence, which I also do, but relies on great care in constructing the iptables chains to prevent intruders while allowing all desired access. My answer to that was to hack Xorg to listen on a specific private local-LAN IP address, i.e. the ipaddress configured on MyXorgHost eth0. This one change reduces the gaping hole in security to a small chink in the woodwork, since an intruder has to devise some way of sending a packet addressed to my private IP address through my IP Service Provider's routers, which of course throw it away as unroutable. No-one has physical access to my machines except me. I do not run any internet browser on MyXorgHost. The only listening TCP sockets on this machine are sshd and Xorg. (I would like to shut off sshd too but too awkward)
I always build a complete Xorg from scratch for every deployment of Xorg on any system, including of necessity systems where no Xorg Server ever runs but which does run X-client apps, which I know is very unusual and which is, as a few others have confirmed, very difficult, at least for the first time. I am used to Xorg source code (at least, some of it), have contributed two (small) bug fixes to the maintainers over the years, and have made a number of other small changes of my own to make Xorg a bit more as I like it; and doing that is, I know, very atypical. I mention all this because , if other slackers do run their Xorg servers to listen on TCP, how do they address the security concern? Or is it the other way around -- the security concern is so great that they don't tell it to listen on TCP even though they would like to?
For completeness, I'll just mention that on MyXorgHost (the one which has the Xorg server controlling my one good monitor), I run sawfish WM and no full DE.
So that is quite a lot about me just so as to explain what I rely on and how I make it all work, and therefore why I am concerned about seeing all this go. And yes, I say go, because I fear it is a delusion to say "Xorg isn't going anywhere". Read h2_1's excellent append about bit-rot. If it is not actively maintained, then it will become unusable (at least for me). Although I'm sure I will figure something out when the crunch comes, I have no idea what or how much work it will take and how it will all fit together. And I am wondering if any of this is shared by others.
X.Org is quite mature. Wayland is still under development at a rapid pace. I see no reason for a distribution like Slackware, LFS, Gentoo, that is source based to be quick to jump onto Wayland while it is such a moving target. Distributions like RHEL, SUSE, Ubuntu, Debian, and the more cutting-edge ARCH based distributions have more motivation to adopt (at least as an option).
If I were installing Slackware (I am not) I would get the gui going with X.Org first and then PLAY with Wayland if I wanted to, thus having X.Org to fall back on.
In fact, that is how I am running Plasma on Manjaro: Wayland by default but I can log off and back on and select X.Org running Plasma or Fluxbox as a start option. That way I can run tests, but also react to issues to determine if Wayland or X.Org are part of a problem or part of a solution.
[ My first degree was Physics, and I am BIG on performing experiments. ;-) ]
I have still not tried any form of wayland compositor, and really should not post any more comments until I have (I just need to get a Round Tuit) , but ...
I am interested in learning in two main areas :
. usage patterns and implications for wayland
. how do slackers in particular set up their graphical-display infrastructure and operation (DE, Window Manager, etc) and (as I wrote in the first append here "Are any slackers concerned ..."
I have learned plenty about the first, wayland, but I am unclear about the second. In particular Jeebizz' comment above. Is this the consensus? May I outline how I operate and then ask if I am the only slacker doing anything like it? or are others doing some (or all) of the same?
I can understand that if a slacker has only a single linux system, and never runs any linux Virtual Machine under that host system, (or has several isolated instances of that single linux system), then the question of a network-aware display doesn't arise.
For myself, I have a number of linux systems all sitting near each other in one room, some self-contained with their own monitor, some with no monitor, and numerous VM's, some of which are linux. Why I operate like this can be summarised as chaotic, unplanned, evolution, plus a containable amount of hacking and just trial-and-error. But not relevant. What is relevant is that some are far more important to me than others, and all the important ones run slackware. And all are interconnected via a simple ethernet switch, plus (for some) an internet route.
One of the most important features of the linux ecosystem for me can be summarised as "every windowing/graphical application respects the DISPLAY environment variable". For me, it is a marvellous and useful fact that every single application that I have come across which runs under linux, and writes output to a windowing system, understands and respects DISPLAY. Of course, for most of them, this is because they use some standard toolkit e.g. gtk, Qt, or (in ancient times) Athena/libXaw, Motif,...). But, the fact is, I can depend on such a protocol to have every single application everywhere on my LAN display its output on my one high-res monitor sitting conveniently in front of me. (The only exception being needing to interoperate with a camera built-in to a different machine).
What about RDP / VNC? Are they the answer? I use them too, VNC extensively, and they are useful, but all fall down on mouse support, especially use of selections and Clipboard. For some scenarios, e.g. running emacs on a remote machine running xvncserver and vnc'ing to the xvncserver, I can get around some of the deficiencies with emacs key-bindings, but most apps don't provide such customizability. vnc is fine for such simple duties as running the console of a VirtualBox VM, but for any X-windows app in that VM, I export DISPLAY to my monitor.
So, for me, being able to export DISPLAY=MyXorgHost:0 everywhere is a cornerstone. How many other slackers also do? And (I wish I already knew from testing) what is the equivalent, if any, in the wayland way?
Now, for those who are concerned about network security, which is everyone : What is the concern with Xorg? I believe the main concern is that, if the Xorg server is started to listen on tcp, then it listens on 0.0.0.0:6000, open to the world, and xauth provides insufficient protection. And clearly the scale of potential damage is greater if Xorg runs as root, which I do. linux iptables firewalling provides some defence, which I also do, but relies on great care in constructing the iptables chains to prevent intruders while allowing all desired access. My answer to that was to hack Xorg to listen on a specific private local-LAN IP address, i.e. the ipaddress configured on MyXorgHost eth0. This one change reduces the gaping hole in security to a small chink in the woodwork, since an intruder has to devise some way of sending a packet addressed to my private IP address through my IP Service Provider's routers, which of course throw it away as unroutable. No-one has physical access to my machines except me. I do not run any internet browser on MyXorgHost. The only listening TCP sockets on this machine are sshd and Xorg. (I would like to shut off sshd too but too awkward)
I always build a complete Xorg from scratch for every deployment of Xorg on any system, including of necessity systems where no Xorg Server ever runs but which does run X-client apps, which I know is very unusual and which is, as a few others have confirmed, very difficult, at least for the first time. I am used to Xorg source code (at least, some of it), have contributed two (small) bug fixes to the maintainers over the years, and have made a number of other small changes of my own to make Xorg a bit more as I like it; and doing that is, I know, very atypical. I mention all this because , if other slackers do run their Xorg servers to listen on TCP, how do they address the security concern? Or is it the other way around -- the security concern is so great that they don't tell it to listen on TCP even though they would like to?
For completeness, I'll just mention that on MyXorgHost (the one which has the Xorg server controlling my one good monitor), I run sawfish WM and no full DE.
So that is quite a lot about me just so as to explain what I rely on and how I make it all work, and therefore why I am concerned about seeing all this go. And yes, I say go, because I fear it is a delusion to say "Xorg isn't going anywhere". Read h2_1's excellent append about bit-rot. If it is not actively maintained, then it will become unusable (at least for me). Although I'm sure I will figure something out when the crunch comes, I have no idea what or how much work it will take and how it will all fit together. And I am wondering if any of this is shared by others.
I just don't see any advantages so-called for xorg still. Again it was already pretty much stated even by the devs that the code is unwieldy. Also I am noticing tears when scrolling or playing videos, now to be fair maybe it is a Plasma5 thing, and I have experimented with the compositor, the NVIDIA compositor is on, and I played with the Plasma5 compositer, accuracy settings, bounced be openGL3.0 and 3.1 , and tweaked all other settings, but still notice vertical tears when scrolling through text and horizontal tears for videos on youtube. Maybe it is also a NVIDIA driver issue and I have always kept previous NVIDIA drivers just in case, and rolled back a few versions. Then again, I still notice some form of tearing or another when I was on MATE.
I am still going to reiterate that I just don't care what xorg offers in terms of legacy features. I still never needed to run a remote display from another machine even from my own network , best I ever did was ssh via text into another machine to run updates....thats it. Again I am almost 42 years old so I was born when X itself was first written, but I never started using Linux until 20 years ago almost, so again I never needed what x offered other than DRI 2d/3d local rendering; and thats still all I need. This is why I still maintain my stance, if you are running wayland - there is RDP or VNC, ok it is not the same as x / xorg , but who the hell really cares? Me? I don't care. I am just old enough to just want shit to work at this point, even though I always stayed with Slackware as my distro of choice. I know enough just to get a working Slackware desktop, but I am not really interesting in further tweaks though.
Quote:
Originally Posted by wpeckham
X.Org is quite mature. Wayland is still under development at a rapid pace. I see no reason for a distribution like Slackware, LFS, Gentoo, that is source based to be quick to jump onto Wayland while it is such a moving target. Distributions like RHEL, SUSE, Ubuntu, Debian, and the more cutting-edge ARCH based distributions have more motivation to adopt (at least as an option).
If I were installing Slackware (I am not) I would get the gui going with X.Org first and then PLAY with Wayland if I wanted to, thus having X.Org to fall back on.
In fact, that is how I am running Plasma on Manjaro: Wayland by default but I can log off and back on and select X.Org running Plasma or Fluxbox as a start option. That way I can run tests, but also react to issues to determine if Wayland or X.Org are part of a problem or part of a solution.
[ My first degree was Physics, and I am BIG on performing experiments. ;-) ]
Yea mature in terms of being around a long time, but again if it were great then the devs themselves would be working further on xorg improvements , or let alone reconstituting the code, maybe removing features that are completely irrelevant today, cleaning up the code at all. Again I know right now and I have no problem admitting for selfish reasons, because even with all the different NVIDIA drivers I have and a major DE like KDE5 right now, I am still experiencing tearing of some sort one way or another; this to me is unaccceptable in "current year" , considering how "mature" as stated that xorg is. Again I am at the point of my life that I want things to 'just work', ableit I am using Slackware , and it is slowly starting that xorg isn't always 'just working' -- again maybe I could also jump over to AMD rather than NVIDIA for my next system, who knows - granted also I am running a GT710 , not the most powerful card obviously, but again I don't do current day gaming, I just want a proper 2d/3d acceleration for browsing the web, youtube videos, or at best the most I ever stressed out this card is when I emulate a Playstation1 or maybe Playstation2 at some point. Not exactly the powerhouse these days huh? I mean if a Pi5 can now emulate a Dreamcast.... Just saying.
Tangent aside, I want wayland to succed - though again clearly right now I am just using X11 for my Plasma5 session , but I am also trying to prepare.
Jeebizz
Senior Member
I am still experiencing tearing of some sort one way or another; this to me is unaccceptable in "current year"
sadly I can’t give you a solution, but I can help you not look for the wrong way.
I haven’t had tearing for a few years (but I had tearing at the beginning of Slackware 14.2).
-I keep xorg-server without version change.
-I keep xfwm without version change.
-I updated kernel but without branch change.
-I updated xf86-video-intel (and I recompile x11.SlackBuild).
sadly I can’t give you a solution, but I can help you not look for the wrong way.
I haven’t had tearing for a few years (but I had tearing at the beginning of Slackware 14.2).
-I keep xorg-server without version change.
-I keep xfwm without version change.
-I updated kernel but without branch change.
-I updated xf86-video-intel (and I recompile x11.SlackBuild).
I don't upgrade xorg, I just use what stock version is included - only "updates" is security patches that is applied.
Well again, it could be NVIDIA - and as I stated I am considering switching over to AMD for my next system; especially for wayland since AMD is friendlier and more supported than NVIDIA's rudimentary support for wayland. I do recall ever since I had this system (now almost 10 years old and only swapped out a dead GPU - both NVIDIA) I always experienced some form of tearing. This was also with the proprietary driver which I still use up to this point. Again maybe it is the chipset ,it could be down to that I don't know - but again something so basic in this day and age.
Again (sorry tangent again), I just want to use what works - I am not a libre-head , I'll never use a libre-compliant distro like Stallman envisions, why? Because well I have hardware that I need to WORK, this is why I also still avoid nouveau - even though I use one-display, Nouveau is still worse than the proprietary driver for me. Ergo, if wayland does eventually solve my issue and it is mature enough (good enough), I'll gladly switch - I don't care - I am not attached to x for any reason as I stated earlier - I need local DRI/2d/3d , and if wayland does it better - fine I'll use that when the time comes - I don't care if I can't somehow run a remote display like xorg... don't care, not my problem not my usecase and I don't care how selfish this sounds.
I've often seen tearing with gl and xv backends of mplayer, but never with vdpau backend.
In other programs like glxgears for example, it's usually eliminated by forcing vsync in xfwm4 settings, and/or forcing triple buffering in xorg.conf.
Unrelated to screen tearing, I've seen someone on reddit complain that wayland on nvidia driver does not support hardware cursor.
So I guess the cursor will lag behind its actual position proportional to CPU load, like it does in video games without hardware cursor support.
I've often seen tearing with gl and xv backends of mplayer, but never with vdpau backend.
In other programs like glxgears for example, it's usually eliminated by forcing vsync in xfwm4 settings, and/or forcing triple buffering in xorg.conf.
Unrelated to screen tearing, I've seen someone on reddit complain that wayland on nvidia driver does not support hardware cursor.
So I guess the cursor will lag behind its actual position proportional to CPU load, like it does in video games without hardware cursor support.
Well I still see tearing when I scroll through text (vertical), it was slightly less noticeable in MATE than plasma5 for some reason, and as for vpdau its only a thing for vlc or mplayer , but when you are watching youtube in a browser thats different even though there is 'hardware acceleration', and yea NVIDIA and wayland is pretty much a no-go - which is why I stated I am considering AMD for my gpu for my next system. Point is this 'compositor' i am using for nvidia and kde I would have thought should eliminate this , or unless maybe it is because my gpu chipset I don't know - I am trying to be somewhat diplomatic and not totally blame x, but on the other hand I have tried many version of the 470 proprietary driver. All I know though is I have tweaked and tweaked, jumped from MATE to Plasma5; and it is still noticeable to an extent, I could still accept this 10-15 years ago, but no longer.
I can't remember ever experiencing screen tearing, so have no first-hand advice, but based on what I think I remember -
1. tearing indicates some kind of mismatch between 3 factors :
video controller
monitor
Xorg mode settings , Specifically all the DotClock and Htiming and Vtiming numbers
(explicitly specified in xorg.conf, derived or sensed by EDID)
2. have you looked for (WW) warning messages in the Xorg.0.log?
3. have you checked what mode settings Xorg is using, and how it arrived at those?
4. if all else fails, have you tried explicitly setting the video mode in your xorg.conf?
I know this sounds archaic and applicable to the days of Cathode-Ray Monitors, and that nowadays settings are all supposed to be set to the correct value automatically by EDID etc, but I have myself sometimes been surprised by what Xorg comes up with in certain configurations. Or maybe you specified a mode somewhere long ago and then forgot to remove it. Worth checking ...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
