Thread (6 messages) 6 messages, 3 authors, 2005-09-19

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

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: 2005-09-19 09:56:00

Geert Uytterhoeven wrote:
On Mon, 19 Sep 2005, Antonino A. Daplas wrote:
quoted
Lior Balkohen wrote:
quoted
/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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help