Bug 23234 - radeon , kms , xrandr - mouse "disspaears" on secondary screen
radeon , kms , xrandr - mouse "disspaears" on secondary screen
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
XOrg git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
: 23683 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-10 05:31 UTC by aaron
Modified: 2010-02-22 09:05 UTC (History)
7 users (show)

See Also:


Attachments
dmesg (35.00 KB, text/plain)
2009-08-10 19:12 UTC, aaron
no flags Details
xorg log (78.07 KB, text/plain)
2009-08-10 19:15 UTC, aaron
no flags Details
xorg.conf to setup two screens DVI-0 on left, DVI-1 on right. (1.04 KB, text/plain)
2009-09-14 13:09 UTC, Kevin DeKorte
no flags Details
dmesg output (34.26 KB, text/plain)
2010-02-20 06:31 UTC, gwydion
no flags Details
xorg log output (90.53 KB, text/x-log)
2010-02-20 06:32 UTC, gwydion
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description aaron 2009-08-10 05:31:27 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
Comment 1 Alex Deucher 2009-08-10 07:07:25 UTC
Please attach your xorg log and dmesg output.
Comment 2 aaron 2009-08-10 19:12:22 UTC
Created attachment 28492 [details]
dmesg
Comment 3 aaron 2009-08-10 19:15:51 UTC
Created attachment 28493 [details]
xorg log
Comment 4 Adam Goode 2009-08-11 17:18:29 UTC
Might this be related to https://bugzilla.redhat.com/show_bug.cgi?id=466623 ?
Comment 5 aaron 2009-08-15 03:56:10 UTC
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)
Comment 6 Ioannis Koutras 2009-09-14 03:01:56 UTC
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.
Comment 7 Alex Deucher 2009-09-14 07:26:27 UTC
*** Bug 23683 has been marked as a duplicate of this bug. ***
Comment 8 Kevin DeKorte 2009-09-14 09:11:14 UTC
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. 
Comment 9 Luca Tettamanti 2009-09-14 12:02:12 UTC
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.
Comment 10 Kevin DeKorte 2009-09-14 13:09:04 UTC
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.
Comment 11 Kevin DeKorte 2009-09-14 13:09:43 UTC
Created attachment 29540 [details]
xorg.conf to setup two screens DVI-0 on left, DVI-1 on right.
Comment 12 Ioannis Koutras 2009-09-15 02:09:59 UTC
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.
Comment 13 Kevin DeKorte 2009-09-18 05:57:13 UTC
Appears to be fixed using drm-next,drm and ddx (git) from Sep 18, 2009
Comment 14 Michael Mair-Keimberger 2009-11-08 02:39:41 UTC
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
Comment 15 gwydion 2010-02-20 06:30:22 UTC
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.


I'm using:

ati-dri-git 20100219-1
dri2proto-git 20100219-1
glproto-git 20100219-1
libdrm-git 20100219-1 (xorg)
libgl-git 20100219-1
mesa-git 20100219-1
xf86-video-ati-git 20100219-1
drm-radeon-testing-git 20100219-1
Comment 16 gwydion 2010-02-20 06:31:06 UTC
Created attachment 33446 [details]
dmesg output
Comment 17 gwydion 2010-02-20 06:32:29 UTC
Created attachment 33447 [details]
xorg log output
Comment 18 Alex Deucher 2010-02-22 09:05:36 UTC
(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