Framebuffers and VC setup (via fbcon.c)

Framebuffers and VC setup (via fbcon.c)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Framebuffers and VC setup (via fbcon.c)

[James Simmons]

> 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.

Wow really cool.
 
> 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

Re: Framebuffers and VC setup (via fbcon.c)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]

On Wed, 2004-03-10 18:15:57 +0000, James Simmons <jsimmons@infradead.org>
wrote in message <Pine.LNX.4.44.0403101806460.24760-100000@phoenix.infradead.org>:
> > 	- 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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Framebuffers and VC setup (via fbcon.c)

[Geert Uytterhoeven]

On Wed, 10 Mar 2004, Jan-Benedict Glaw wrote:
> On Wed, 2004-03-10 18:15:57 +0000, James Simmons <jsimmons@infradead.org>
> wrote in message <Pine.LNX.4.44.0403101806460.24760-100000@phoenix.infradead.org>:
> > > 	- 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