Linux Frame Buffer Device Development

> Ok, this may be the problem. The first one is initialized by the pm2fb,
> while the second is not. This mean either some initialization problems,
> or the fact that X doesn't initialize some values set by pm2fb.

Sound sreasonable.

> What kernel are you using, maybe it would be best to work on a 2.6
> kernel and try to adapt the pm2fb to the new framework or something.

Currently using Herbert's 2.4.24-1.  I tried various 2.6 kernels prior
to 2.6.1, but xdm couldn't seem to start the server and the USB HID
drivers didn't seem to be functional.

> Can you describe me the symptoms again ? what exactly did you see on the
> second head ?

The second head is currently running WindowMaker with the default Debian
background.  In the upper left corner, there is the 1/Main clip.
Directly to the right of that (I assume by 64 pixels or so) is the exact
same 1/Main clip.  In the border between the two are some flickering
white lines.  The rest of the screen is filled with horizontal
flickering black and whitish lines.  The left edge of the swirl is on
the right hand side of the screen.  It appears 5 times.  The "debian"
only appears as "de", though there are about 5 d's and 3 or 4 e's,
overlapping.  The clips themselves look perfect, but nothing else does.

Thanks.

On Tue, Jan 13, 2004 at 10:40:25AM -0500, Clint Adams wrote:
> > Ok, this may be the problem. The first one is initialized by the pm2fb,
> > while the second is not. This mean either some initialization problems,
> > or the fact that X doesn't initialize some values set by pm2fb.
> 
> Sound sreasonable.

Yep. It probably doesn't happen on x86, since the int10 stuff
initializes the card with the onboard bios. Using a x86 emulator in X to
run this bios might be a solution.

> > What kernel are you using, maybe it would be best to work on a 2.6
> > kernel and try to adapt the pm2fb to the new framework or something.
> 
> Currently using Herbert's 2.4.24-1.  I tried various 2.6 kernels prior
> to 2.6.1, but xdm couldn't seem to start the server and the USB HID
> drivers didn't seem to be functional.

Mmm.

> > Can you describe me the symptoms again ? what exactly did you see on the
> > second head ?
> 
> The second head is currently running WindowMaker with the default Debian
> background.  In the upper left corner, there is the 1/Main clip.
> Directly to the right of that (I assume by 64 pixels or so) is the exact
> same 1/Main clip.  In the border between the two are some flickering

Ho. definitively some registers who are bad. It has been a long time
since i have looked at the pm2 specs (kind of 98ish i think) though.
Maybe you could get hand of the free TI-pm2 specs and look for yourself ?

You would dump all the possible registers, and see which one is
different. Enabling debugging in the glint driver would also do. You can
safely run no-accel on these for the tests, as this is definitively not
an accel issue, but a video out/ramdac one.

> white lines.  The rest of the screen is filled with horizontal
> flickering black and whitish lines.  The left edge of the swirl is on
> the right hand side of the screen.  It appears 5 times.  The "debian"
> only appears as "de", though there are about 5 d's and 3 or 4 e's,
> overlapping.  The clips themselves look perfect, but nothing else does.

Any color problem ?

Friendly,

Sven Luther

> Yep. It probably doesn't happen on x86, since the int10 stuff
> initializes the card with the onboard bios. Using a x86 emulator in X to
> run this bios might be a solution.

According to Tech-Source, this card has no VGA bios..

> Ho. definitively some registers who are bad. It has been a long time
> since i have looked at the pm2 specs (kind of 98ish i think) though.
> Maybe you could get hand of the free TI-pm2 specs and look for yourself ?

I've been looking and not finding anything.

> You would dump all the possible registers, and see which one is
> different. Enabling debugging in the glint driver would also do. You can
> safely run no-accel on these for the tests, as this is definitively not
> an accel issue, but a video out/ramdac one.

Attached is the XFree86.0.log from xserver-xfree86-dbg.  I'll start it
again with noaccel.  The only thing I notice is that it thinks the
second card only has 4 megs of video ram.

> Any color problem ?

No.

On Wed, Jan 14, 2004 at 04:06:35PM -0500, Clint Adams wrote:
> > Yep. It probably doesn't happen on x86, since the int10 stuff
> > initializes the card with the onboard bios. Using a x86 emulator in X to
> > run this bios might be a solution.
> 
> According to Tech-Source, this card has no VGA bios..

Ok. An OF driver then ?

> > Ho. definitively some registers who are bad. It has been a long time
> > since i have looked at the pm2 specs (kind of 98ish i think) though.
> > Maybe you could get hand of the free TI-pm2 specs and look for yourself ?
> 
> I've been looking and not finding anything.

you did not find the specs, or you didn't find anything ? 

> > You would dump all the possible registers, and see which one is
> > different. Enabling debugging in the glint driver would also do. You can
> > safely run no-accel on these for the tests, as this is definitively not
> > an accel issue, but a video out/ramdac one.
> 
> Attached is the XFree86.0.log from xserver-xfree86-dbg.  I'll start it
> again with noaccel.  The only thing I notice is that it thinks the
> second card only has 4 megs of video ram.

Nope, this is not the right way, you have to rebuild the driver and add
some code to drop the content of the registers somewhere.

I don't have time right now, maybe later i will find time to send you a
register dropping patch or something.

Friendly,

Sven Luther

> You would dump all the possible registers, and see which one is
> different. Enabling debugging in the glint driver would also do. You can
> safely run no-accel on these for the tests, as this is definitively not
> an accel issue, but a video out/ramdac one.

Here's the NoAccel version.

On Wed, Jan 14, 2004 at 04:12:46PM -0500, Clint Adams wrote:
> > You would dump all the possible registers, and see which one is
> > different. Enabling debugging in the glint driver would also do. You can
> > safely run no-accel on these for the tests, as this is definitively not
> > an accel issue, but a video out/ramdac one.
> 
> Here's the NoAccel version.

This will not help, X things everything is ok, it is just the graphic
card output which is problematic. No way to find it in the log, you have
to look at the way the graphic output registers are programmed. 

Look at the pm2_dac.c stuff.

Friendly,

Sven Luther

> Ok. An OF driver then ?

I assume so.

> Nope, this is not the right way, you have to rebuild the driver and add
> some code to drop the content of the registers somewhere.
> 
> I don't have time right now, maybe later i will find time to send you a
> register dropping patch or something.

Okay, I'll poke around.  Thanks.

> This will not help, X things everything is ok, it is just the graphic
> card output which is problematic. No way to find it in the log, you have
> to look at the way the graphic output registers are programmed. 
> 
> Look at the pm2_dac.c stuff.

Well, I haven't gotten as far as dumping the registers, but I came
across Permedia2VPreInit in pm2v_dac.c, and forced it to call
Permedia2VPreInitSecondary(pScrn) unconditionally.

I also changed a few things seemingly related to linux-kernel-headers to
get the thing to compile, and it improved the situation.  Now there is a
mild amount of distortion and flicker.  The really bad part is that if I
drag an open window, it will turn into a block of noise, somewhat
related to the colors of the root window.  Also, X now detects 8 megs of
memory on that card.

> This will not help, X things everything is ok, it is just the graphic
> card output which is problematic. No way to find it in the log, you have
> to look at the way the graphic output registers are programmed. 

Attached is XFree86.0.log after putting #define DEBUG 1 at the top of
pm2v_dac.c.  For some reason this makes the right head usable, but the
left head is at the wrong resolution and distorted.

This patch helps, though the second head is still a bit fuzzy.
One other thing I've noticed is that the clock range is detected
by X as 16.25 to 110.00 MHz, though the board specs claim a max of
250MHz.

diff -ruN xc-old/programs/Xserver/hw/xfree86/drivers/glint/glint_regs.h xc/programs/Xserver/hw/xfree86/drivers/glint/glint_regs.h
--- xc-old/programs/Xserver/hw/xfree86/drivers/glint/glint_regs.h	2003-01-11 22:55:47.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/drivers/glint/glint_regs.h	2004-03-30 10:24:35.000000000 -0500
@@ -75,6 +75,10 @@
 			 ((pGlint->PciInfo->subsysCard == 0x0100) ||  \
 			  (pGlint->PciInfo->subsysCard == 0x0002)))
 
+/* Tech-Source Raptor GFX 8P (Permedia 2V) */
+#define IS_TSGFX8P	((pGlint->PciInfo->subsysVendor == 0x1227) && \
+                         (pGlint->PciInfo->subsysCard   == 0x0006))
+
 /**********************************************
 *  GLINT 500TX Configuration Region Registers *
 ***********************************************/
diff -ruN xc-old/programs/Xserver/hw/xfree86/drivers/glint/pm2v_dac.c xc/programs/Xserver/hw/xfree86/drivers/glint/pm2v_dac.c
--- xc-old/programs/Xserver/hw/xfree86/drivers/glint/pm2v_dac.c	2002-05-07 19:15:59.000000000 -0400
+++ xc/programs/Xserver/hw/xfree86/drivers/glint/pm2v_dac.c	2004-03-30 10:25:19.000000000 -0500
@@ -113,21 +113,21 @@
 	Permedia2VPreInitSecondary(pScrn);
     }
 
-#if defined(__alpha__)
+#if defined(__alpha__) || defined(__sparc__)
     /*
      * On Alpha, we have to init secondary PM2V cards, since
      * int10 cannot be run on the OEMed cards with VGA disable
      * jumpers.
      */
     if (!xf86IsPrimaryPci(pGlint->PciInfo)) {
-	if ( IS_QPM2V ) {
+	if ( (IS_QPM2V) || (IS_TSGFX8P) ) {
 
 	    xf86DrvMsg(pScrn->scrnIndex, X_INFO,
 		       "PM2V secondary: initializing\n");
 	    Permedia2VPreInitSecondary(pScrn);
 	}
     }
-#endif /* __alpha__ */
+#endif /* __alpha__ || __sparc__ */
 }
 
 Bool

On Tue, Mar 30, 2004 at 10:32:47AM -0500, Clint Adams wrote:
> This patch helps, though the second head is still a bit fuzzy.
> One other thing I've noticed is that the clock range is detected
> by X as 16.25 to 110.00 MHz, though the board specs claim a max of
> 250MHz.

I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
think. You looked at it, you have the hardware, you just have become the
resident expert on this issue :).

Friendly,

Sven Luther

> I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> think. You looked at it, you have the hardware, you just have become the
> resident expert on this issue :).

Ahh.  I tried increasing the 32bpp number to 150MHz, and was successfully
able to use a mode at 135MHz.  I am confused as to why the Pixmap setting
affects the ramdac frequency.  Is this a mistake or am I misunderstanding 
something?  Would it be okay to set the maximum based on depth instead
of bitsPerPixel, or is bitsPerPixel wrong if it's set to 32 at a plain
24-bit depth?

On Tue, Mar 30, 2004 at 06:02:03PM -0500, Clint Adams wrote:
> > I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> > remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> > think. You looked at it, you have the hardware, you just have become the
> > resident expert on this issue :).
> 
> Ahh.  I tried increasing the 32bpp number to 150MHz, and was successfully
> able to use a mode at 135MHz.  I am confused as to why the Pixmap setting
> affects the ramdac frequency.  Is this a mistake or am I misunderstanding 
> something?  Would it be okay to set the maximum based on depth instead
> of bitsPerPixel, or is bitsPerPixel wrong if it's set to 32 at a plain
> 24-bit depth?

I would have to look in the specs, but i believe the ramdac is only able
to push less pixels if those are of 16 or 32 bpp. This is the case for
all 3Dlabs chips prior to the permedia3. Look at the part in glint_driver.c
where these values are set. I have no explanation also, since my
involvement was with the permedia3, so maybe ask Alan Hourihane about
it.

Friendly,

Sven Luther

On Wed, 31 Mar 2004, Sven Luther wrote:
> On Tue, Mar 30, 2004 at 06:02:03PM -0500, Clint Adams wrote:
> > > I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> > > remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> > > think. You looked at it, you have the hardware, you just have become the
> > > resident expert on this issue :).
> >
> > Ahh.  I tried increasing the 32bpp number to 150MHz, and was successfully
> > able to use a mode at 135MHz.  I am confused as to why the Pixmap setting
> > affects the ramdac frequency.  Is this a mistake or am I misunderstanding
> > something?  Would it be okay to set the maximum based on depth instead
> > of bitsPerPixel, or is bitsPerPixel wrong if it's set to 32 at a plain
> > 24-bit depth?
>
> I would have to look in the specs, but i believe the ramdac is only able
> to push less pixels if those are of 16 or 32 bpp. This is the case for
> all 3Dlabs chips prior to the permedia3. Look at the part in glint_driver.c
> where these values are set. I have no explanation also, since my
> involvement was with the permedia3, so maybe ask Alan Hourihane about
> it.

If your graphics controller is limited by memory bandwidth, the maximum pixel
clock depends on the number of bits per pixels, since larger pixels mean more
memory bandwidth.

Gr{oetje,eeting}s,

						Geert

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

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

> If your graphics controller is limited by memory bandwidth, the maximum pixel
> clock depends on the number of bits per pixels, since larger pixels mean more
> memory bandwidth.

I'm unclear on the differences between 24 bpp and 32 bpp and how this
relates to internal pixmap format.

On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > If your graphics controller is limited by memory bandwidth, the maximum=
 pixel
> > clock depends on the number of bits per pixels, since larger pixels mea=
n more
> > memory bandwidth.
>=20
> I'm unclear on the differences between 24 bpp and 32 bpp and how this
> relates to internal pixmap format.

Some hardware uses a "packed-pixel format"; that is, 4 24-bit pixels are
encoded in 3 32-bit words (what Intel calls "DWORDS", I think).

Other hardware tosses in a zero byte with every 32-bit "DWORD" transfer.

--=20
G. Branden Robinson                |     The last time the Republican Party
Debian GNU/Linux                   |     was on the right side of a social
branden@...                 |     issue, Abe Lincoln was president.
http://people.debian.org/~branden/ |     -- Kirk Tofte

On Thu, Apr 01, 2004 at 01:41:22AM -0500, Branden Robinson wrote:
> On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > > If your graphics controller is limited by memory bandwidth, the maximum pixel
> > > clock depends on the number of bits per pixels, since larger pixels mean more
> > > memory bandwidth.
> > 
> > I'm unclear on the differences between 24 bpp and 32 bpp and how this
> > relates to internal pixmap format.
> 
> Some hardware uses a "packed-pixel format"; that is, 4 24-bit pixels are
> encoded in 3 32-bit words (what Intel calls "DWORDS", I think).

Yeah, DWORDS, because they are stil living in the era of 16bit hardware :)

> Other hardware tosses in a zero byte with every 32-bit "DWORD" transfer.

Well, the permedia2 should support both formats, depending on chosen
mode.

Friendly,

Sven Luther

On Thu, Apr 01, 2004 at 08:51:02AM +0200, Sven Luther wrote:
> On Thu, Apr 01, 2004 at 01:41:22AM -0500, Branden Robinson wrote:
> > On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > > > If your graphics controller is limited by memory bandwidth, the max=
imum pixel
> > > > clock depends on the number of bits per pixels, since larger pixels=
 mean more
> > > > memory bandwidth.
> > >=20
> > > I'm unclear on the differences between 24 bpp and 32 bpp and how this
> > > relates to internal pixmap format.
> >=20
> > Some hardware uses a "packed-pixel format"; that is, 4 24-bit pixels are
> > encoded in 3 32-bit words (what Intel calls "DWORDS", I think).
>=20
> Yeah, DWORDS, because they are stil living in the era of 16bit hardware :)
>=20
> > Other hardware tosses in a zero byte with every 32-bit "DWORD" transfer.
>=20
> Well, the permedia2 should support both formats, depending on chosen
> mode.

Well, maybe this is what is going on.  Maybe Solaris is using a
packed-pixel format, and XFree86 is using zero-padded format.

That is, assuming it's the RAMDAC's job to understand the pixel format,
and that some part isn't stuck in front of it to give it a standardized
format.  I wouldn't know.

--=20
G. Branden Robinson                |     That's the saving grace of humor:
Debian GNU/Linux                   |     if you fail, no one is laughing at
branden@...                 |     you.
http://people.debian.org/~branden/ |     -- A. Whitney Brown