RE: 2.6.19-rc4-mm2

2 messages, 2 authors, 2006-11-07 · open the first message on its own page

RE: 2.6.19-rc4-mm2

From: Richardson, Charlotte <hidden>
Date: 2006-11-06 22:17:33

Hi, Andrew -

Yours is PCI device id 0x5157. Mine is 0x515E - which is also dual-head-
capable, but we don't have it wired that way (it's on the motherboard).
0x1002 is ATI's PCI vendor id. Lspci is just printing out the PCI config
header in a nicer format (so that you can read it).

I think I remember something relevant from working on these chips
before:
there was some kind of a hardware bug in some of them that caused you to
have to pretend that unpacked 24-bit pixels were twice as many 16-bit
pixels. I think you had to double basically everything that dealt with 
widths or offsets into a scan line. I don't remember the details
anymore,
and I can't really ask, since that company has a proprietary Unix. I'll
try
to remember what it was - and which ones it affected, since that is
probably
what's wrong with the 24bpp. Too bad the chip specs are so crummy...
How much is each line offset when you have the garbled stuff? I mean, is
it
a couple pixels, half the total width, something else? And is it always
the
same for each line (or can you tell)?

/Charlotte


-----Original Message-----
From: Andrew Wade [mailto:andrew.j.wade@gmail.com]
Sent: Monday, November 06, 2006 5:02 PM
To: Richardson, Charlotte
Cc: Andrew Morton; linux-kernel@vger.kernel.org; Kimball Murray;
linux-
fbdev-devel@lists.sourceforge.net
Subject: Re: 2.6.19-rc4-mm2

On 11/6/06, Richardson, Charlotte [off-list ref]
wrote:
quoted
What's the device id of your VC1?
I presume lscpi -n -v will tell you what you need to know. I don't
know
how to read the output myself:

0000:01:00.0 0300: 1002:5157
        Subsystem: 1002:013a
        Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ
16
        Memory at d8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at d800 [size=256]
        Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at d7fe0000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2

My card is a dual-head card, but I'm only using one head. On that
head, if
I switch to virtual console 1, everything is fine, but if I switch to
any
other vitual console, the display is "garbled": each row of pixels is
offset
from the row before, producing interlaced "ghost" images.

I hope this helps; feel free to ask further questions.

-ajw

Re: 2.6.19-rc4-mm2

From: Andrew Wade <hidden>
Date: 2006-11-07 04:31:12

On 11/6/06, Richardson, Charlotte [off-list ref] wrote:
...
How much is each line offset when you have the garbled stuff? I mean,
is it a couple pixels, half the total width, something else? And is
it always the same for each line (or can you tell)?
Each ghost is 1/3 of a screen horizontally from the other ghosts. I've
been looking carefully at test patterns to figure out what is going on.

If

(1,1) (2,1) (3,1) (4,1) (5,1) (6,1) (7,1) (8,1)
(1,2) (2,2) (3,2) (4,2) (5,2) (6,2) (7,2) (8,2)
(1,3) (2,3) (3,3) (4,3) (5,3) (6,3) (7,3) (8,3)
(1,4) (2,4) (3,4) (4,4) (5,4) (6,4) (7,4) (8,4)
(1,5) (2,5) (3,5) (4,5) (5,5) (6,5) (7,5) (8,5)
(1,6) (2,6) (3,6) (4,6) (5,6) (6,6) (7,6) (8,6)

is what should be displayed, I'm getting instead

(1,1) (2,1) (3,1) black (4,1) (5,1) (6,1) black
(7,1) (8,1) (1,2) black (2,2) (3,2) (4,2) black
(5,2) (6,2) (7,2) black (8,2) (1,3) (2,3) black
(3,3) (4,3) (5,3) black (6,3) (7,3) (8,3) black
(1,4) (2,4) (3,4) black (4,4) (5,4) (6,4) black
(7,4) (8,4) (1,5) black (2,5) (3,5) (4,5) black

i.e., a black pixel is inserted every thee pixels.

However, it's not just a garbled display, the acceleration (I think) is
also bogus. When I tried setting a solid colour using echo -e '\e[47m',
instead of the above display, I got

(1,1) (2,1) (3,1) black (4,1) black black black
black black (1,2) black (2,2) (3,2) (4,2) black
black black black black black (1,3) (2,3) black
(3,3) (4,3) black black black black black black
(1,4) (2,4) (3,4) black (4,4) black black black
black black (1,5) black (2,5) (3,5) (4,5) black

i.e., in addition to a black pixel being inserted every three pixels,
one of the halves of the "source" image is black. And in the X virtual
console, the cursor is ungarbled.

Two other thing of note is that virtual consoles 2-6 are garbled after
only some boots. (vc7, the X server console, is always garbled). And
output below the as-displayed bottom of a garbled virtual console
prevents me from switching to a different vc. (I get "radeonfb FIFO
Timeout !"/"radeonfb Idle Timeout !" on the serial line).

Hope this helps,

ajw
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help