Bug 2506

Summary: TV out corruption w/ Hardware Cursor
Product: xorg Reporter: Arthur Taylor <art>
Component: Driver/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high CC: amilo
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Camera screenshot sequence (350Kb) none

Description Arthur Taylor 2005-02-08 18:16:42 UTC 
GPU: Radeon 7500 Mobile 32mb (IBM Thinkpad T41 model-num:2378-DLU)
X Server: X.org CVS Feburary 2nd, 2005
Basic Description: If a hardware cursor is used when TV out is enabled, the
Display on the TV gets corurpted.

I have known of this problem since June of last year. I have not been able to
test it on another machines as I lack access to another maching with a radeon
running linux. The problem is reproducable every time on my own machine.

To reproduce, simply start X with a hardware cursor (option "SWCURSOR" disabled)
and enable TV by means of enabling "VGAAccess", "BIOSHotKeys" and running
'atitvout -f t' when X is running. The -f option on atitvout (force ATI-Rage)
mode is nessisary as the regular R126/Radeon mode '-r' fails. The display will
appear on the TV as normal, except the cursor will be a black rectangle that is
about 48-ish pixels square. The black square contains some series of pixels that
are transparent or random colours. Apart from that the display will be fine
until the cursor is moved a certain distance. Once the cursor is moved a regular
distance the image on the TV gets currupted. It appears to me as if the gamma
has been increased sevearly and then the brightness of each pixel modularly
divided (Think that is the correct term, you know how 20 modularly divided by 16
 is 4 and 34 modularly divided by 16 is 2 (20 - 16 = 4, 34 - 2(16) = 2) so that
realy bright areas of the screen are black. I beleive this is because of a
hardware gamma bug, as when switched back to the LDC (atitvout -f l) the image
on the LCD looks to have had the gamma on it turned up. The bug is not dependant
on 3D accelleration (NOACCEL has no effect) and xgamma doesn't do anything to
fix the problem. 2D, 3D and XV out are all effected. The display is recoverable
by restarting X, but the bug will still occur if TV-out and hardware cursor are
still used. The bug produces no output to the X log.

Not really a major bug, but still a bit anoying. Can be solved by using a
software cursor when TV-out is needed. My guess (only a guess, I've never seen
the code, and I probably wouldn't understand it) is that somehow the gamma is
increased when the hardware cursor is drawn on the tv-out, and the TV-out DAC
can't handle such large numbers, so the top bits get's 'clipped' (my guess is a
buffer overflow) and the remaining bits are used as the brightness (per pixel
here.) Thanks for any help.
Comment 1 Erik Andren 2006-05-10 06:31:14 UTC 
Are you still experiencing this bug using a current version of xorg?
Comment 2 Alan Swanson 2006-05-22 06:36:11 UTC 
Created attachment 5709 [details]
Camera screenshot sequence (350Kb)

I have the same problem on a laptop with Radeon Mobility 9000 (rv250) using the
ati-1-0-branch dated 2006-04-21 for Xorg 7.0. Attached is a sequence of
screenshots from a (low quality) camera phone just for visual representation.

1) Normal display with hardware cursor prior to switching.
2) Switched via BIOS hotkey to s-video on television. Cursor now replaced with
black rectangular block.
3) Moved mouse and the gamma effect occurs but the cursor now normal.
4) Swtiched via BIOS hotkey back to LCD on laptop but display remains the same.

5) Switched to console with Alt-Ctrl-F1. The screen is corrupted and jittery
where text is displayed. Switching back to X with Alt-Ctrl-F7 resolves issue on
X. However switching back to console from now on results in same corrupted and
jittery screen on the console only but X is fine when switched back. I'd guess
some register has been reset correctly in X but is being reset wrongly on any
future switch to the console.
6) Just to demonstrate that switching back to LCD from s-video without moving
mouse the same problem will still occur as in 3 if mouse then moved.

Scientific this is not, but perhaps of help.
Comment 3 Timo Jyrinki 2007-02-22 14:27:21 UTC 
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.

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.