Re: Complete fix for PB 2400 16-bit video problem

Re: Complete fix for PB 2400 16-bit video problem

[Benjamin Herrenschmidt]

On Sun, Dec 13, 1998, David Ray <daver@idiom.com> wrote:

>It appears that the 16-bit in the console still has some problems. The color
>balance is off, but useable. Red is too bright and blue is too dim. I use a
>custom prompt that uses ansi colors so the color balance at the console
is more
>apparent on my system than on one that just uses white characters.

There is still a little issue with DIRECTCOLOR vs. TRUECOLOR and default
console color map, I think Tim will post a patch soon but if he can't,
I'll try a fix and send it to the list (I don't own a 2400 so I can't test).

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Complete fix for PB 2400 16-bit video problem

[David Ray]

Sorry it's taken me a few days to get back to the list with a status on the chipsfb.c driver.

I want to thank Tim for his enormous help with the Chips 65550 video driver on the Powerbook 2400. I confirmed what a couple other readers already posted. The diff that Tim develped definitely fixes all vodeo problems in X at all depths, and improves the video problem while in 16-bit mode on the console. Thanks, Tim!

I'm booting from quik, not using anything special in my boot settings and not using BootX. I compiled the 2.1.130 kernel to use the custom fb8 and fb16 values. The startup messages indicate it is recognizing the driver as Chips 65550. Xpmac that was developed for the pb2400/3400 now works fine in all depths.

It appears that the 16-bit in the console still has some problems. The color balance is off, but useable. Red is too bright and blue is too dim. I use a custom prompt that uses ansi colors so the color balance at the console is more apparent on my system than on one that just uses white characters.

The new XF68_FBDev just released from the xfree86 site still fails in 16 bit mode. This is not a color balance problem, but something more serious. It looks like only half the screen is trying to be initialized while the bottom half still shows a "compressed" display of the console. After about a second, X fails and exits.

As usual, let me know if there is any information I can collect that would be useful in debugging these problems.

Cheers-

Dave
daver@idiom.com



> Date: Tue, 8 Dec 1998 00:38:39 -0800
> From: "Timothy A. Seufert" <tas@mindspring.com>
> Subject: Complete fix for PB 2400 16-bit video problem
> 
> I figured out why 16-bit doesn't work in the console today.  I wasn't
> checking "Advanced driver options" in the console setup screen (I use make
> menuconfig).  This resulted in CONFIG_FBCON_CFB16 (I think that's the name)
> not getting set, which .  Perhaps the CONFIG_FBCON_CFBxx settings should
> default to Y?
> 
> 
> Also, since I proved in my earlier message that I didn't know how to use
> diff, and got told about it :), here is a better diff for
> drivers/video/chipsfb.c.  This will patch it to correctly change bitdepth.
> 
> 



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Complete fix for PB 2400 16-bit video problem

[Ted Whalen]

David Ray wrote:
> The new XF68_FBDev just released from the xfree86 site still fails in
> 16 bit mode. This is not a color balance problem, but something more
> serious. It looks like only half the screen is trying to be
> initialized while the bottom half still shows a "compressed" display
> of the console. After about a second, X fails and exits.

I had this problem too, and I realized that it was due to the
hard-coded video ram setting in chipsfb.c -- it assumes 468k of vram,
when in fact most machines have more.  To get around this, use the
following diff.

diff -r1.16 chipsfb.c
553c553
< 	p->fix.smem_len = 800 * 600;
---
> 	p->fix.smem_len = 1024 * 1024; /* 800 * 600 */

However, even with this fix -- which provides the 1mb of vram I so
richly deserve, the colors are screwy.

tew
-- 
             Is "Princess" your real name?
                Ted Whalen - tew@nwu.edu

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Partial fix for 2400 16-bit video problem

[Timothy A. Seufert]

The Problem: In recent kernels, the chipsfb driver for the C&T 65550
chipset has been broken for 16-bit modes.

The Solution: I did some poking around, and discovered some lines related
to turning palettes on and off missing from the 16/8-bit mode switch code
in chipsfb.c.  These were present in 2.1.115 but disappeared somewhere
along the road to 2.1.130.

With the lines restored, the 2/3400 accelerated version of Xpmac works in
16-bit mode again.  I haven't been trying XF68FBDev, so I don't know if it
was ever broken, but I suspect it would be as this shouldn't be specific to
any one X server.

The console is still broken for 16-bit mode, and I have no idea why.
Fortunately, 16-bit color is not a necessity on the console.  For whatever
reason, the fb console driver does not seem to be capable of writing
anything to a chipsfb display; it doesn't even manage to clear the frame
buffer when the switch to 16-bit is made, so you get to see leftover
garbage from when it was 8-bit.

Here is the diff relative to the version of chipsfb.c in the latest vger
kernel that I synced with:

----------cut here-----------
360a361
> 			write_xr(0x82, 0x00);		// disable palettes
381a383
> 			write_xr(0x82, 0x08);		// Graphics gamma
>enable
----------cut here-----------

If your chipsfb.c is different from mine, here is the context:  The first
line should be inserted after the line containing "write_xr(0x81, 0x14)"
and the second line should be inserted after the line containing
"write_xr(0x81, 0x12)".

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Complete fix for PB 2400 16-bit video problem

[Timothy A. Seufert]

I figured out why 16-bit doesn't work in the console today.  I wasn't
checking "Advanced driver options" in the console setup screen (I use make
menuconfig).  This resulted in CONFIG_FBCON_CFB16 (I think that's the name)
not getting set, which .  Perhaps the CONFIG_FBCON_CFBxx settings should
default to Y?


Also, since I proved in my earlier message that I didn't know how to use
diff, and got told about it :), here is a better diff for
drivers/video/chipsfb.c.  This will patch it to correctly change bitdepth.


---------cut-----------------
--- chipsfb.orig.c	Mon Dec  7 00:24:13 1998
+++ chipsfb.c	Mon Dec  7 01:27:17 1998
@@ -358,6 +358,7 @@
 		if (con == currcon) {
 			write_cr(0x13, 200);		// 16 bit display
width (decimal)
 			write_xr(0x81, 0x14);		// 15 bit
(TrueColor) color mode
+			write_xr(0x82, 0x00);		// disable palettes
 			write_xr(0x20, 0x10);		// 16 bit blitter mode
 		}

@@ -379,6 +380,7 @@
 		if (con == currcon) {
 			write_cr(0x13, 100);		// 8 bit display
width (decimal)
 			write_xr(0x81, 0x12);		// 8 bit color mode
+			write_xr(0x82, 0x08);		// Graphics gamma
enable
 			write_xr(0x20, 0x00);		// 8 bit blitter mode
 		}
---------cut-----------------

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Complete fix for PB 2400 16-bit video problem

[Geert Uytterhoeven]

On Tue, 8 Dec 1998, Timothy A. Seufert wrote:
> I figured out why 16-bit doesn't work in the console today.  I wasn't
> checking "Advanced driver options" in the console setup screen (I use make
> menuconfig).  This resulted in CONFIG_FBCON_CFB16 (I think that's the name)
> not getting set, which .  Perhaps the CONFIG_FBCON_CFBxx settings should
> default to Y?

You're right. If CONFIG_FB_CT65550 is enabled but Advanced driver options
isn't, it should enable support for cfb8 and cfb16 automatically. I'll fix
that.

> Also, since I proved in my earlier message that I didn't know how to use
> diff, and got told about it :), here is a better diff for
> drivers/video/chipsfb.c.  This will patch it to correctly change bitdepth.
> 
> 
> ---------cut-----------------
> --- chipsfb.orig.c	Mon Dec  7 00:24:13 1998
> +++ chipsfb.c	Mon Dec  7 01:27:17 1998
> @@ -358,6 +358,7 @@
>  		if (con == currcon) {
>  			write_cr(0x13, 200);		// 16 bit display
> width (decimal)
  ^^^^^^^^^^^^^^^
Please use a mailer that doesn't wrap long lines, since patch doesn't like
that.

>  			write_xr(0x81, 0x14);		// 15 bit
> (TrueColor) color mode
> +			write_xr(0x82, 0x00);		// disable palettes
>  			write_xr(0x20, 0x10);		// 16 bit blitter mode
>  		}
> 
> @@ -379,6 +380,7 @@
                 ^
>  		if (con == currcon) {
>  			write_cr(0x13, 100);		// 8 bit display
> width (decimal)
>  			write_xr(0x81, 0x12);		// 8 bit color mode
> +			write_xr(0x82, 0x08);		// Graphics gamma
> enable
>  			write_xr(0x20, 0x00);		// 8 bit blitter mode
>  		}
> ---------cut-----------------
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You cut an important empty line. The `7' means the patch hunk will result in
_7_ lines, not 6.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]