[mach64] ATI Mobility M1 -- the mouse cursor garbles some underlying pixels

[ianst]

Binary package hint: xserver-xorg-video-ati

Using
 xserver-xorg-video-ati - 1:6.7.197+git20080217.d055b9e8-0ubuntu0tormod~gutsy

on Sony with ATI Mobility M1

I observe a line of garbled pixels under the mouse cursor, for example on the initial login screen, and then they stay there no matter what is redrawn, like that they are "burned in". Moving mouse cursor keep these pixels on the initial location, and doesn't produce new, until something happens, when the "burned in" pixels appear somewhere else, but again under the current place of the cursor.

The effect never happens in Vesa mode. Here's conf, I don't know what else I should try:

Section "Device"
 Identifier "Generic Video Card"
 Boardname "ATI Rage Mobility"
 Busid "PCI:1:0:0"
 Driver "ati"
 Screen 0
 Vendorname "ATI"
 Option "MergedFB" "off"
EndSection

Thanks in advance for any suggestions.

ProblemType: Bug
Architecture: i386
Date: Fri Feb 22 22:46:40 2008
DistroRelease: Ubuntu 7.10
Package: xserver-xorg-video-ati 1:6.7.197+git20080217.d055b9e8-0ubuntu0tormod~gutsy
PackageArchitecture: i386
SourcePackage: xserver-xorg-video-ati
Uname: Linux lino 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
UnreportableReason: This is not a genuine Ubuntu package

[ianst (janko-js)]

There is some logic in behaviour -- I've already mentioned that pixels appear at first at the initial display of screen and the mouse. Then, going to "Screen and Graphics Preferences / Graphics card" and performing Test will make the pixels dissapear. Probably the sequence of initializing the screen and the mouse is not the same as on initial activation? Then they will appear only at some later event that seems to duplicate some events in the same way as the start of the graphics mode.

[Gary Chan (garychan)]

Is this what your mouse pointer/cursor looks like?

[ianst (janko-js)]

On my machine it appears as the pointer is not changed, the pixels on the
screen close to the pointer get "wrong" (the pattern itself has similarities
to the picture, but the main pointer is ok) and then these pixels stay there
until something happens, they appear somewhere else. They appear always
present, no matter what is done on the screen. But they don't follow the
pointer in all movements, they stay somewhere for a while and then appear
somewhere else.

I guess that if the hardware has two independent
"sprites" (sorry for C64 terminology if now it has some other name, I'm that
old) for hardware drawn cursors then what I observe must be the second one
which gets initialized to something and then turned on on some events and
then reinitialized on some other events? Is there any docs or info that
there can be two (or more) hardware sprites? The obvious fix would be to
avoid touching the second, especially avoid setting the "show" flag for it.

(I have a lot of programming experience, although not on Linux and with
drivers, but I'm really willing to help as much as I can).

[Bryce Harrington (bryce)]

Please attach your /var/log/Xorg.0.log.

[ianst (janko-js)]

attached "/var/log/Xorg.0.log"

[ianst (janko-js)]

the 1st photo of the screen detail -- in the snapshot is the problem not visible. I'll attacht one more photo so that you can see that it doesn't follow the main cursor all the time and that it's not affected by anything else appearing on the screen

[ianst (janko-js)]

the second photo of the screen detail

[ianst (janko-js)]

now, from all the observations, I'm quite sure that it's drawn by the same mechanism that draws the main "hardware cursor", and that what I see must be a second "hardware cursor" which "show flag" is unintentionally activated by some initialization and reinitialization procedure.

[Bryce Harrington (bryce)]

I'm forwarding a bug from a Ubuntu user:

"Using -ati 6.8.0 on Sony with ATI Mobility M1

I observe a line of garbled pixels under the mouse cursor, for example on the initial login screen, and then they stay there no matter what is redrawn, like that they are "burned in". Moving mouse cursor keep these pixels on the initial location, and doesn't produce new, until something happens, when the "burned in" pixels appear somewhere else, but again under the current place of the cursor.

The effect never happens in Vesa mode. Here's conf:

Section "Device"
 Identifier "Generic Video Card"
 Boardname "ATI Rage Mobility"
 Busid "PCI:1:0:0"
 Driver "ati"
 Screen 0
 Vendorname "ATI"
 Option "MergedFB" "off"
EndSection

now, from all the observations, I'm quite sure that it's drawn by the same mechanism that draws the main "hardware cursor", and that what I see must be a second "hardware cursor" which "show flag" is unintentionally activated by some initialization and reinitialization procedure.

http://launchpadlibrarian.net/14062548/Xorg.0.log
http://launchpadlibrarian.net/14062622/SecondCursorDrop1.jpg
http://launchpadlibrarian.net/14062647/SecondCursorDrop2.jpg

[agd5f (agd5f)]

Switching component. M1 is mach64 based.

[ianst (janko-js)]

One more observation: I've tried to run GlTron game, and in the window of GlTron the "second mouse cursor" which is "some pattern" follows the main cursor. Once it comes out of that window, it get stuck to some point and doesn't move for a while.

[ianst (janko-js)]

The Freecell game shows even more interesting effects:

- The arrow cursor leaves the "line pattern" on one place
- When the cursor is the "hand" the "line pattern" always follows cursor.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. In the development cycle for Intrepid there have been some vast improvements in the open source ati video driver and we could use your help testing them. Could you please download the latest Alpha CD image of Intrepid and test this particular bug just using the Live CD? You can find the latest image at http://www.ubuntu.com/testing . Your testing can help make Ubuntu and the open source ati driver even better! Thanks in advance.

[ianst (janko-js)]

the problem is still present in Interpid Alpha 4

[Mattst88 (mattst88)]

Is this still a problem?

[bugbot (bugbot)]

This bug report was filed against an old version of Ubuntu.
Can you confirm whether this is still an issue in natty?

If you don't mind, it would be very helpful if you could update the bug
report in launchpad to 'Fix Released' if it is no longer an issue for
you, or if it is still occurring under natty, please tag the bug 'natty'
so it's easier for us to track.

[Ajax-a (ajax-a)]

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

[Timo Aaltonen (tjaalton)]

​​​​this driver has been removed from Ubuntu, closing the bugs