Re: 2.6.19-rc4-mm2

Re: 2.6.19-rc4-mm2

[Andrew Morton]

On Fri, 3 Nov 2006 16:42:33 -0500
Andrew James Wade <andrew.j.wade@gmail.com> wrote:

> On Thursday 02 November 2006 02:54, Andrew Morton wrote:
> > - Lots of fbdev updates.  We haven't heard from Tony in several months, so I
> >   went on a linux-fbdev-devel fishing expedition.
> 
> radeonfb-support-24bpp-32bpp-minus-alpha.patch broke my video: my
> screen ended up garbled. (vc1 was ok, strangely enough). Reverting
> fixed things. 
> 
> lspci -v:
> 
> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (prog-if 00 [VGA])
>         Subsystem: ATI Technologies Inc Radeon 7500
>         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: <available only to root>
> 

Great, thanks for working that out.  I'll drop the patch.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

RE: 2.6.19-rc4-mm2

[Richardson, Charlotte]

Hi, Andrew & Andrew -

Kimball said to work this through you; I modified this fix so that it
only applies to RV100-based Radeons, since evidently some of them (like
your RV200-based Radeon) really do NOT do 24bpp, as retro as that seems
to me. I'm certain this is actually overly-restrictive, but the only
Radeon chips I have here are ES1000s (RN50, device id 0x515E): I did
drivers
for three earlier Radeon chips at my previous job several years ago, all
of which did 24bpp just fine, but I do not recall what their device ids
were
anymore. What's the device id of your VC1? What I'd ideally like to do
is
to allow 24bpp for all the Radeons for which it works and disallow it
for
all the ones where it doesn't, rather than disallow it for ALL of them,
or
only allow it for the ES1000 (RN50) that we happen to have in our
hardware
here. Your thoughts?

/Charlotte

> -----Original Message-----
> From: Andrew Morton [mailto:akpm@osdl.org]
> Sent: Friday, November 03, 2006 4:52 PM
> To: andrew.j.wade@gmail.com
> Cc: linux-kernel@vger.kernel.org; Richardson, Charlotte; Kimball
Murray;
> linux-fbdev-devel@lists.sourceforge.net
> Subject: Re: 2.6.19-rc4-mm2
> 
> On Fri, 3 Nov 2006 16:42:33 -0500
> Andrew James Wade <andrew.j.wade@gmail.com> wrote:
> 
> > On Thursday 02 November 2006 02:54, Andrew Morton wrote:
> > > - Lots of fbdev updates.  We haven't heard from Tony in several
> months, so I
> > >   went on a linux-fbdev-devel fishing expedition.
> >
> > radeonfb-support-24bpp-32bpp-minus-alpha.patch broke my video: my
> > screen ended up garbled. (vc1 was ok, strangely enough). Reverting
> > fixed things.
> >
> > lspci -v:
> >
> > 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
> RV200 QW [Radeon 7500] (prog-if 00 [VGA])
> >         Subsystem: ATI Technologies Inc Radeon 7500
> >         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: <available only to root>
> >
> 
> Great, thanks for working that out.  I'll drop the patch.

Re: 2.6.19-rc4-mm2

[Andrew Wade]

On 11/6/06, Richardson, Charlotte <Charlotte.Richardson@stratus.com> wrote:
> 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

[Richardson, Charlotte]

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 <Charlotte.Richardson@stratus.com>
> wrote:
> > 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

[Andrew Wade]

On 11/6/06, Richardson, Charlotte <Charlotte.Richardson@stratus.com> 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

RE: 2.6.19-rc4-mm2

[Richardson, Charlotte]

Hi again, Andrew -

(Sorry, I don't know what timezone you're in, but I went home, cooked
supper, ate supper, did two loads of laundry, slept for about seven
hours, ate breakfast, did another load of laundry, and voted, and now
I'm back!)

I'll go investigate whether any virtual consoles do anything weird
in 24-bit TrueColor mode with our chip here. Of course, I don't remember
what the problem with the Radeon chips I worked on several years
ago (about 7 now!) looked like. I got a list of the device ids for those
Radeons from someone who is still at my old company, and your chip is
one of them, so it isn't surprising that there is a problem. I don't
recall
exactly what we had to do about it (and as I said I can't really ask).
If the chip we are using here works solidly in 24 bit mode, I won't
be able to test it, either. I hadn't messed much with using a graphical
console at all other than to make sure that the various modes we are
supposed to support (resolution, refresh rate, and bit depth) worked
- I didn't try switching virtual consoles, etc. The systems are early
protos and there are not many of them around yet, but I pretty much
have the use of one almost all of the time. So after I finish dealing
with
the morning's email, I'll go into the lab and beat on it a bit!
I'll email results later...

If I can't repro it with this chip, if you want to mess around with it
on yours, here's what I think we had to do... I believe the trick was
to use 16bpp mode as far as what mode you write to the chip, and then
double all the x coordinate values for things like offset, width, and
pitch. You would have to do that to the accelerated routines also.
(Btw we have to turn off the acceleration here anyhow because we
essentially are hot-plugging the boards.)

/Charlotte

> -----Original Message-----
> From: Andrew Wade [mailto:andrew.j.wade@gmail.com]
> Sent: Monday, November 06, 2006 11:31 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 <Charlotte.Richardson@stratus.com>
> 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

Re: 2.6.19-rc4-mm2

[Andrew Wade]

Hello Charlotte,

> (Sorry, I don't know what timezone you're in, but I went home, cooked
> supper, ate supper, did two loads of laundry, slept for about seven
> hours, ate breakfast, did another load of laundry, and voted, and now
> I'm back!)

I'm EST (GMT-5). But the hours I'm online are somewhat erratic.

...
> If I can't repro it with this chip, if you want to mess around with it
> on yours, here's what I think we had to do... I believe the trick was
> to use 16bpp mode as far as what mode you write to the chip, and then
> double all the x coordinate values for things like offset, width, and
> pitch. You would have to do that to the accelerated routines also.

I'd be happy to mess around with the driver, but I won't have much
time to do so until tomorrow. I'll let you know if I find anything,
and of course I'll be happy to test patches.

-ajw

Re: 2.6.19-rc4-mm2

[Geert Uytterhoeven]

On Tue, 7 Nov 2006, Richardson, Charlotte wrote:
> If I can't repro it with this chip, if you want to mess around with it
> on yours, here's what I think we had to do... I believe the trick was
> to use 16bpp mode as far as what mode you write to the chip, and then
> double all the x coordinate values for things like offset, width, and
> pitch. You would have to do that to the accelerated routines also.

> > From: Andrew Wade [mailto:andrew.j.wade@gmail.com]
> > On 11/6/06, Richardson, Charlotte <Charlotte.Richardson@stratus.com>
> > 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.

Since the ghosts are 1/3 of a screen apart and not 1/2...

If this is similar to the old Mach64, for 24-bit you have to use 8-bit mode and
multiply all horizontal values by _3_.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

RE: 2.6.19-rc4-mm2

[Richardson, Charlotte]

Hi, Andrew -

I messed around with trying to recreate the workaround for the 24bpp
Radeon stuff for chips that have the problem (like yours does) all
afternoon yesterday, but I never did get it to work. I can't spend any
more time on this right now (boss is after me!) but I will try to do
some more poking around later or next week. Do you think I should submit
a patch that at least enables 24bpp for the chip I have where it
definitely does work? I'm sure that is overly restrictive, but I don't
know which ones work and which are broken at this point. I tried going
to the ATI web site (we have an OEM agreement with them, so I can get
more data that way) but their documents are no better now that they are
part of AMD than they ever were, and I didn't find anything useful.
Grumble! Actually, as more people use linux and Xfree86, they may have
to do a bit better with the specs. One can hope!

If you get a chance before I do, you might look at what Xfree86 does -
they might have the workaround.

/Charlotte

PS - You have your reply-to email address set to
ajwade@alumni.uwaterloo.ca
which evidently is stale, 'cause replying to that bounces.

> -----Original Message-----
> From: Andrew Wade [mailto:andrew.j.wade@gmail.com]
> Sent: Tuesday, November 07, 2006 10:58 AM
> 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
> 
> Hello Charlotte,
> 
> > (Sorry, I don't know what timezone you're in, but I went home,
cooked
> > supper, ate supper, did two loads of laundry, slept for about seven
> > hours, ate breakfast, did another load of laundry, and voted, and
now
> > I'm back!)
> 
> I'm EST (GMT-5). But the hours I'm online are somewhat erratic.
> 
> ...
> > If I can't repro it with this chip, if you want to mess around with
it
> > on yours, here's what I think we had to do... I believe the trick
was
> > to use 16bpp mode as far as what mode you write to the chip, and
then
> > double all the x coordinate values for things like offset, width,
and
> > pitch. You would have to do that to the accelerated routines also.
> 
> I'd be happy to mess around with the driver, but I won't have much
> time to do so until tomorrow. I'll let you know if I find anything,
> and of course I'll be happy to test patches.
> 
> -ajw

Re: 2.6.19-rc4-mm2

[Andrew James Wade]

Hello Charlotte,

     I have just noticed that the garbled X-server mode is different
than what I thought it was. rinfo->depth is 24, but rinfo->bpp is 32.
(measured in radeon_write_mode). I haven't yet thought through the
implications of this. I've been unable to get the display correct, but
I've been trying to fix the wrong mode.
     The console mode is ->depth==8, ->bpp==8, and presumably the same
when it's garbled, but I've been unable to reproduce the problem since
instrumenting the kernel.

On Wednesday 08 November 2006 09:01, Richardson, Charlotte wrote:
> ... Do you think I should submit
> a patch that at least enables 24bpp for the chip I have where it
> definitely does work? I'm sure that is overly restrictive, but I don't
> know which ones work and which are broken at this point.

That sounds like a good idea to me, but I'm not very familiar with the
programming practices here.

...
> If you get a chance before I do, you might look at what Xfree86 does -
> they might have the workaround.

It looks like the X.org radeon driver doesn't support 24bpp.

-ajw