VERY STRANGE persistent rendering (Screen Tearing?) mouse cursor issues!
antiX / MX LinuxThis forum is for the discussion of antiX and MX 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.
VERY STRANGE persistent rendering (Screen Tearing?) mouse cursor issues!
I'm not certain if this is an MX Linux specific or a Hardware specific issue. I've only encountered this (see uploaded image) on MX Linux machines though, and each time it happened to be an older Sony Vaio laptop with AMD graphics. This phenomenon has occurred on MX Linux 18, MX Linux 19.4, as well as the latest MX Linux Wildflower.
To resolve this issue with the Text block ??? around the cursor, I've tried disabling the compositor, using the default compositor, enabling GLX alternatively, and also switching to Compton for compositing. No matter what I do, the system works looks and performs properly in all of the settings that I have tried. LibreOffice, VLC, Gimp, Web Browser, everything looks and works fine. Yet that really weird "text block" for lack of better words remains and shadows the cursor non-stop.
Tried utilizing different cursors as well of course, but nothing seems to be able to get rid of this weird block shadow. Any thoughts, ideas, or suggestions? I have not tried installing a different distro since MX Linux with XFCE is really my preferred choice of OS.
Thoughts only: I have seen this before, but not in XFCE, which I rarely use. The following shadows I've seen were always smaller much than yours, maybe 20% the size of yours. It's always been on old hardware. I don't remember ever actively finding a cause or solution. I have seen the problem disappear after ordinary updates.
The thing that is puzzling me is the persistence of this issue through three different releases of MX Linux as well as the lack of any changes whatsoever when the screen tearing issue is being addressed. Yes, the hardware is as explained from older Sony Vaio laptops ... but ... I work on dozens of computers per year which all receive the MX Linux installations. Never seen this with Dell, HP, Packard Bell, Medion, Asus, or any other brands. This appears to be an exclusive older "Sony Vaio" issue.
It looks almost like some weird kind of miniature text block that keeps following the cursor.
The system runs 100% perfectly in every way, except for this weird shadow.
I also do a lot of Windows 10 and Windows 11 installations, probably 50 to 100 per year. And again, strictly with older Sony Vaios I've encountered odd issues trying to install newer Windows versions on older Sony machines that used to have Windows 8 on them. Not any other brand, just the older Sony Vaios. Hah, I even installed Windows 11 on a 12 year old Dell and it ran wonderfully.
Thanks for your thoughts on this issue though.
There's an MX Tools section within MX Linux, or more specifically the MX Tweak application which has an option to correct Radeon "tearing" by enabling and/or disabling the tearfree function. Tried both today, enabled as well as disabled, each time followed by a reboot, but neither choice made any difference whatsoever. There's also a testing function within the system quick info which permits testing of the graphical output. All of that checked out fine without any errors on the screen.
Then I used the latest POP OS .iso to check out how that would work with the system. Problem is still there, identical as the MX Linux, precisely the same shadow block as before. No difference.
I also noticed that the graphics are Radeon HD 7550M and as coincidence would have it, that's exactly the same Radeon graphics which I ran into issues with for installing Windows 10 and Windows 11 on some machines with related driver issues that could, under some circumstances, even render the Windows OS inoperable. Within the next day or two I'll try another .iso or two to see how that works out. I'm beginning to think that this issue has to be related specifically to the Radeon HD 7550M graphics.
Yesterday afternoon I turned off compositing on MX Linux altogether, yet still that block shadow persisted to be there after a reboot.
Next I installed Ubuntu / Budgie which has a standard installer as well as a safe graphics mode. Utilizing the standard installer once again had the cursor show up as before, with that friggen weird block shadow by the cursor. Ahhhh, but when I tried out the safe graphics mode that weird block shadow finally disappeared. So I guess the problem with that shadow is that it is tied specifically into the Radeon graphics on those particular hardware setups from older Sony Vaios.
The other thing that I noticed was that the mainboard is specific to Sony as well.
What I was not able to figure out is *WHY* the safe graphic setting worked, so I could try to duplicate that on the MX Linux setup. If there even is such a thing (safe graphics mode) it sure would be nice to have the option of enabling that for MX Linux since everything else seems to function without a hitch.
Gotta go and ask my buddy Google. Any thoughts on that?
I hope that everyone had a good holiday and a productive "ride" into the new year.
This will be my last question about this topic ....
Does anyone know how to enable SAFE GRAPHICS mode in MX Linux AFTER booting into the system?
I'm thinking that if Budgie can boot into safe mode followed by rendering properly without compositing, then perhaps this might be possible for MX as well, only after the normal boot process has completed as opposed to booting into the safe graphics mode from the get-go? I guess it would have to be a method of enabling safe graphics mode during boot after first having logged in already, then rebooting immediately into those new changes, in order to then have safe graphics enabled automatically during every subsequent reboot.
Any thoughts ???
Boot MX in its safe graphics mode, then show here input/output from cat /proc/cmdline. If it has /etc/X11/xorg.conf or files in /etc/X11/xorg.conf.d/, show here the content of those files.
At this point I've tried the identical OS image on a total of three different Sony laptops which are all close to the same age. The weird mouse cursor rendering issue only appears on the one with an i7 quad core / eight threads processor. I wonder if that can have something to do with the issue?
Booting into safe graphics mode during startup isn't exactly what I was looking for. Since I already know that safe graphics mode appears to work properly or at lease cause the mouse rendering issue to disappear while everything else continues to work, I was hoping to find a way to force the safe-graphics mode on the system after booting up. Kind of like restarting X with CTRL + ALT + BACKSPACE which restarts X ... but in safe graphics mode instead.
I wonder if there's a terminal command that would accomplish this very function?
(restart X with safe graphics mode enabled after restarting).
I'm not worried about screwing up the system. In its current state it's just something to play around with until I get this mouse rendering thing figured out. Any more thoughts or ideas on this? Thanks.
Safe graphics mode essentially involves not having KMS enabled. AFAIK, the only way to turn it off is during init, via the kernel cmdline *modeset* options - nomodeset, radeon.modeset=0 or amdgpu.modeset=0 for AMD/ATI graphics - or blacklisting the radeon and/or amdgpu modules.
What might do what you need would be to define use of a generic display driver via /etc/X11/xorg.con*, either FBDEV or VESA, then restart X. These two slovenly drivers that don't support compositing traditionally have support for a limited number of modes, most of which are 4:3, but sometimes include 1920x1080, depending on the GPU and display. Also, neither supports more than one display.
All that said, I just tried it, and got FBDEV to produce 1440x900:
Note two active output ports, but only one display in use according the inxi. Actually, both displays are active, but the smaller of the two merely clones the pixels that it can from the other output.
Thanks. Your response then prompts two more questions.
1. Once this has been accomplished will this adjustment (if it works) remain in place after a reboot or with a cold start?
2. Exactly how (step by step) would I go about achieving what you just described?
(if changes are not saved during reboots / after cold starts, then the adjustments are mute)
1. Once this has been accomplished will this adjustment (if it works) remain in place after a reboot or with a cold start?
As a general rule, whatever configuration is done by an admin in /etc/X11/ stays done until it gets removed by an admin. Package management could conceivably place a file there that might conflict, but it's quite rare as long as admin filenames are smartly selected.
Quote:
2. Exactly how (step by step) would I go about achieving what you just described?
All you need to know is in my previous response:
a kernel command line video= parameter with a desired mode on the bootloader stanza's linu line
a file in /etc/X11/xorg.conf.d/ specifying use of the fbdev display driver
It was that simple here for me using a month old openSUSE. I don't have enough experience with MX to have any idea if anything it normally does would thwart this, but it would be a surprise if it did.
Well, I sincerely appreciate your thoughts and efforts, but both 1. and 2. went right over my head. When someone is used to dealing with the command line for decades many things "appear to be quite easy" as opposed to another person who's had 99.9% point n click experience during the past 30+ years. I've been using Windows since version 3.11 for Workgroups and by the time that I switched to Linux full-time without a dual-boot I was running Ubuntu which never really required the use of a terminal. As a matter of fact, I've helped about 50 people to make the switch from Windows to Linux during the past 4 to 5 years and I can almost guarantee you that none of them ever use the terminal for anything aside from entering a required password now and then. Never had any problems with my customers either.
I switched from Mint with XFCE about 3 to 4 years ago to MX Linux with XFCE since MX Linux provides me with much more freedom to customize without having to resort to the terminal since there's an app available for pretty much anything and everything.
I feel comfortable running backup, update, upgrade, search, installation, and other minor terminal commands, but when you start talking about "inserting" lines somewhere or creating actual files, that's a whole different ballgame. At that point the old "Paranoia" tries to rise up and tell me that I'll probably end up totally hosing my system if I try these things without nitty gritty for noobs instructions.
Thanks though.
Number 1 isn't about adding any lines to anything. It's about an admin or root user adding a modest string to the existing GRUB_CMDLINE_LINUX_DEFAULT= line in /etc/default/grub with any text editor, then regenerating /boot/grub/grub.cfg. The latter is something that gets done automatically every time a new kernel is installed, or an update causes a need to have grub.cfg regenerated. To do it manually is simply sudo grub-mkconfig -o /boot/grub/grub.cfg or without the sudo if logged in as a root user, or following sudo - as normal user. It can also be done one shot (for one boot), for test purposes by striking the E key at the boot menu to edit the linu line in the currently selected boot stanza.
Number 2 isn't all that complicated either. sudo touch /etc/X11/xorg.conf.d/15-fbdev.conf will create an empty file, to which can be added
using any app that can edit a plain text file, and having administrative (root) power, such as sudo nano /etc/X11/xorg.conf.d/15-fbdev.conf.
Once the file has been created, booting using a suitable video= string appended to the bootloader's linu line should result in the described effect when Xorg starts.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.