Hi all,
I have been trying to get a CG3 sparc clone up and running with linux.
Under 2.2.26, the console is fine. During the development of the
2.5.x/2.6.x frame buffer system the CG3 support got broken. I have managed
to track done one of the problems (the blanking code had some typing
errors in it) and this gave me a logo + black screen and cursor using a
linux-2.2.8.1 kernel. Still no console text.
Given that 2.2.10-rc1-bk6 is available, I have downloaded and applied the
appropriate patches and made some additional mods to keep the
compiler/linker happy. Now I have a black console, no text, logo or cursor
and if I redirect the console output to a serial port I get the following:
-------------------------------------------------------------------------
b vmlinux.sun4c
Probing Memory Bank #: 1 2 3 4 5
Booting from: sd(0,0,0)vmlinux.sun4c
root on sd0a fstype 4.2
Size: 1990912+0+117384 bytes
PROMLIB: Sun Boot Prom Version 0 Revision 0
Linux version 2.6.10-MTF (mark@fw) (gcc version 3.4.2) #3 Fri Oct 29
18:04:22 BST 2004
ARCH: SUN4C
TYPE: Sun4c SparcStation 1
Ethernet address: 0:80:f1:0:5:89
Loading sun4c MMU routines
Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek ([email protected]). Patching
kernel for sun4c
SUN4C: 79 mmu entries for the kernel
Booting Linux...
auxio register: 0xffd0e000
Built 1 zonelists
Kernel command line: -p
ip=10.1.1.3:10.1.1.4:10.1.1.3:255.255.255.0:sparc3::off root=/dev/sda4
rootfstype=ufs rootflags=ufstype=sunos
PID hash table entries: 64 (order: 6, 1024 bytes)
time_init: reg address: fe001000
Console: mono PROM 80x34
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 14084k/16332k available (1440k kernel code, 2224k reserved, 376k
data, 120k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
NET: Registered protocol family 16
SCSI subsystem initialized
sbus0: Clock 20.0 MHz
dma0 register address at 0xfe002000
dma0: Revision 1
CG3 Register Base Address: fe003000
CG3 Screen Base Address: ffd80000
Console: switching to colour frame buffer device 80x34
cg3: cgthree at 1:fe000000
Zilog Serial 0 @ 0xffd02000
Zilog Serial 1 @ 0xffd00000
zs2 at 0xffd00004 (irq = 12) is a SunZilog
zs3 at 0xffd00000 (irq = 12) is a SunZilog
ttyS0 at MMIO 0x0 (irq = 12) is a SunZilog
ttyS1 at MMIO 0x0 (irq = 12) is a SunZilog
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
elevator: using anticipatory as default io scheduler
Floppy drive(s): fd0 is 1.44M
Floppy Address: 0xffd18000
Sparc FDC is 82077
FDC 0 is a pre-1991 82077
sunlance.c:v2.02 24/Aug/03 Miguel de Icaza ([email protected])
SunLance at register address fe004000
eth0: LANCE 00:80:f1:00:05:89
ESP registers at fe005000
esp0: IRQ 3 SCSI ID 7 Clk 20MHz CCYC=50000 CCF=4 TOut 167
NCR53C90A(esp100a)
ESP: Total of 1 ESP hosts found, 1 actually in use.
scsi0 : Sparc ESP100A (NCR53C90A)
Vendor: IBM Model: DORS-32160 Rev: S82C
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 sda4 sda5 sda7 sda8
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
mice: PS/2 mouse device common for all mice
input: Sun Type 4 keyboard on zs/serio0
input: Sun Mouse on zs/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 1024)
NET: Registered protocol family 1
IP-Config: Complete:
device=eth0, addr=10.1.1.3, mask=255.255.255.0, gw=10.1.1.3,
host=sparc3, domain=, nis-domain=(none),
bootserver=10.1.1.4, rootserver=10.1.1.4, rootpath=
ufs_read_super: fs needs fsck
VFS: Mounted root (ufs filesystem) readonly.
Freeing unused kernel memory: 120k freed
Warning: unable to open an initial console.
Kernel panic - not syncing: Attempted to kill init!
<0>Press L1-A to return to the boot prom
-------------------------------------------------------------------------
The questions are:
1) How do a force the frame buffer system to initialise the colour pallet
on CG3 initialisation (PROM uses black on white, linux uses white on
black).
2) What command line options are required to use a prom console, followed
by a CG3 console (as soon as the CG3 is available) and have a logo on the
CG3 console.
3) Is there any documentation for this as I have not been able to find
anything appropriate and the code is far from easy to decipher.
Please note, my kernel has been tweeked to:
a) To have a default command line as the SunOS boot code does not apear
to be passing command line parameters in a compatible way and it saves on
the typing.
b) Use PROM addresses were available to help me with the debugging.
c) To fix 82077 FDC detection for sun4c.
d) To fix CG3 blanking code errors.
e) To get around incorrect compilation (or a bug in printk) of %llu
parameters to printk in sd.c. (I use %lu with unsigned long ards instead).
f) To have a SunOS 4.1.1 compatible partition detection system.
Thank you to thoes who have helped me so far. I am slowly making progress.
Regards
Mark Fortescue.
On Fri, Oct 29, 2004 at 07:22:11PM +0100, Mark Fortescue wrote:
> I have been trying to get a CG3 sparc clone up and running with linux.
> Under 2.2.26, the console is fine. During the development of the
> 2.5.x/2.6.x frame buffer system the CG3 support got broken. I have managed
> to track done one of the problems (the blanking code had some typing
> errors in it) and this gave me a logo + black screen and cursor using a
> linux-2.2.8.1 kernel. Still no console text.
> Given that 2.2.10-rc1-bk6 is available, I have downloaded and applied the
> appropriate patches and made some additional mods to keep the
> compiler/linker happy. Now I have a black console, no text, logo or cursor
> and if I redirect the console output to a serial port I get the following:
Okay, sounds like a relatively major disaster. =(
-- wli
On Fri, Oct 29, 2004 at 07:22:11PM +0100, Mark Fortescue wrote:
> e) To get around incorrect compilation (or a bug in printk) of %llu
> parameters to printk in sd.c. (I use %lu with unsigned long ards instead).
If this is what I looked at about 6 months ago, it's a compiler bug
probably specific to 32-bit SPARC. The problem occurs if there are
enough arguments that the stack has to be used to pass some of them
(so more than 6 32-bit quantities), and the 6th argument was the first
half of a long long. So a function with a prototype like:
void foo(int, int, int, int, int, long long);
would be affected, while:
void foo(int, int, int, int, int, int, long long);
and
void foo(long long, long long, long long, int, int);
were ok.
It looks like my 3.4.3-pre gcc now generates:
0000000000000000 <foo>:
0: 9d e3 bf 90 save %sp, -112, %sp
4: fa 27 a0 58 st %i5, [ %fp + 0x58 ]
8: 11 00 00 00 sethi %hi(0), %o0
8: R_SPARC_HI22 .rodata
c: b0 06 00 19 add %i0, %i1, %i0
10: 90 12 20 00 mov %o0, %o0
10: R_SPARC_LO10 .rodata
14: d2 07 a0 58 ld [ %fp + 0x58 ], %o1
18: d4 07 a0 5c ld [ %fp + 0x5c ], %o2
1c: 40 00 00 00 call 1c <foo+0x1c>
1c: R_SPARC_WDISP30 printf
20: b0 06 00 1a add %i0, %i2, %i0
24: b0 06 00 1b add %i0, %i3, %i0
28: b0 06 00 1c add %i0, %i4, %i0
2c: c2 07 a0 60 ld [ %fp + 0x60 ], %g1
30: 81 c7 e0 08 ret
34: 91 ee 00 01 restore %i0, %g1, %o0
0000000000000038 <main>:
38: 9d e3 bf 88 save %sp, -120, %sp
3c: 1b 3f bb 7e sethi %hi(0xfeedf800), %o5
40: 9a 13 62 ce or %o5, 0x2ce, %o5 ! feedface <main+0xfeedfa96>
44: da 23 a0 5c st %o5, [ %sp + 0x5c ]
48: 82 10 20 08 mov 8, %g1
4c: 1b 37 ab 6f sethi %hi(0xdeadbc00), %o5
50: c2 23 a0 60 st %g1, [ %sp + 0x60 ]
54: 9a 13 62 ef or %o5, 0x2ef, %o5 ! deadbeef
58: 90 10 20 00 clr %o0
5c: 92 10 20 01 mov 1, %o1
60: 94 10 20 02 mov 2, %o2
64: 96 10 20 03 mov 3, %o3
68: 40 00 00 00 call 68 <main+0x30>
68: R_SPARC_WDISP30 foo
6c: 98 10 20 04 mov 4, %o4
70: 81 c7 e0 08 ret
74: 91 e8 00 08 restore %g0, %o0, %o0
for
#include <stdio.h>
int foo(int, int, int, int, int, unsigned long long, int);
int
main(int argc, char *argv[])
{
return (foo(0, 1, 2, 3, 4, 0xdeadbeeffeedfaceULL, 8));
}
int
foo(int a, int b, int c, int d, int e, unsigned long long f, int g)
{
printf("ull: %llx\n", f);
return (a + b + c + d + e + g);
}
when compiled with -m32 -O2. This code is correct, and moreover,
SunPro generates nearly identical code (and more importantly an
identical argument layout, with the high half in %o5 and the low half
at %sp + 0x5c as seen by the caller):
0000000000000000 <main>:
0: 9d e3 bf 98 save %sp, -104, %sp
4: 3b 37 ab 6f sethi %hi(0xdeadbc00), %i5
8: b6 10 20 08 mov 8, %i3
c: f6 23 a0 60 st %i3, [ %sp + 0x60 ]
10: 9a 07 62 ef add %i5, 0x2ef, %o5
14: 3b 3f bb 7e sethi %hi(0xfeedf800), %i5
18: ba 07 62 ce add %i5, 0x2ce, %i5 ! feedface <foo+0xfeedfa8e>
1c: fa 23 a0 5c st %i5, [ %sp + 0x5c ]
20: 90 10 20 00 clr %o0
24: 92 10 20 01 mov 1, %o1
28: 94 10 20 02 mov 2, %o2
2c: 96 10 20 03 mov 3, %o3
30: 40 00 00 00 call 30 <main+0x30>
30: R_SPARC_WDISP30 foo
34: 98 10 20 04 mov 4, %o4
38: 81 c7 e0 08 ret
3c: 91 e8 00 08 restore %g0, %o0, %o0
0000000000000040 <foo>:
40: 9d e3 bf a0 save %sp, -96, %sp
44: fa 27 a0 58 st %i5, [ %fp + 0x58 ]
48: 92 10 00 1d mov %i5, %o1
4c: 3b 00 00 00 sethi %hi(0), %i5
4c: R_SPARC_HI22 .rodata1
50: d4 07 a0 5c ld [ %fp + 0x5c ], %o2
54: 40 00 00 00 call 54 <foo+0x14>
54: R_SPARC_WDISP30 printf
58: 90 07 60 00 add %i5, 0, %o0
58: R_SPARC_LO10 .rodata1
5c: ba 06 00 19 add %i0, %i1, %i5
60: ea 07 a0 60 ld [ %fp + 0x60 ], %l5
64: ae 07 40 1a add %i5, %i2, %l7
68: ac 05 c0 1b add %l7, %i3, %l6
6c: a8 05 80 1c add %l6, %i4, %l4
70: 81 c7 e0 08 ret
74: 91 ed 00 15 restore %l4, %l5, %o0
You might try compiling sd.c with 3.4.3 and comparing the generated
assembly with what you get from your usual compiler, referencing the
calling convention shown above. The particular compiler I use is
configured for Solaris, but I'd be very surprised if the convention
were different when configured for Linux. Even if it is, the crucial
thing is for the caller and callee to agree on where argument f is
located in the above example. When I last looked at the sd.c
assembly, they did not.
Changing the type to unsigned long is not the right solution. If gcc
is severely defective in this area, pass two unsigned longs and put
them back together yourself in the callee. Of course it's really
better just to fix the compiler.
--
Keith M Wesolowski
"Site launched. Many things not yet working." --Hector Urtubia
On Saturday 30 October 2004 02:22, Mark Fortescue wrote:
> Hi all,
>
> I have been trying to get a CG3 sparc clone up and running with linux.
> Under 2.2.26, the console is fine. During the development of the
> 2.5.x/2.6.x frame buffer system the CG3 support got broken. I have managed
> to track done one of the problems (the blanking code had some typing
> errors in it) and this gave me a logo + black screen and cursor using a
> linux-2.2.8.1 kernel. Still no console text.
>
> Given that 2.2.10-rc1-bk6 is available, I have downloaded and applied the
> appropriate patches and made some additional mods to keep the
> compiler/linker happy. Now I have a black console, no text, logo or cursor
> and if I redirect the console output to a serial port I get the following:
I'm assuming 2.6.10-rc1-bk6...
Make sure you correctly fill up the red, green, blue, and transp fields
in all->info.var. You can do it in sbufsfb_fill_var, or somewhere
within cg3.c before the register_framebuffer() part.
As a reminder, info->var and info->fix must be valid prior to framebuffer
registration.
Tony
Hi all,
Thanks for the info Antonino. I see you spotted my typing error. Yes it is
the 2.6.10-rc1-bk6 kernel. The oter error is the 2.2.8.1. It should be
2.6.8.1.
The cgthree driver does not currently set up the all->info.var.red,
all->info.var.green or all->info.var.blue structures. Putting a value of 8
in the length field of these structures (correct for the cgthree) does get
me my logo back but I am still getting black on black text. It makes it
very difficult to read. It is begining to look like there is something
werid going on with the colour pallet stuf for PSEUDO_COLOUR.
Regards
Mark Fortescue.
On Sat, 30 Oct 2004, Antonino A. Daplas wrote:
> On Saturday 30 October 2004 02:22, Mark Fortescue wrote:
> > Hi all,
> >
> > I have been trying to get a CG3 sparc clone up and running with linux.
> > Under 2.2.26, the console is fine. During the development of the
> > 2.5.x/2.6.x frame buffer system the CG3 support got broken. I have managed
> > to track done one of the problems (the blanking code had some typing
> > errors in it) and this gave me a logo + black screen and cursor using a
> > linux-2.2.8.1 kernel. Still no console text.
> >
> > Given that 2.2.10-rc1-bk6 is available, I have downloaded and applied the
> > appropriate patches and made some additional mods to keep the
> > compiler/linker happy. Now I have a black console, no text, logo or cursor
> > and if I redirect the console output to a serial port I get the following:
>
> I'm assuming 2.6.10-rc1-bk6...
>
> Make sure you correctly fill up the red, green, blue, and transp fields
> in all->info.var. You can do it in sbufsfb_fill_var, or somewhere
> within cg3.c before the register_framebuffer() part.
>
> As a reminder, info->var and info->fix must be valid prior to framebuffer
> registration.
>
> Tony
>
>
>
>
On Tuesday 02 November 2004 01:32, Mark Fortescue wrote:
> Hi all,
>
> Thanks for the info Antonino. I see you spotted my typing error. Yes it is
> the 2.6.10-rc1-bk6 kernel. The oter error is the 2.2.8.1. It should be
> 2.6.8.1.
>
> The cgthree driver does not currently set up the all->info.var.red,
> all->info.var.green or all->info.var.blue structures. Putting a value of 8
> in the length field of these structures (correct for the cgthree) does get
> me my logo back but I am still getting black on black text. It makes it
> very difficult to read. It is begining to look like there is something
> werid going on with the colour pallet stuf for PSEUDO_COLOUR.
>
I doubt that the problem is at the driver layer since you were able to
see the logo. It's probably higher up.
Try this mod, hardwire the foreground color to 0x07.
Edit drivers/video/console/bitblit.c:bit_putcs() and change this line:
image.fg_color = fg;
image.bg_color = bg;
to
image.fg_color = 0x07070707;
image.bg_color = 0x0;
You can also try the reverse:
image.fg_color = 0x0;
image.bg_color = 0x07070707
If you get visible text, the problem is either in fbcon.c or vt.c.
Tony
On Tuesday 02 November 2004 00:46, Antonino A. Daplas wrote:
> On Tuesday 02 November 2004 01:32, Mark Fortescue wrote:
> > Hi all,
> >
> > Thanks for the info Antonino. I see you spotted my typing error. Yes it is
> > the 2.6.10-rc1-bk6 kernel. The oter error is the 2.2.8.1. It should be
> > 2.6.8.1.
> >
> > The cgthree driver does not currently set up the all->info.var.red,
> > all->info.var.green or all->info.var.blue structures. Putting a value of 8
> > in the length field of these structures (correct for the cgthree) does get
> > me my logo back but I am still getting black on black text. It makes it
> > very difficult to read. It is begining to look like there is something
> > werid going on with the colour pallet stuf for PSEUDO_COLOUR.
I saw similiar problems with the stifb driver on HPPA.
Changing the driver's pseudo_palette[] struct to support 256 colors solved this problem.
But there might be a problem in higher levels as well....
Helge
Hi all,
I have already hard wired the fg and bg colours. I have got to the point
where I am checking the cfbimgblt code where it converts the mono bit font
image data to the 8bpp pseudo colour screen image data. It is looking
like there may be a problem with sign extension at this level as the
pixel value being used apears to be 255.
I have changed a char *pt to a u8 *pt to see if this helps.
Regards
Mark Fortescue.
On Tue, 2 Nov 2004, Antonino A. Daplas wrote:
> On Tuesday 02 November 2004 01:32, Mark Fortescue wrote:
> > Hi all,
> >
> > Thanks for the info Antonino. I see you spotted my typing error. Yes it is
> > the 2.6.10-rc1-bk6 kernel. The oter error is the 2.2.8.1. It should be
> > 2.6.8.1.
> >
> > The cgthree driver does not currently set up the all->info.var.red,
> > all->info.var.green or all->info.var.blue structures. Putting a value of 8
> > in the length field of these structures (correct for the cgthree) does get
> > me my logo back but I am still getting black on black text. It makes it
> > very difficult to read. It is begining to look like there is something
> > werid going on with the colour pallet stuf for PSEUDO_COLOUR.
> >
>
> I doubt that the problem is at the driver layer since you were able to
> see the logo. It's probably higher up.
>
> Try this mod, hardwire the foreground color to 0x07.
>
> Edit drivers/video/console/bitblit.c:bit_putcs() and change this line:
>
> image.fg_color = fg;
> image.bg_color = bg;
>
> to
>
> image.fg_color = 0x07070707;
> image.bg_color = 0x0;
>
> You can also try the reverse:
>
> image.fg_color = 0x0;
> image.bg_color = 0x07070707
>
> If you get visible text, the problem is either in fbcon.c or vt.c.
>
> Tony
>
>
Hi all,
I have identified what is going on. My CG3 console uses the same font and
exactly overlaps prom console. [I have re-inserted the console margin code
for my CG3 driver]. The timing is such that the prom overwrites the
console text (using colour 255) a fraction later than the fbcon code.
The two problems to be solved are (apart from seting the red,green and
blue structures up for the cg series fb cards):
1) The prom write (from -p) needs to be disabled as soon as an alternative
console becomes active (either prom console, fbcon console or serial
console). This has probably been the major cause of hassel.
2) The restore pallet function (see cgsix.c in the 2.2.x or 2.4.x kernels)
needs to be re-introduced in some form and called when exiting fbcon so
that the prom does not end up as black on black. My prom uses fg=255,
bg=0. Does any one know if this is standard for all sparc boot proms.
I need to tidy up my code before I start work on the first of these two
problems. The second one should not catch me out as I am using colour
255 as my margin colour and it is set to "Dark Slate Grey" so I do not
have a black on black prom console.
If any one wants a linux 2.6.10 CG3 driver with software margins then let
me know and I will post an appropriate patch.
Regards
Mark Fortescue.
On Tue, 2 Nov 2004, Antonino A. Daplas wrote:
> On Tuesday 02 November 2004 01:32, Mark Fortescue wrote:
> > Hi all,
> >
> > Thanks for the info Antonino. I see you spotted my typing error. Yes it is
> > the 2.6.10-rc1-bk6 kernel. The oter error is the 2.2.8.1. It should be
> > 2.6.8.1.
> >
> > The cgthree driver does not currently set up the all->info.var.red,
> > all->info.var.green or all->info.var.blue structures. Putting a value of 8
> > in the length field of these structures (correct for the cgthree) does get
> > me my logo back but I am still getting black on black text. It makes it
> > very difficult to read. It is begining to look like there is something
> > werid going on with the colour pallet stuf for PSEUDO_COLOUR.
> >
>
> I doubt that the problem is at the driver layer since you were able to
> see the logo. It's probably higher up.
>
> Try this mod, hardwire the foreground color to 0x07.
>
> Edit drivers/video/console/bitblit.c:bit_putcs() and change this line:
>
> image.fg_color = fg;
> image.bg_color = bg;
>
> to
>
> image.fg_color = 0x07070707;
> image.bg_color = 0x0;
>
> You can also try the reverse:
>
> image.fg_color = 0x0;
> image.bg_color = 0x07070707
>
> If you get visible text, the problem is either in fbcon.c or vt.c.
>
> Tony
>
>
Will this work for a kernel Panic ?
Mark
On Wed, 3 Nov 2004, Antonino A. Daplas wrote:
> On Wednesday 03 November 2004 02:03, Mark Fortescue wrote:
> > Hi all,
> >
> > I have identified what is going on. My CG3 console uses the same font and
> > exactly overlaps prom console. [I have re-inserted the console margin code
> > for my CG3 driver]. The timing is such that the prom overwrites the
> > console text (using colour 255) a fraction later than the fbcon code.
> >
> > The two problems to be solved are (apart from seting the red,green and
> > blue structures up for the cg series fb cards):
> >
> > 1) The prom write (from -p) needs to be disabled as soon as an alternative
> > console becomes active (either prom console, fbcon console or serial
> > console). This has probably been the major cause of hassel.
> >
> > 2) The restore pallet function (see cgsix.c in the 2.2.x or 2.4.x kernels)
> > needs to be re-introduced in some form and called when exiting fbcon so
> > that the prom does not end up as black on black. My prom uses fg=255,
>
> You can implement a cg3fb_open() and cg3fb_release() hooks and set up a
> use_count field. You increment the count on every open, decrement on every
> release. Then restore whatever on the last release. Optionally, you can even
> do hardware inits on the first open.
>
> Tony
>
>
On Wednesday 03 November 2004 06:57, Mark Fortescue wrote:
> Will this work for a kernel Panic ?
>
Probably not, unless the 'Panic' tells fbcon to release the console and
tells promcon to take over the console again. That in itself is problematic
as fbcon cannot be safely unloaded yet.
Tony
I have just tested it and at the moment it does not. I suspect that
something needs to be registered in the 'panic_notifier_list' to do some
basic resets on the colour palette.
For the moment I will just ensure that colour 255 <> colour 0 by some
visible margin (Black/Dark Slate).
Mark.
On Wed, 3 Nov 2004, Antonino A. Daplas wrote:
> On Wednesday 03 November 2004 06:57, Mark Fortescue wrote:
> > Will this work for a kernel Panic ?
> >
>
> Probably not, unless the 'Panic' tells fbcon to release the console and
> tells promcon to take over the console again. That in itself is problematic
> as fbcon cannot be safely unloaded yet.
>
> Tony
>
>
On Wednesday 03 November 2004 02:03, Mark Fortescue wrote:
> Hi all,
>
> I have identified what is going on. My CG3 console uses the same font and
> exactly overlaps prom console. [I have re-inserted the console margin code
> for my CG3 driver]. The timing is such that the prom overwrites the
> console text (using colour 255) a fraction later than the fbcon code.
>
> The two problems to be solved are (apart from seting the red,green and
> blue structures up for the cg series fb cards):
>
> 1) The prom write (from -p) needs to be disabled as soon as an alternative
> console becomes active (either prom console, fbcon console or serial
> console). This has probably been the major cause of hassel.
>
> 2) The restore pallet function (see cgsix.c in the 2.2.x or 2.4.x kernels)
> needs to be re-introduced in some form and called when exiting fbcon so
> that the prom does not end up as black on black. My prom uses fg=255,
You can implement a cg3fb_open() and cg3fb_release() hooks and set up a
use_count field. You increment the count on every open, decrement on every
release. Then restore whatever on the last release. Optionally, you can even
do hardware inits on the first open.
Tony