linuxconsole-dev

Questions on new framebuffer API:

[Antonino D. <ad...@po...>]

Hi,

I just downloaded the ruby tree and tried it.  It compiles without
errors and the sytem boots okay.  It seems that tty0 was used only for
"printk" console dumps since I wasn't able to see a login prompt
afterwards.  I was able to switch to tty1 and login from there.  Is this
"normal" for the  current snapshot?

Secondly, is the new framebuffer API already workable?  I looked at some
of the specific driver codes and a few have already been ported
(aty128fb, pm3fb, vga16fb, etc).  I tried vga16fb (only one that works
for the i810 chipset), it fails to compile with "undefined reference to
spinlock_init" although changing "spinlock_init" to "spin_lock_init" in
vga16fb.c seems to correct the error (not sure if this is the correct
way to do this).  I enabled "framebuffer console support" in the kernel
config and rebooted.  I just got a blank/corrupted screen though, and
the machine never finished the booting and locks up at the end.  Never
got to log any debugging messages to a file.  

I'm asking the above since while trying to write an i810 driver for the
new API, I met the same problem as with the vga16fb.  The "check_var"
and "set_var" fb_ops seem to work since I was able to properly set the
video mode using those functions during a test.  I was able to directly
write to info->screen_base and correctly display the pixel data. I was
also able to use cfb_rectfill to display a 64x64 pixel square.

Anything I might have missed or anything I need to examine more
closely?  

Thanks.

Tony

Re: Questions on new framebuffer API:

[James S. <jsi...@tr...>]

> I just downloaded the ruby tree and tried it.  It compiles without
> errors and the sytem boots okay.  It seems that tty0 was used only for
> "printk" console dumps since I wasn't able to see a login prompt
> afterwards.  I was able to switch to tty1 and login from there.  Is this
> "normal" for the  current snapshot?

Yes. The standard tree is not multidesktop aware. So their is only one
foreground VC even when you have multiple heads. tty0 is always teh
foreground VC. Now in ruby it doesn't make sense to have /dev/tty0 as the
foreground console since their can be more than one of them. So instead
tty0 to tty15 goes to VT one and tty16 to tty31 goes to VT 2 etc. BTW
their is no such a thing at tty0 as the foreground VC on SYSV UNIXs. So
linux is broken in this way.

To have a terminal on tty0 just add to /etc/inittab

1:2345:respawn:/sbin/mingetty tty0

and increment the numbers of the VCs that follow. Note for the standard
tree if you have this in your inittab the console will behave strangely.
 
> Secondly, is the new framebuffer API already workable?  

Yes. It is pretty stable. The upper console stuff needs some work.

> (aty128fb, pm3fb, vga16fb, etc).  I tried vga16fb (only one that works
> for the i810 chipset), it fails to compile with "undefined reference to
> spinlock_init" although changing "spinlock_init" to "spin_lock_init" in
> vga16fb.c seems to correct the error (not sure if this is the correct
> way to do this).  

Oops. I haven't worked on that in some time.

> I enabled "framebuffer console support" in the kernel
> config and rebooted.  I just got a blank/corrupted screen though, and
> the machine never finished the booting and locks up at the end.  Never
> got to log any debugging messages to a file. 

The rectfill, copyarea and image functions are broke for that driver. I
never got around to fixing. I will shortly.
 
> I'm asking the above since while trying to write an i810 driver for the
> new API, I met the same problem as with the vga16fb.  The "check_var"
> and "set_var" fb_ops seem to work since I was able to properly set the
> video mode using those functions during a test.  I was able to directly
> write to info->screen_base and correctly display the pixel data. I was
> also able to use cfb_rectfill to display a 64x64 pixel square.
> 
> Anything I might have missed or anything I need to examine more
> closely?  

Nope. The vga16fb driver needs some work. I will get to it. I just need a 
rectfill, cooparea, and imageblit function for that driver.

Re: [Linux-fbdev-devel] Re: Questions on new framebuffer API:

[Rogelio M. S. Jr. <ro...@vi...>]

I have also been trying to use the new patch but my video card seems to be
unsupported. I have a rage 128 pro ultra tf. Is it enough to modify the 
aty128_pci_probe_list?

On Fri, 30 Nov 2001, James Simmons wrote:

> 
> > I just downloaded the ruby tree and tried it.  It compiles without
> > errors and the sytem boots okay.  It seems that tty0 was used only for
> > "printk" console dumps since I wasn't able to see a login prompt
> > afterwards.  I was able to switch to tty1 and login from there.  Is this
> > "normal" for the  current snapshot?
> 
> Yes. The standard tree is not multidesktop aware. So their is only one
> foreground VC even when you have multiple heads. tty0 is always teh
> foreground VC. Now in ruby it doesn't make sense to have /dev/tty0 as the
> foreground console since their can be more than one of them. So instead
> tty0 to tty15 goes to VT one and tty16 to tty31 goes to VT 2 etc. BTW
> their is no such a thing at tty0 as the foreground VC on SYSV UNIXs. So
> linux is broken in this way.
> 
> To have a terminal on tty0 just add to /etc/inittab
> 
> 1:2345:respawn:/sbin/mingetty tty0
> 
> and increment the numbers of the VCs that follow. Note for the standard
> tree if you have this in your inittab the console will behave strangely.
>  
> > Secondly, is the new framebuffer API already workable?  
> 
> Yes. It is pretty stable. The upper console stuff needs some work.
> 
> > (aty128fb, pm3fb, vga16fb, etc).  I tried vga16fb (only one that works
> > for the i810 chipset), it fails to compile with "undefined reference to
> > spinlock_init" although changing "spinlock_init" to "spin_lock_init" in
> > vga16fb.c seems to correct the error (not sure if this is the correct
> > way to do this).  
> 
> Oops. I haven't worked on that in some time.
> 
> > I enabled "framebuffer console support" in the kernel
> > config and rebooted.  I just got a blank/corrupted screen though, and
> > the machine never finished the booting and locks up at the end.  Never
> > got to log any debugging messages to a file. 
> 
> The rectfill, copyarea and image functions are broke for that driver. I
> never got around to fixing. I will shortly.
>  
> > I'm asking the above since while trying to write an i810 driver for the
> > new API, I met the same problem as with the vga16fb.  The "check_var"
> > and "set_var" fb_ops seem to work since I was able to properly set the
> > video mode using those functions during a test.  I was able to directly
> > write to info->screen_base and correctly display the pixel data. I was
> > also able to use cfb_rectfill to display a 64x64 pixel square.
> > 
> > Anything I might have missed or anything I need to examine more
> > closely?  
> 
> Nope. The vga16fb driver needs some work. I will get to it. I just need a 
> rectfill, cooparea, and imageblit function for that driver.
> 
> 
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 
> 

Re: [Linux-fbdev-devel] Re: Questions on new framebuffer API:

[James S. <jsi...@tr...>]

> I have also been trying to use the new patch but my video card seems to be
> unsupported. I have a rage 128 pro ultra tf. Is it enough to modify the 
> aty128_pci_probe_list?

Yes. Can you post the results of lspci -vvv.