Bug 22080 - Mouse cursor sometimes shows wrong pictogram
Summary: Mouse cursor sometimes shows wrong pictogram
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) FreeBSD
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-03 23:49 UTC by Vladimir B. Grebenschikov
Modified: 2011-11-07 15:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (63.51 KB, text/plain)
2009-06-03 23:50 UTC, Vladimir B. Grebenschikov
no flags Details
xorg.conf (10.65 KB, text/plain)
2009-06-03 23:50 UTC, Vladimir B. Grebenschikov
no flags Details
usual cursor (220.67 KB, image/jpeg)
2009-06-04 00:15 UTC, Vladimir B. Grebenschikov
no flags Details
Hand cursor (168.27 KB, image/jpeg)
2009-06-04 00:16 UTC, Vladimir B. Grebenschikov
no flags Details
Xorg.0.log with recent radeonhd driver (63.20 KB, application/octet-stream)
2009-06-04 01:22 UTC, Vladimir B. Grebenschikov
no flags Details

Description Vladimir B. Grebenschikov 2009-06-03 23:49:34 UTC
See attached shot, usually it looks like image just put into buffer with wrong offset.

Sometimes image repeated down several times (out of usual cursor boundaries)

Often after some time of work with such cursor system crashes.

xf86-video-radeonhd-1.2.5_2

$ egrep -i curs\|mouse /var/log/Xorg.0.log
(**) |-->Input Device "Mouse0"
(II) LoadModule: "mouse"
(II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
(II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00000000 (size = 0x00004000)
(II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00004000 (size = 0x00004000)
(==) RADEONHD(0): Silken mouse enabled
(**) Mouse0: Device: "/dev/sysmouse"
(**) Mouse0: Protocol: "auto"
(**) Mouse0: always reports core events
(**) Option "Device" "/dev/sysmouse"
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7
(==) Mouse0: YAxisMapping: buttons 4 and 5
(**) Mouse0: EmulateWheel, EmulateWheelButton: 2, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(**) Mouse0: Buttons: 11
(**) Mouse0: Sensitivity: 1
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(**) Mouse0: (accel) keeping acceleration scheme 1
(**) Mouse0: (accel) filter chain progression: 2.00
(**) Mouse0: (accel) filter stage 0: 20.00 ms
(**) Mouse0: (accel) set acceleration profile 0
(II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0
(II) Mouse0: SetupAuto: protocol is SysMouse
(II) config/hal: Adding input device PS/2 Mouse
Comment 1 Vladimir B. Grebenschikov 2009-06-03 23:50:07 UTC
Created attachment 26422 [details]
Xorg.0.log
Comment 2 Vladimir B. Grebenschikov 2009-06-03 23:50:34 UTC
Created attachment 26423 [details]
xorg.conf
Comment 3 Vladimir B. Grebenschikov 2009-06-04 00:15:57 UTC
Created attachment 26426 [details]
usual cursor
Comment 4 Vladimir B. Grebenschikov 2009-06-04 00:16:16 UTC
Created attachment 26427 [details]
Hand cursor
Comment 5 Yang Zhao 2009-06-04 01:01:45 UTC
Doesn't quite look like the old known cursor corruption, but please try to reproduce it with git HEAD.

Cursor code has changed quite a bit since 1.2.5 release.
Comment 6 Vladimir B. Grebenschikov 2009-06-04 01:22:13 UTC
Tried with latest version
(II) RADEONHD: version 1.2.5, built from git branch (no branch), commit c6f607fd

everithing the same (after restart of X cursor still not changed)
Comment 7 Vladimir B. Grebenschikov 2009-06-04 01:22:47 UTC
Created attachment 26428 [details]
Xorg.0.log with recent radeonhd driver
Comment 8 Matthias Hopf 2009-06-04 07:41:01 UTC
Hm. This looks like an endian problem. However, we don't support big endian at all AFAIR, and i586 is little endian anyway. Strange.
Comment 9 Alex Deucher 2009-06-04 07:45:10 UTC
I used to see this on my rs690 occasionally when I would move the cursor between head before the last round of cursor fixes (i.e., both cursors have to be set to the same color mode).  I haven't seen it since.  It's probably related to using ARGB on one cursor and mono on the other which was the basis of the cursor issues.
Comment 10 Jeremy Huddleston Sequoia 2011-10-16 15:57:31 UTC
Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Comment 11 Jeremy Huddleston Sequoia 2011-11-07 15:31:56 UTC
Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati


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.