At some random moment mouse cursor turns into vertical dashed line (see attached screenshot) and stays in this state for some unpredicted time, then at some random moment (probably on some specific action or event) might turn back to normal state. I have opensuse 11.4 m5, ATI r600 with opensource driver, xorg 7.6 from opensuse repo and KDE4.6 beta2, but I have been hit by exactly same issue about 3-4 years ago on the same machine but with opensuse 10.3 with ancient fgrlx driver with KDE3. Also if I check "include mouse pointer" in ksnapshot, the screenshot would show correct mouse pointer. Also if I change mouse cursor theme in kde system settings nothing changes - dashed line just changes its color while changing themes. P.S. While I was writting this report, the cursor was corrupted, when clicked "attach file" and was navigating to the photo with kde open file dialog, the cursor changed itself to the normal state.
Created attachment 42101 [details] corrupted cursor
Please attach the full Xorg.0.log file.
Created attachment 42120 [details] Xorg.0.log
Same corruption here, it happens from time to time, usually it just dissapear alone or restarting X server. The last time it happened, restarting the X server did not fixed it and I could see the corrupted curdor on KDM login screen every time until I rebooted the system.
Created attachment 42641 [details] X server log
Created attachment 42644 [details] xorg log I saw this once last week. It started after leaving dpms and lasted a few minutes when it turned back normal as it moved over window buttons. I use this box every day, shutting down overnight, so this looks like hard to reproduce. My set up is atypical - old lfs, no compositing, no desktop, just old metacity + xterms. AMD phenom x4, but everything 32bit, card is PCIE rv790. Software is current git d-r-t kernel, ddx and mesa. Xserver is git but reset to circa 1.9 tag.
Not sure if this is related to this issue, but I had my mouse cursor turned to dashed line as usual right now and on some movement I think I saw a half of Tux's face for a split second on the mouse pointer location, then cursor turned back to normal state. Probably this could be something coming from framebuffer or something like that - Tux is often painted during system boot.
Any ideas if any other debug info would be useful to catch this? I am receiving it rather often right now - once a day or two and in some cases it even prevents from being able to do the work, cause in some apps (krdc) the cursor disappears at all. I can make any tests/provide any additional info required.
I'd also like hints on how to debug this. But it's worth pointing out that turning on SWcursor is a completely acceptable workaround. When a new version of the driver comes out, I turn off SWcursor long enough to verify the bug is still there and then turn it back on...
>SWcursor Thank's, did not know about this option. After enabling it I'v started to receive xorg crashes when try to change desktop resolution with kde display/monitor config module, but that's another story. Also for the main issue - I remember that recently during last 2 times, when I was hit by it, after some time being vertical line, during a second or 2 mouse pointer started to quickly turn back to normal state, then to vertical line and back few times and then the whole system rebooted - not sure if those events are related, did not find anything looking useful in /var/log/messages after that, do not remember if met such reboots before (probably because I have recently updated to 39 kernel), the system had uptime about 2 days in both cases.
I haven't seen this recently. Is this still a problem with recent X server / radeon driver / linux ?
I have xorg-x11-server 7.6 on opensuse 11.4 64 bit from x11:XOrg repository and receive this rather often. I am using opensource ati driver, but as I have said - did receive exactly same issue years ago on ancient fglrx, so this might be not the driver problem.
It's back with Linux 3.1 X server 1.11 branch ati git. Seemed to not occur with Linux 3.0, X server 1.10.4, ati git from sometime Aug/Sep. But it does not always happen so it may be just random. Suspend to disk seemed to fix this last time it happened way back. The thin dashed line is caused by repeating the first 3 scanlines of the cursor which typically repeats some tip. The cursor changes normally as it passes over areas with different cursor, it's just rendered wrong. This is on RV530LE so not limited to r600.
Can you bisect?
It's not something you could bisect. It just sometimes happens, perhaps once in a few days.
Created attachment 53409 [details] Good and Evil areas Ok, I think I have some more input on this issue. Don't ask me how, but once I have somehow noticed, that corrupted mouse cursor got cured when I moved the mouse though a particular area on the desktop. This area is located somewhere near horizontal middle of the screen for X axis and probably 1/4 of the screen from top for Y axis (see attached screenshot). This assumption of having some magic area which cures the cursor looked much like true, because many of previous times the mouse was cured after chaotic movements the mouse here and there around the screen. So the next time the mouse was corrupted I have just moved it to the suggested area, moved it slowly here and there inside it and this worked again, so now I have at least one confirmation of the initial idea. This also gave me an idea that as soon as there is magic Good area which cures the mouse once it goes there, there should be also another magic Evil area which corrupts the cursor when the mouse comes though it. So I have also tried to find this area by moving the mouse around the screen and even had a success to corrupt the mouse once (the approximate area is also shown on the screenshot) - and after this I was able to cure it back with the "Good area" method, so this is the 2nd confirmation for it. But I was not able to reproduce corrupted mouse with "Evil area" again at least for now (the 2nd time I have opened gimp with 1x1 brush and tried to fill the whole assumed area - you can see it is almost all black and mouse was not corrupted). So will need more tests here.
I don't have this "good area" but sometimes the cursor recovers when I turn a screen on and off and pretty much always when I suspend and resume the box. Also this time I had broken cursor on one screen and invisible on the other.
Created attachment 53760 [details] magic good area I just got another confirmation for the magic Good area for me - this time I was searching it rather accurately in the region I have noticed last time, so remembered the mouse location better (see attached screen). I will try to record video next time. Did not get any additional info for Evil area for now. >Also this time I had broken cursor on one screen and invisible on the other. for me it also always completely invisible inside rdp (Remote Desktop Client) window area during connection.
I have a video for the curing mouse: http://www.youtube.com/watch?v=qqDktoewOLk I looks like there is invisible not large rectangle area around the place I have pointed to - the corrupted mouse comes in, it disappears at all and then when it comes out it is normal again.
I have noted that this "magic area" does not work with kms enabled. I had to work with kms/3d disabled for some time due to another bug and this "magic area" always worked to bring mouse back to its right state. Now I'm working most time with with kms/3d enabled (x stopped hanging) and now I have received this corrupted cursor and it does not turn back to its normal state when move it though this area shown on the video.
What's the output of xrandr when the cursor turns bad?
Just caught it again - this the output: > xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 connected 640x480+0+0 (normal left inverted right x axis y axis) 160mm x 90mm 1280x720 60.0 + 50.0 1920x1080i 30.0 640x480 60.0* DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 Seems to be the same as when the cursor is not corrupted: > xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 connected 640x480+0+0 (normal left inverted right x axis y axis) 160mm x 90mm 1280x720 60.0 + 50.0 1920x1080i 30.0 640x480 60.0* DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1
I can also confirm this bug; sinche enabling swcorsor a couple weeks ago I've not experienced it again. This is running "compiled for 1.10.4, module version = 6.14.2" (version info from Xorg.log) on a 6450 "ATI Technologies Inc NI Caicos [AMD RADEON HD 6450]" (from lspci). If there's anything that I can contribute / test, let me know. -Nick
(In reply to comment #23) > If there's anything that I can contribute / test, let me know. See comment #21.
I also saw this problem when resuming after suspending the computer to RAM. I have a Radeon 6770. It was cured again when I did another suspend /resume cycle. It just appeared on one of the two screens (the smaller one), and the problem persisted when restarting X . [fa2k@blackhole ~]$ xrandr -q Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 8192 x 8192 HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ 1600x1200 60.0 1680x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 640x480 60.0 720x400 70.1 VGA-0 connected 1280x1024+1920+176 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1
Created attachment 61444 [details] [review] Try harder to prevent cursor from ending at multiple of 128 columns Does this kernel patch help for any of you?
RV710 here, kms *enabled*, running linux 3.2.12 (with Gentoo patches). I've seen this happen many times (both on this computer and on my laptop, which has a different card (690, IIRC). Today was the first time this happened with a dual-head setup, so far this has happened with single-head setups only (I don't do dual-head a lot). Both heads are set to the same screen pixel size, so I just tried moving the pointer along the edge of both screens, 1/4 from the top, and it got back to normal. But, so far, I found no way to trigger the "bad cursor"...
(In reply to comment #27) > RV710 here, kms *enabled*, running linux 3.2.12 (with Gentoo patches). I've > seen this happen many times (both on this computer and on my laptop, which has > a different card (690, IIRC). > > Today was the first time this happened with a dual-head setup, so far this has > happened with single-head setups only (I don't do dual-head a lot). > > Both heads are set to the same screen pixel size, so I just tried moving the > pointer along the edge of both screens, 1/4 from the top, and it got back to > normal. > > But, so far, I found no way to trigger the "bad cursor"... Does the patch from comment 26 help?
It happened to me for the second time now. Since it's so infrequent, it's difficult to troubleshoot. This time it did not happen right after an ACPI S3 resume, but doing another suspend/resume cycle fixed it (i.e., the cursor was then back to normal). I will build a kernel with the patch in comment 26 if I can find the time, sorry, it's a lot of instructions to go through.
I'm using a dual-head setup and experience this bug. Trying with the kernel patch now...
Just caught it again. As requested: # xrandr Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384 DisplayPort-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 50.0 60.0 1600x1200 60.0 1680x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1280x800 59.8 1280x720 50.0 60.0 1024x768 60.0 800x600 60.3 56.2 720x576 50.0 720x480 59.9 640x480 60.0 HDMI-0 connected (normal left inverted right x axis y axis) 1920x1080 60.0 + 1024x768 75.1 70.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 DVI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1600x1200 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 60.0
(In reply to comment #31) > Just caught it again. As requested: > > # xrandr > Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384 > DisplayPort-0 connected 1920x1200+1920+0 (normal left inverted right x axis y > axis) 518mm x 324mm > 1920x1200 60.0*+ > 1920x1080 50.0 60.0 > 1600x1200 60.0 > 1680x1050 60.0 > 1280x1024 60.0 > 1440x900 59.9 > 1280x960 60.0 > 1280x800 59.8 > 1280x720 50.0 60.0 > 1024x768 60.0 > 800x600 60.3 56.2 > 720x576 50.0 > 720x480 59.9 > 640x480 60.0 > HDMI-0 connected (normal left inverted right x axis y axis) > 1920x1080 60.0 + > 1024x768 75.1 70.1 60.0 > 800x600 75.0 60.3 > 640x480 75.0 60.0 > 720x400 70.1 > DVI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm > x 324mm > 1920x1200 60.0*+ > 1600x1200 60.0 > 1280x1024 60.0 > 1280x960 60.0 > 1024x768 60.0 > 800x600 60.3 56.2 > 640x480 60.0 Odd... Shortly after I posted this, the cursor returned to normal; I'm not sure what I did to cause this to happen. Interestingly, though, the output of xrandr is unchanged.
I've been using the patch from comment #26 for about a month now and could not reproduce it any more. And I do hibernate/suspend and switching between single/dual monitor combinations quite frequently.
A patch referencing this bug report has been merged in Linux v3.6-rc1: commit f60ec4c7df043df81e62891ac45383d012afe0da Author: Michel Dänzer <michel.daenzer@amd.com> Date: Tue Jul 17 19:02:09 2012 +0200 drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.
Please reopen if thus is still an issue when using a kernel with the fix.
I running xorg on FreeBSD 8.2-RELEASE with <a href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-drivers/xf86-video-ati/">6.14.3_1</a> and a patch to radeon_accel.c from xorg 7.5.2. Which version of xf86-video-ati is the patch in <a href="https://bugs.freedesktop.org/show_bug.cgi?id=33183#c26">comment #26</a> against? It does apply cleanly to any of <a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tag/?id=xf86-video-ati-6.14.3">6.14.3</a>, <a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tag/?id=xf86-video-ati-6.14.4">6.14.4</a>, <a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tag/?id=xf86-video-ati-6.14.5">6.14.5</a> or <a href="http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tag/?id=xf86-video-ati-6.14.6">6.14.6</a>. Better yet does xf86-video-ati-6.14.6 already include it the fix?
(In reply to comment #36) > I running xorg on FreeBSD 8.2-RELEASE with <a > href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-drivers/xf86-video-ati/">6.14.3_1</a> > and a patch to radeon_accel.c from xorg 7.5.2. > > Which version of xf86-video-ati is the patch in <a > href="https://bugs.freedesktop.org/show_bug.cgi?id=33183#c26">comment #26</a> > against? The patch is for the kernel and not for the UMS ddx. The UMS ddx already has similar code. If you are still having issues with UMS, you should open a new bug.
FWIW, this fix and a couple of previous cursor fixes should probably be backported to the UMS code. I haven't done so and no plans to.
Running a Debian stock build of kernel 3.9; here's the uname -r output: misely@aulin7:~$ uname -r 3.9-1-amd64 And the problem just happened again. This is after running for about 3-4 days. I point this out because of the earlier post that states that the fix was submitted into 3.6. Yet here I am in 3.9 still seeing the problem. -Mike
I forgot about this bug report, but I have experienced this even more frequently when using the proprietary ATI driver. I work around it by moving the mouse over a VM window, which restores the cursor. I am definitely using an old kernel and X though, as I use Scientific Linux now. $ uname -a [...] 2.6.32-358.11.1.el6.x86_64 #1 SMP x86_64 x86_64 GNU/Linux $ sudo yum info xorg-x11-drivers [...] Name : xorg-x11-drivers Arch : x86_64 Version : 7.3 Release : 13.4.el6
Other information... xrandr output: misely@aulin7:~$ xrandr Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 3840 x 1200 DVI-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 720x400 70.1 DVI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 720x400 70.1 I should point out here two possibly notable things about that xrandr output: (1) Just like Nick LeRoy, I have a pair of 1920x1200 LCDs hooked up, and (2) the problem did not actually start until after I had upgraded to these panels. Previously I was using a pair of 1600x1200 LCD panels - for nearly a year without issue. This mouse cursor corruption started *within hours* of changing to the larger panels (and also of course increasing the total virtual desktop size to match) - nothing else at that time had changed. This has been going on for several weeks now, as I've tried various things to solve this (upgrade to Debian wheezy, verify latest X11 driver, move up to 3.9 kernel after seeing the thread here...). Video hardware, from lspci: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV515GL [FireGL V3350] I can attach my xorg.conf if it will help, however the only things of any real consequence there are (1) selection of the "radeon" driver, and the "Virtual 3840 1200" setting to arrange for use of side-by-side 1920x1200 LCD panels. I guess now I'm off to see if I can disable the hw cursor... -Mike
Just happened to me again, in a single-head setup: Kernel is linux 3.8.13 (with Gentoo patches), and using the open drivers for AMD Radeon. $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 VGA-0 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1
Lot of people experienced this bug while playing heroes of newerth. OS does not matter as it happens even in Windows (check google for that). Its known issue since 2003 and it did NOT get fixed since that, so ... 10 years old bug. Maybe hardware design issue? I was playing on Catalyst and r600g, both seems to suffer from this bug. Vertical dashed line isnt only corruption that happens - mouse cursor gets bugged even horizontally and/or both, creating some type of matrix. To me it happens mostly when cursor is changed (in HoN it happens AFTER scrolling map using screen sides), but time after time it happens even on magic areas on desktop. Quite annoying bug, but im not sure if opensource devs can fix it when even AMD has this issue for ages.
confirming this old annoying bug still exists even with new mesa-dri. Always on Radeon with KDE. Doesn't happen enough or reliably for AMD to make it a priority. The problem is in the driver/kernal or hardware. What do bugs do? they bug you. But not often for me. Arch linux x86_64 kde/mesa Radeon R6570
Created attachment 107838 [details] Xorg.0.log I can confirm this bug is still present with: kernel-3.14.21 (x86_64) mesa-10.3.0 xorg-server-1.16.1 xf86-video-ati-7.4.0 Card is an ATI Radeon HD 4890 (RV770)
Affects me too. A workaround for this bug in KDE is to change the mouse settings randomly in System Settings -> Input Devices -> Mouse. If I recall correctly, also changing the cursor theme a few times in System Settings -> Workspace Appearance -> Cursor Theme may help. I think this used to be much more persistent than it is now, so I guess the patch did help, but obviously it is still happening.
(In reply to Jose P. from comment #46) > Affects me too. > A workaround for this bug in KDE is to change the mouse settings randomly in > System Settings -> Input Devices -> Mouse. If I recall correctly, also > changing the cursor theme a few times in System Settings -> Workspace > Appearance -> Cursor Theme may help. > I think this used to be much more persistent than it is now, so I guess the > patch did help, but obviously it is still happening. Neither workaround is successful for me. Linux 4.1.9 (x86_64) Mesa 10.3.7 (x86_32) Xorg server 1.16.4 (x86_32) xf86-video-ati 7.5.0 (x86_32)
I am experiencing the same issue with Ubuntu 14.04, radeon driver, and KDE. Reading through the comments I tried searching for a "good area" to reset the cursor, and sure enough, the cursor got reset at some point of me scanning the desktop for a good spot. Not sure whether this is really a "good spot", or a combination of other factors that reset the cursor. My set up is: kernel: 4.4.0-36-generic #55~14.04.1-Ubuntu SMP Fri Aug 12 11:49:30 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Radeon driver: xserver-xorg-video-radeon 1:7.3.0-1ubuntu3.1 Video card: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]
I ran into a similar situation just now. Here is my system environment: ``` openSUSE Tumbleweed: 20171129 KDE Plasma: 5.11.3 Qt: 5.9.2 KDE Frameworks: 5.40.0 KDE Applications: 17.08.3 Kernel: 4.14.2-1-default ``` When I was about to select texts in Konsole, suddenly the window did not respond to my mouse click. Then I found the mouse cursor was stalked as the "I" symbol even when I move the mouse to other area where the cursor should change back to normal "cursor" symbol. At this time, I could use Alt+Tab to switch windows but the mouse could only move around without response to click (by left or right click). I was about to save the state and do a reboot, then I touched the touchpad finding the touchpad working. After this, the mouse works again. This mouse is a Logitech M335 wireless mouse. I think this is the second time I run into this in a really lone time that I could not even recall when is the last time. I am using ThinkPad T470s with touchpad enabled at the time.
(In reply to H Zeng from comment #49) > When I was about to select texts in Konsole, suddenly the window did not > respond to my mouse click. Then I found the mouse cursor was stalked as the > "I" symbol even when I move the mouse to other area where the cursor should > change back to normal "cursor" symbol. At this time, I could use Alt+Tab to > switch windows but the mouse could only move around without response to > click (by left or right click). I was about to save the state and do a > reboot, then I touched the touchpad finding the touchpad working. After > this, the mouse works again. That sounds like a different issue (possibly related to X11 pointer grabs) than the one this report is about.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/15.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.