Bug 22080

Summary:

Mouse cursor sometimes shows wrong pictogram

Product:

xorg

Reporter:

Vladimir B. Grebenschikov <vova>

Component:

Driver/radeonhd

Assignee:

Luc Verhaegen <lverhaegen>

Status:

RESOLVED WONTFIX

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

Version:

7.4 (2008.09)

Hardware:

x86 (IA32)

OS:

FreeBSD

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg.0.log	none
xorg.conf	none
usual cursor	none
Hand cursor	none
Xorg.0.log with recent radeonhd driver	none

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.