fbcon woes with closed source framebuffer kernel module

fbcon woes with closed source framebuffer kernel module

[Lior Balkohen]

hi list,

i got an STB with STB04xxx Digital Set-Top Box Integrated Controller
from IBM (it's a 250Mhz embedded powerpc CPU).

the machine runs a 2.6.9 kernel with a closed source framebuffer
kernel module "fb.ko".

I can perform lot of ioctls and mmap the framebuffer device, and
implement a putpixel() to draw something on TV-Output.

but when i compile framebuffer based console driver "fbcon.ko" and the
fonts "font.ko" and load those modules on the box, I DO NOT get a VT
or console login prompt on the TV-output.

what's wrong? or should i implement my own putc, scroll, etc... or
better a terminal for framebuffers like jfbterm, fbiterm???

thanks in advance for any suggestions!


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: fbcon woes with closed source framebuffer kernel module

[Antonino A. Daplas]

Lior Balkohen wrote:
> hi list,
> 
> i got an STB with STB04xxx Digital Set-Top Box Integrated Controller
> from IBM (it's a 250Mhz embedded powerpc CPU).
> 
> the machine runs a 2.6.9 kernel with a closed source framebuffer
> kernel module "fb.ko".
> 
> I can perform lot of ioctls and mmap the framebuffer device, and
> implement a putpixel() to draw something on TV-Output.
> 
> but when i compile framebuffer based console driver "fbcon.ko" and the
> fonts "font.ko" and load those modules on the box, I DO NOT get a VT
> or console login prompt on the TV-output.

Are you sure fbcon is using your framebuffer?  Check lsmod output.
If fbcon is using the driver, and your kernel did not crash, then
that closed source driver is already implementing all the drawing
functions needed by fbcon.

If you don't see any output, then there's a bug somewhere or hopefully
just an incorrect setting.  Check the output of fbset -i and post it here.
An incorrect value in one of the settings can easily lead to a blank
screen.

> 
> what's wrong? or should i implement my own putc, scroll, etc... or

Don't, no use doing this.

> better a terminal for framebuffers like jfbterm, fbiterm???
> 

As a last resort, perhaps.  Why don't you ask IBM?

Tony


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: fbcon woes with closed source framebuffer kernel module

[Lior Balkohen]

>Are you sure fbcon is using your framebuffer?  Check lsmod output.
>If fbcon is using the driver, and your kernel did not crash

telnet 192.168.2.150
Trying 192.168.2.150...
Connected to 192.168.2.150.
Escape character is '^]'.


welcome on your dreambox! - Kernel 2.6.9 (17:49:20).
dreambox login: root
Password:


BusyBox v1.01 (2005.09.08-20:13+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ > cd /tmp
/tmp > ls -l *.ko
-rw-r--r--    1 root     root        39224 Sep 16 17:49 fbcon.ko
-rw-r--r--    1 root     root         9236 Sep 16 17:49 font.ko
/tmp > lsmod
Module                  Size  Used by
usbhid 22016 0 - Live 0xc389e000
head 338412 45 - Live 0xc38c9000
/tmp > insmod ./font.ko
/tmp > insmod ./fbcon.ko
/tmp > lsmod
Module                  Size  Used by
fbcon 31732 65 - Live 0xc391d000
font 7008 1 fbcon, Live 0xc3896000
usbhid 22016 0 - Live 0xc389e000
head 338412 46 - Live 0xc38c9000

head is used 45 times and after loading fbcon, 46 times, so i think,
fbcon is using the driver.

>then that closed source driver is already implementing all the drawing
>functions needed by fbcon.

i don't think so:

nm head.ko | grep pfb
000125bc t pfb_check_var
00003a28 d pfb_default
00000000 t pfb_fix
00012c50 t pfb_pan_display
0001edb0 b pfb_pseudo_palette
00012798 t pfb_set_par
00012af4 t pfb_setcolreg

>Check the output of fbset -i and post it here.

/tmp > ./fbset -i

mode "720x576-171"
    # D: 50.000 MHz, H: 54.825 kHz, V: 170.793 Hz
    geometry 720 576 720 576 8
    timings 20000 64 64 32 32 64 2
    laced true
    rgba 8/16,8/8,8/0,8/24
endmode

Frame buffer device information:
    Name        : Pallas FB
    Address     : 0xa0901000
    Size        : 2093056
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 720
    Accelerator : No

>Why don't you ask IBM?
actually, the driver does not come from ibm, but from dream
multimedia, an stb manufacturer, i asked them, and they said, they
cannot answer any questions about drivers because they have a non
disclosure agreement with ibm. ;-)


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Re: fbcon woes with closed source framebuffer kernel module

[Antonino A. Daplas]

Lior Balkohen wrote:
 > i don't think so:
> 
> nm head.ko | grep pfb
> 000125bc t pfb_check_var
> 00003a28 d pfb_default
> 00000000 t pfb_fix
> 00012c50 t pfb_pan_display
> 0001edb0 b pfb_pseudo_palette
> 00012798 t pfb_set_par
> 00012af4 t pfb_setcolreg


That's okay, it's probably using the generic functions, cfb_imageblit,
cfb_copyarea, and cfb_fillrect. Check lsmod, or grep for imageblit,
copyarea and fillrect.

> 
>> Check the output of fbset -i and post it here.
> 
> /tmp > ./fbset -i
> 
> mode "720x576-171"
>     # D: 50.000 MHz, H: 54.825 kHz, V: 170.793 Hz
>     geometry 720 576 720 576 8
>     timings 20000 64 64 32 32 64 2
>     laced true
>     rgba 8/16,8/8,8/0,8/24
> endmode
> 
> Frame buffer device information:
>     Name        : Pallas FB
>     Address     : 0xa0901000
>     Size        : 2093056
>     Type        : PACKED PIXELS
>     Visual      : PSEUDOCOLOR
>     XPanStep    : 1
>     YPanStep    : 1
>     YWrapStep   : 1
>     LineLength  : 720
>     Accelerator : No
> 

I don't think this is correct.  It describes RGBA8888 as
pseudocolor (indexed palette).  Try doing an fbset -depth 8
and check the fbset -i output again.  

Tony


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Re: fbcon woes with closed source framebuffer kernel module

[Geert Uytterhoeven]

On Mon, 19 Sep 2005, Antonino A. Daplas wrote:
> Lior Balkohen wrote:
> > /tmp > ./fbset -i
> > 
> > mode "720x576-171"
> >     # D: 50.000 MHz, H: 54.825 kHz, V: 170.793 Hz
> >     geometry 720 576 720 576 8
> >     timings 20000 64 64 32 32 64 2
> >     laced true
> >     rgba 8/16,8/8,8/0,8/24
> > endmode
> > 
> > Frame buffer device information:
> >     Name        : Pallas FB
> >     Address     : 0xa0901000
> >     Size        : 2093056
> >     Type        : PACKED PIXELS
> >     Visual      : PSEUDOCOLOR
> >     XPanStep    : 1
> >     YPanStep    : 1
> >     YWrapStep   : 1
> >     LineLength  : 720
> >     Accelerator : No
> 
> I don't think this is correct.  It describes RGBA8888 as
> pseudocolor (indexed palette).  Try doing an fbset -depth 8
> and check the fbset -i output again.  

But the depth is already 8. And this matches with the LineLength and
xres_virtual.

Probably only the rgba bitfields are incorrect.

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


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Re: fbcon woes with closed source framebuffer kernel module

[Antonino A. Daplas]

Geert Uytterhoeven wrote:
> On Mon, 19 Sep 2005, Antonino A. Daplas wrote:
>> Lior Balkohen wrote:
>>> /tmp > ./fbset -i
>>>
>>> mode "720x576-171"
>>>     # D: 50.000 MHz, H: 54.825 kHz, V: 170.793 Hz
>>>     geometry 720 576 720 576 8
>>>     timings 20000 64 64 32 32 64 2
>>>     laced true
>>>     rgba 8/16,8/8,8/0,8/24
>>> endmode
>>>
>>> Frame buffer device information:
>>>     Name        : Pallas FB
>>>     Address     : 0xa0901000
>>>     Size        : 2093056
>>>     Type        : PACKED PIXELS
>>>     Visual      : PSEUDOCOLOR
>>>     XPanStep    : 1
>>>     YPanStep    : 1
>>>     YWrapStep   : 1
>>>     LineLength  : 720
>>>     Accelerator : No
>> I don't think this is correct.  It describes RGBA8888 as
>> pseudocolor (indexed palette).  Try doing an fbset -depth 8
>> and check the fbset -i output again.  
> 
> But the depth is already 8. And this matches with the LineLength and
> xres_virtual.
> 
> Probably only the rgba bitfields are incorrect.

Yes, but in pseudocolor, the pseudo_palette is not read, so what is
being written to the fb memory are colors 0-15 (which in 32-bit
truecolor will be very light blue on black. This is easy to mistake
as a blank screen).

Tony


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php