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.
Are you still experiencing this bug using a current version of xorg?
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.
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.