Mouse glitch multihead setup on OpenSuse 13.2 w/ KDE Plasma4
Page 1 of 1 (11 posts)
Tags:
None
Registered Member 
|
Been having intermittent issues w/ my mouse on my multihead setup. The issue is now constant:
 This is a picture of a screen capture of my mouse, left side is picture of the output from ksnapshot, and that glitched out line on the right is what appears on my screen - it appears to be a mouse cursor being recursively printed over another mouse cursor. I'm running OpenSuse 13.2 using KDE Plasma 4.11. I've tried changing the mouse themes, and those changes manifest on my other monitor, however the affect seen in this picture never change regardless the reboots or theme/icon changes. I recently used lxrandr to fix my multihead setup (the first monitor was being mirrored to the second.) Besides the glitchy graphic, the mouse functionality works w/o issue. Kind of stuck with where to further investigate. I'm not really sure if it's a KDE or Xorg issue, however I don't know where to begin looking. Any help would be much appreciated. |
|
Registered Member
|
So I did some more research, and it seems like adding Option "SWCursor" "true" to /etc/X11/xorg.conf might work. From what I've read, the xorg.conf file is no longer used, as xorg auto detects settings.
Forum thread detailing the information above: http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/22129-dual-screen-ati-10-10-and-10-11-garbled-mouse-cursor-on-secondary-screen There seems to be a work-around, however I've never tried it and fear it might further break my setup: http://askubuntu.com/questions/4662/where-is-the-x-org-config-file-how-do-i-configure-x-there Does anybody have any input on this method? Or advice on how I can program xorg to start up w/ the SWCursor option enabled? |
|
/etc/X11/xorg.conf.d/20-mydevice.conf
This would be a driver bug, you should however not have a "multihead" (https://wiki.archlinux.org/index.php/Mu ... te_screens) setup w/o present Xorg config files. Also using the software cursor is not exactly a performance improvement. => Please paste your /var/log/Xorg.0.log somewhere. |
|
Registered Member
|
Ahh, I understand now. I think I was confused with plasma using separate activities for each screen. Thank you for clarifying.
So this is going to augment any automatic detection/configuration done by Xorg? |
|
> So this is going to augment any automatic detection/configuration done by Xorg?
Yes, but you need to match the used device driver (it can be found eg. in Xorg.0.log) Since the cursor is usually done by the driver, you might simply be facing a driver bug that can be resolved differently, though ("wrong" driver, "ambitious" acceleration, ...) |
|
Registered Member
|
Here is the entire log Xorg log: http://pastebin.com/4brYgaa5
From it, I gather evdev is the driver I need to use as such: file: 20-evdev.conf
Is there anything I am missing? What is the downside to software drawing my cursor? I take it the added performance features from my mouse, whatever they are, are ignored? cat /var/log/Xorg.0.log | grep Razer
|
|
nope, "fglrx" (what a surprise)
This is also indicated by > [ 7.977] (==) fglrx(0): Silken mouse enabled > [ 7.978] (==) fglrx(0): Using HW cursor of display infrastructure! |
|
Registered Member
|
I still experience that problem, and it seems to have worsen as the system up-time increments. Problem noticeably occurs when I move the mouse between both monitors, it was glitching every 3-4 movements between my screens. Now the mouse glitch stays constant on one of the screens.
This is the configuration I used:
After reading a bit about fglrx drivers, I understand your reaction; is there anything else I can do about it?
Last edited by bluemoo on Mon Sep 14, 2015 5:53 pm, edited 1 time in total.
|
|
Registered Member
|
Seems like I am SOL with this bug until AMD fixes their code:
https://community.amd.com/thread/169542
Last edited by bluemoo on Mon Sep 14, 2015 5:52 pm, edited 2 times in total.
|
|
Registered Member
|
Disregard this post, made it in error. Can't find a way to delete.
|
|
xorg.conf snippet looks good (though you're not editing the razer device
 - did you check Xorg.0.log on whether the software cursor is used (no silken mouse)You can try the radeon driver instead (if there's no collision, uninstall fglrx while installing radeon and be prepared to end up at a textshell, conflictive installations are pretty common with fglrx and I don't know how good SuSE handles that) |
Page 1 of 1 (11 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], blue_bullet, Google [Bot], rockscient, Yahoo [Bot]
