Bugzilla – Bug 23234
radeon , kms , xrandr - mouse "disspaears" on secondary screen
Last modified: 2010-02-22 09:05:36 UTC
using radeon xrandr and kms - everything except the kernel(2.6.31-rc5) from git
the first time i start X (after a reboot) the mouse is not visible when it is on the secondary screen - it is still usable though
it become visible if i use xrandr to swap the screens around ( or the gnome display control thinngy)
once it is working normally it stays like that after restarting x
also an interesting side note - when i started mythfrontend over ssh it started the size of both screens but offset to the right by one screen
Please attach your xorg log and dmesg output.
Created attachment 28492 [details]
Created attachment 28493 [details]
Might this be related to https://bugzilla.redhat.com/show_bug.cgi?id=466623 ?
my card died :( (well more accurately is almost dead and sitting on my desk) - may well be related although the other symptoms include random graphical glitches, and freezes (in both win and linux) (ie not consistent like the mouse thing)
I have the same problem: I have an ATI Radeon HD 2400 XT with a dual monitor setup and I've just migrated from xf86-video-radeonhd to xf86-video-ati from git.
When I move the mouse to the second screen, the mouse cursor disappears. Clicking seems to be working, though.
I am using KMS, too, but I think it is irrelevant. I think this problem was happenning before, too, and that was the reason I chose xf86-video-radeonhd.
If you want any output, please tell me to attach it.
*** Bug 23683 has been marked as a duplicate of this bug. ***
I have this same problem with drm-next, lidrm (master), mesa (master) xorg-x11-drv-ati (master) on a rv635.
I can make the cursor reappear by using the SWCursor option
If I switch back to DRI1 (non-KMS) then I get proper cursor without the need of SWCursor.
Here it seems to happen only when the second monitor is connected at startup; if it's plugged in later (and activated with xrandr) the cursors is displayed. A workaround is to deactivate the second monitor (xrandr --off) and then reactivate it.
Hardware is a M56, kernel from drm-next, xf86-video-ati and libdrm from git master.
I disabled SWCursor and rebooted, in this setup I found that the cursor on DVI-1 was not visible. But, I found that I could use this combination to bring the screen on DVI-1 up with a cursor
xrandr --output DVI-1 --off
xrandr --output DVI-1 --auto --right-of DVI-0
However, if I split out the steps..
[kdekorte@quad ~]$ xrandr --output DVI-1 --off
[kdekorte@quad ~]$ xrandr --output DVI-1 --auto
[kdekorte@quad ~]$ xrandr --output DVI-1 --right-of DVI-0
the screen would come up and I could drag items to it, but the cursor was not visible on the DVI-1 screen.
Since my displays are initially setup in xorg.conf, I believe that are using the second sequence to bring up the displays.
Created attachment 29540 [details]
xorg.conf to setup two screens DVI-0 on left, DVI-1 on right.
I confirm that SWcursor is working, as well as the xrandr commands Kevin DeKorte gave in #10: xrandr in two commands (off and auto with placement setting) is working just fine, but in three commands (off, auto and placement setting seperately) it is not.
Appears to be fixed using drm-next,drm and ddx (git) from Sep 18, 2009
I can confirm, that this problem is now fixed. Tried it with the latest kernel (sys-kernel/git-sources-2.6.32_rc6-r3) and a git-checkout from today (drm, xf86-vdieo-ati, mesa). I'm using xorg-server 1.6.5.
So far no problems. KMS is really awesome :D
Bug seems not fixed for my evergreen radeon (5780).
When using a second screen the mouse cursor is not displayed on the second screen (DVI-0).
The workaround with xrandr is not working here.
libdrm-git 20100219-1 (xorg)
Created attachment 33446 [details]
Created attachment 33447 [details]
xorg log output
(In reply to comment #15)
> Bug seems not fixed for my evergreen radeon (5780).
> When using a second screen the mouse cursor is not displayed on the second
> screen (DVI-0).
Please open a new bug for new issues like this. It just confuses things when you tack on new stuff to an old fixed bug. Your bug is probably a dup of bug 26551