My cursor has a issue where is gets stuck on a wrong setting. say it was loading for a minute and then i move to something else and it wont switch back to arrow...or ill scroll or resize a window and it will be stuck on that. also when i go full screen on apps its wont even show up alot. it seems to get stuck on last clicked action vs what its hovering. im trying to describe it as best i can please ask further qs and help me out. its very irritating. also i did search before hand and found nothing relevant. So if theres something i SHOULD look at point me in the right direction please.
1 Like
This is an interesting... and new... thing. I've never encountered this.
Have you checked your package updates?
sudo apt update && sudo apt full-upgrade
sudo reboot
Have you checked your graphics drivers (AMD, Nvidia, Intel)?
Have you tested this on X11 display protocol (Zorin Desktop on X) instead of logging in on Wayland?
FYI I'm running 17.1 pro full install and experience similar problem. It has only surfaced on PLEX app. Move the cursor off bottom control bar, into video viewing area, and
I may get to select few menu items, but then my cursor disappears. There is some shadow effects that show that my arrow is still active, but not able to find specific control buttons. No problem when getting back to desktop, and a different app. But if I don't have a couple of apps running, I cant leave PLEX. I can only pull the plug. If i have other apps running, I can "Alt-TAB?" and gain control off other apps. But when returning to PLEX app. loose my cursor. Some keyboard keys may function but again, not reliable.
It will be interesting to see how you work with the OP, and see if I can follow that to a solution.
Pardon my windows speak, as this is only about 6 months of Zorin, and don't know all the commands of Zorin.
Is Plex an electron built application?
I would suggest switching to the X11 standard Display Protocol to see if that helps to resolve your issue.
Wayland has trouble with Electron built apps.
Log out - then click the gear icon (click "sign in as another user" if you cannot see the gear icon appearing, then click the gear icon, then return to logging in as yourself) and choose Zorin Desktop on X
Under Wayland, apps kind of draw it themselves, which allows them to have custom cursors in e.g games, but by default it should just tell the OS/Compositor to render the default cursor if it doesn't wanna overwrite it. Electron has supported this for years and it shouldn't happen in any recent-ish Electron application.
Either way, one solution I've found is to just globally force a specific cursor theme 
Generally you can achieve that by adding this to $HOME/.profile and rebooting:
# check /usr/share/icons, ~/.local/share/icons and ~/.icons
# for any cursor themes you may already have. "Adwaita" is the default
# under Zorin if I remember right.
XCURSOR_THEME="your-theme-name-here"
# 24 or whatever your preferred size is.
# Try to match the size with your system's settings to not have it
# resize randomly between apps.
XCURSOR_SIZE=24
@LarryGB if you installed Plex from Flatpak/Flathub (check the Software Store to check, just in case), you can also use this neat tool called Flatseal to add these settings to ONLY your Plex application:
Just select Plex, scroll down and add them like this
1 Like
Electron has, indeed, supported it for years, but this does not mean that Wayland and Electron built applications communicate properly.
It is true that with a lot of tweaking (e.g. launching your Electron Apps using parameters --enable-features=UseOzonePlatform --ozone-platform=wayland and disabling sandboxing for GPU actions --disable-gpu-sandbox) the end user may be able to launch all their Electron built apps on Wayland, though some features will be missing.
Importantly, most Electron built apps use Xwayland in order to bridge the gap.
The End User is all that matters and the end user should not need to jump through hoops to get their applications working while the developers say, "See, It mostly works after you jump through all those hoops. Everything's fine..."
That the end user is deeply affected by Wayland faults with Nvidia or with Electron cannot be ignored by anyone who wishes to show support for Wayland or for Electron. The multitude of issues are real and should be properly addressed and fixed, not swept under the rug out of fear that public support for Wayland may wane if too many issues are known.
- Wayland struggles with high refresh rates
- Electron built applications often show cursor lag on Wayland and on Wayland with Nvidia, can show cursor lag or cursor vanishing.
- With hardware acceleration, keyboard input lag becomes troublesome on Wayland with Electron built apps.
- Wayland struggles with Enbedded frameworks, not just Electron. Chromium Embedded Frameworks have similar difficulties on Wayland.
- Wayland struggles with Fractional Scaling and dual-monitor setups and when a user launches an Electron built application, features may vanish or cause a variety of Lag-related issues
This is an issue that 17.1 gave me, too, the cursor is invisible on games unless they provide a custom one. The only exception is Interstellar Armada Galactic Ace that has one but isn't shown anyway. See this 
reddit.com/r/openSUSE/comments/n82w5g/invisible_mouse_cursor_in_fullscreen_games_under.
With recent versions of Electron that too shouldn't be a problem. Essentially everything from Pipewire Audio/Screen capture, Wayland-Native rendering and Portals are supported. You will only reasonably run into issues when you try using in-development features[1] or older versions of Electron[2]
Also, you no longer have to disable the GPU Sandbox to get it running under Wayland, and since last year you no longer have to manually enable Ozone and Wayland rendering.
Indeed, that is why for Flatpaks of apps with old electron versions these overrides should be setup by default, but for some reason unknown to me, they aren't.
It is explicitly designed to handle those including VRR...???
That is a lack of Nvidia Proprietary Drivers supporting the HW-Accelerated Cursor Layer, and it doesn't happen on either recent versions of GNOME or KDE Plasma as they have overrides in place to disable this on Nvidia Proprietary Drivers.
That just sounds like old Electron with extra steps...? Either that, or I'm missing some crucial context as to what "Chromium Embedded Frameworks" are 
Wayland supports fractional scaling better than X11 ever could by design. Unless X12 happens, the X Windowing System won't see proper fractional scaling. This was even proven today by another user in the Zorin Forums having issues with scaling on X.
That is again a result of old Electron. Developers should update to support the latest features.
Yes I know this results in worse UX, but no it isn't a Wayland fault.
Interesting, I tried to replicate this running KDE Plasma and...I just couldn't no matter how hard I tried
Seems like a GNOME-Specific issue? I wonder why this wasn't fixed yet either???
Eh, I guess that is GNOME being GNOME again 
1 Like
I definetly agree that Fractional Scaling is troublesome on X11 as much as on Wayland.
I do differentiate when the claims are made that Wayland improved that situation - and then didn't.
The reports I see are from the latest applications. I cannot say that only old Electron built apps have these flaws when the reports that roll in are from the latest released versions.
Importantly, we cannot say that it is not a Wayland issue by saying that the app developers must write their apps to be Wayland compatible.
They are under no such obligation. They have developed their apps to be display protocol compliant and another developer forcing the use of a new display protocol does not place the onus on the app developers to get onboard.
We cannot say anything is "proven" as one users issue can vary widely from other users experiences.
In that case, it did work and was a helpful suggestion.
In troubleshooting, we must follow known suggestions to try and follow known bugs and issues to try to resolve an issue. I stand by my suggestion above and if it does not work, we can try something else.
But I am not going to dismiss, neglect or ignore a potential suggestion based on "I do not believe Wayland should be questioned."
1 Like
No, they indeed aren't obliged to anything, but XWayland is a stop-gap and shouldn't be seen as a long-term solution for getting your old application running on a modern Wayland system.
Remember: Wayland is supposed to replace X, but not substitute every single function the X11 protocol has.
Yes, eventually the goal is to have desktops that can run on Wayland exclusively, without the need of XWayland to run older X applications. But the goal was never to have feature parity with X.
The developer has the choice to either keep using X or not, but in the same way the people contributing to today's Linux Desktop have the choice of continuing to support X, or not.
As someone which provides support, we should suggest going back to Xorg, but as someone that wants to see the Linux Desktop progress, we should not.
We are moving into a Wayland-First Desktop in the future for very, very good reasons, and we cannot keep X around forever; By continuously saying that "XYZ is caused by Wayland" when infact Wayland has solutions for this that a developer has not adopted, we create a negative image of Wayland itself lacking modern features when that is infact not the case. [1]
For the future of the Linux Desktop, it is important to differentiate between "Wayland cannot do this" and "the developer chose not to support Wayland natively"; We should not blame developers for not supporting Wayland, however.
This also re-enforces a certain stigma around "Wayland breaking everything" that we've probably read a million times. ↩︎
We should suggest the thing which works and solves the problem.
If the Desktop Mouse Cursor is bugged out on Wayland, I am sorry but we cannot say that the Mouse Developer failed to support Wayland.
We can have a lot of discussions about the pros and cons of Wayland as well as the merits of what we can label as progress; but for the purpose of this thread; our only goal is to helpfully guide the End User to finding a solution that allows the features and functionality that they expect and a workable solution.
This happens only with Zorin Desktop on Wayland to me, with Xorg doesn't happen, and not even in other software, only games 
. This thing is on Wayland since 2021 
.
1 Like
so still having this issue can someone please help? ive tried full updates x11 and wayland... so irritating
Tried this reddit.com/r/openSUSE/comments/n82w5g/invisible_mouse_cursor_in_fullscreen_games_under? There's an extension to install that should prevent at least the issue with full screen use.
thelinuxexperiment in a recent video explained that X-Wayland was created to assist games (Windows?) in running.
well we will see if that fixes the diappearing act... but still need help on the cursor getting stuck to the wrong icon or hand...thing lol
1 Like
still looking for a solution to my cursor issue
still havent got the cursor problem resolved