Hi!
I've got some trouble getting a local FB console to work, maybe you've
got some suggestions...
This all happens on a VAX 4000 Model 46. I've already done the FB driver
(http://cvs.sourceforge.net/viewcvs.py/linux-vax/kernel-2.5/drivers/video/vaxlcgfb.c)
which basically works - cat'ting a properly prepared image to it
produces a proper display output.
Now I tried to bring CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE into the
game. However, I end up with no working FB console. No penguin image, no
login prompt. This is because vc->vc_bottom ends up being 0, while it
should be at around 60.
Adding some printk()s and initcall_debug, here is what happens:
tty_class_init()
chr_dev_init()
vaxlcgfb_init()
tty_init()
vty_init()
fb_console_init()
"fbcon_startup: mode: VAX LCGfb"
"fbcon_startup: visual: 3"
"fbcon_startup: res: 1280x1024-8"
"Console: switching to frame buffer device"
pty_init()
fb_console_init()
"Console: switching to frame buffer device"
...
vc_init():
currcons=0, rows=64, cols=160, clear=1
then colors 0..15 are set
Two things look odd to me:
- fb_console_init is called twice. Once from
tty_init() -> vty_init() -> fb_console_init(), second time
directly as a "normal" __init / module_init() call.
- Despite the fact that (quite late in the boot process)
vc_init() is called (with correct looking arguments), I think
it should have been called quite some time earlier. With other
(PC based) graphic cards, the machine just switches to FB mode
after the FB driver is initialized. All further output is put
there. But not here...
I haven't yet really understood how FB and console code work together,
so it would be nice to have some hints there :)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Now I tried to bring CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE into the
game. However, I end up with no working FB console. No penguin image, no
login prompt. This is because vc->vc_bottom ends up being 0, while it
should be at around 60.
Wow. Nasty bug.
Adding some printk()s and initcall_debug, here is what happens:
tty_class_init()
chr_dev_init()
vaxlcgfb_init()
tty_init()
vty_init()
fb_console_init()
"fbcon_startup: mode: VAX LCGfb"
"fbcon_startup: visual: 3"
"fbcon_startup: res: 1280x1024-8"
"Console: switching to frame buffer device"
pty_init()
fb_console_init()
"Console: switching to frame buffer device"
...
vc_init():
currcons=0, rows=64, cols=160, clear=1
then colors 0..15 are set
Two things look odd to me:
- fb_console_init is called twice. Once from
tty_init() -> vty_init() -> fb_console_init(), second time
directly as a "normal" __init / module_init() call.
That is a bug. I have a patch to fix that.
- Despite the fact that (quite late in the boot process)
vc_init() is called (with correct looking arguments), I think
it should have been called quite some time earlier. With other
(PC based) graphic cards, the machine just switches to FB mode
after the FB driver is initialized. All further output is put
there. But not here...
I haven't yet really understood how FB and console code work together,
so it would be nice to have some hints there :)
I'm going to have to look at your driver. Normally one of two things
happen. Some driver have there hardware modes set by firmware and they
can't be changed. For example VESA fbdev. In this case you lack a
xxxfb_check_var and xxxfb_set_par function. Then fbcon doesn't attempt to
change the hardware state but use the current one.
The other case is that your driver sets the hardware state. You have a
set_check_var and a set_par function hook in struct fb_info->fbops. So the
fbcon layer will call set_par directly for you.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
On Wed, 2004-03-10 18:15:57 +0000, James Simmons [off-list ref]
wrote in message [off-list ref]:
quoted
- Despite the fact that (quite late in the boot process)
vc_init() is called (with correct looking arguments), I think
it should have been called quite some time earlier. With other
(PC based) graphic cards, the machine just switches to FB mode
after the FB driver is initialized. All further output is put
there. But not here...
I haven't yet really understood how FB and console code work together,
so it would be nice to have some hints there :)
In the meantime, another VAX hacker (who initially worked on the 2.4.x
code base) hinted me: in the arch_setup function, I was missing a
conswitchp = &dummy_con;
After adding these, I got a penguin and a login prompt. However, the
console output (during further boot-up) didn't show up. But I'll get
there:)
I'm going to have to look at your driver. Normally one of two things
happen. Some driver have there hardware modes set by firmware and they
can't be changed. For example VESA fbdev. In this case you lack a
xxxfb_check_var and xxxfb_set_par function. Then fbcon doesn't attempt to
change the hardware state but use the current one.
The other case is that your driver sets the hardware state. You have a
set_check_var and a set_par function hook in struct fb_info->fbops. So the
fbcon layer will call set_par directly for you.
Well, as I know today, there are more variants of this hardware, some of
them capable of changing screen resolution. So I think I'd add those two
functions (after I figured out how to actually change modes, or even how
to properly detect the available hardware at all:)
Thanks for these valuable hints! Oh, just another question: the largest
of theses framebuffer devices can handle four CRTs. Just need to
register four framebuffers, then?
After all, I've had my very first local login last night, at 00:42:23
CET with local monitor and keyboard on a VAX. Right, I waited some
seconds to get that nice time on my watch:)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Wed, 2004-03-10 18:15:57 +0000, James Simmons [off-list ref]
wrote in message [off-list ref]:
quoted
quoted
- Despite the fact that (quite late in the boot process)
vc_init() is called (with correct looking arguments), I think
it should have been called quite some time earlier. With other
(PC based) graphic cards, the machine just switches to FB mode
after the FB driver is initialized. All further output is put
there. But not here...
I haven't yet really understood how FB and console code work together,
so it would be nice to have some hints there :)
In the meantime, another VAX hacker (who initially worked on the 2.4.x
code base) hinted me: in the arch_setup function, I was missing a
conswitchp = &dummy_con;
Yep, you need that, since fb is initialized later than the console (requested
by people with vgacon hardware).
After adding these, I got a penguin and a login prompt. However, the
console output (during further boot-up) didn't show up. But I'll get
there:)
CONFIG_FRAMEBUFFER_CONSOLE=y?
Thanks for these valuable hints! Oh, just another question: the largest
of theses framebuffer devices can handle four CRTs. Just need to
register four framebuffers, then?
Indeed.
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
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click