Re: fb_imageblit semantic

Re: fb_imageblit semantic

[Petr Vandrovec]

On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> 
> That depends... How do we draw the monochrome penguin? Using image->depth is 1
> or 8? The latter (current method) is slower, since we need to expand the
> monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> driver afterwards.

As far as I can see, it gets monochromatic logo and converts it to
8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
converts it back to 1bpp.
 
> And perhaps we may want to draw 32-bit ARGB images later?
> 
> So I see the following possible valid values for image->depth:
>   - 8 (logo with up to 256 colors and LUT)
>   - optional 1 (monochrome logo, if we don't want to expand?)
>   - optional 32 (ARGB image, dithering left to the driver?)

I still do not understand 'if we don't want to expand'. This forces too
much knowledge on upper layer, as far as I can tell.
                                                    Petr Vandrovec
                                                    



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: fb_imageblit semantic

[Geert Uytterhoeven]

On Mon, 17 Mar 2003, Petr Vandrovec wrote:
> On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> > That depends... How do we draw the monochrome penguin? Using image->depth is 1
> > or 8? The latter (current method) is slower, since we need to expand the
> > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> > driver afterwards.
> 
> As far as I can see, it gets monochromatic logo and converts it to
> 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
> converts it back to 1bpp.

Yes, that's what I wrote above (current method).

> > And perhaps we may want to draw 32-bit ARGB images later?
> > 
> > So I see the following possible valid values for image->depth:
> >   - 8 (logo with up to 256 colors and LUT)
> >   - optional 1 (monochrome logo, if we don't want to expand?)
> >   - optional 32 (ARGB image, dithering left to the driver?)
> 
> I still do not understand 'if we don't want to expand'. This forces too
> much knowledge on upper layer, as far as I can tell.

Color expansion => use fb_image.fg_color if bit == 1,
		   use fb_image.bg_color if bit == 0
No expansion => look up color in fb_image.cmap.

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:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: fb_imageblit semantic

[Antonino Daplas]

On Mon, 2003-03-17 at 20:25, Petr Vandrovec wrote:
> On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> > 
> > That depends... How do we draw the monochrome penguin? Using image->depth is 1
> > or 8? The latter (current method) is slower, since we need to expand the
> > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> > driver afterwards.
> 
> As far as I can see, it gets monochromatic logo and converts it to
> 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
> converts it back to 1bpp.
>  

Yes.  That's the sacrifice for simplicity and consistency, low color
depths sacrifice on speed, high color depth sacrifice on color range. 
The real beneficiary is 8-bit pseudo-pixel.

Of course, there's always a choice:

1.  allow support for non-monochrome expansion/reduction in
cfb_imageblit(), ie input data is 4bpp and framebuffer format is 16 bpp,
directcolor.

2.  prepare all logo so image->depth matches framebuffer depth.  This
will require  that fb_prepare_logo() has additional code to pack
image->data properly

3.  Just add conditionals like:

if depth == 1
	logo->data == logo_bw
else if depth == 4
	logo->data == logo_4
else if depth == 8
	logo->data == logo_8
else
	prepare_logo_to_match_fb_depth

For #2 and #3, what do we do when var->bits_per_pixel > 8?  Do we still
use image->depth=8? Do we still use the LUT?  

4.  Go back to the 2.4 way of drawing the logo, let the upper layer do
everything, and just directly memcopy the data to the framebuffer.

> > And perhaps we may want to draw 32-bit ARGB images later?
> > 
> > So I see the following possible valid values for image->depth:
> >   - 8 (logo with up to 256 colors and LUT)
> >   - optional 1 (monochrome logo, if we don't want to expand?)
> >   - optional 32 (ARGB image, dithering left to the driver?)
> 
> I still do not understand 'if we don't want to expand'. This forces too
> much knowledge on upper layer, as far as I can tell.

I agree.

Tony




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: fb_imageblit semantic

[Geert Uytterhoeven]

On 17 Mar 2003, Antonino Daplas wrote:
> On Mon, 2003-03-17 at 20:25, Petr Vandrovec wrote:
> > On 17 Mar 03 at 13:18, Geert Uytterhoeven wrote:
> > > 
> > > That depends... How do we draw the monochrome penguin? Using image->depth is 1
> > > or 8? The latter (current method) is slower, since we need to expand the
> > > monochrome logo to 8-bit first, and (usually) compress it to 1-bit in the fbdev
> > > driver afterwards.
> > 
> > As far as I can see, it gets monochromatic logo and converts it to
> > 8bpp format ;-) (fb_set_logo, needs_logo = 1 or ~1) And then imageblit
> > converts it back to 1bpp.
> 
> Yes.  That's the sacrifice for simplicity and consistency, low color
> depths sacrifice on speed, high color depth sacrifice on color range. 
> The real beneficiary is 8-bit pseudo-pixel.

Indeed.

> Of course, there's always a choice:
> 
> 1.  allow support for non-monochrome expansion/reduction in
> cfb_imageblit(), ie input data is 4bpp and framebuffer format is 16 bpp,
> directcolor.
> 
> 2.  prepare all logo so image->depth matches framebuffer depth.  This
> will require  that fb_prepare_logo() has additional code to pack
> image->data properly

This moves code from the low-level driver to the high-level, and thus reduces
code duplication.

The disadvantage is that the conversion may be a waste of work, if the
resulting image data is not in the same format as the hardware uses (e.g. for
bitplanes).

> 3.  Just add conditionals like:
> 
> if depth == 1
> 	logo->data == logo_bw
> else if depth == 4
> 	logo->data == logo_4
> else if depth == 8
> 	logo->data == logo_8
> else
> 	prepare_logo_to_match_fb_depth

Don't forget about other depths. And the number of logo colors does not depend
on the color depth only, for visuals different from pseudocolor.

> For #2 and #3, what do we do when var->bits_per_pixel > 8?  Do we still
> use image->depth=8?

IMHO always using an image depth of 8 is fine. That's a nice trade off between
genericity and easy access of image data.

Except for monochrome, there I prefer a depth of 1, since doing 1->8 and 8->1
in a row is a bit too wasteful.

BTW, I just realized there's no need to distinguish between monochrome copy and
monochrome-to-color expansion. The monochrome logo code just has to write the
correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).

> Do we still use the LUT?  

Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there
are enough number of colors). But since imageblit is done for the logo only,
doing the transform from LUT index to pixel value in imageblit is OK, I think.

> 4.  Go back to the 2.4 way of drawing the logo, let the upper layer do
> everything, and just directly memcopy the data to the framebuffer.

Ugh... This is much worse, since the logo drawing code has to know about all
possible frame buffer formats. In the current scheme, this is nicely hidden in
imageblit.

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:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: fb_imageblit semantic

[Antonino Daplas]

On Mon, 2003-03-17 at 21:47, Geert Uytterhoeven wrote:
>
> IMHO always using an image depth of 8 is fine. That's a nice trade off between
> genericity and easy access of image data.
> 
> Except for monochrome, there I prefer a depth of 1, since doing 1->8 and 8->1
> in a row is a bit too wasteful.
> 

An exception to the rule :-)  Well, I guess if it will significantly
benefit monochrome drivers...

> BTW, I just realized there's no need to distinguish between monochrome copy and
> monochrome-to-color expansion. The monochrome logo code just has to write the
> correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
> bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).
> 

I remember mentioning this to you before, and you said that there might
be rare cases that fgcolor can be equal to bgcolor.  However, using -1
instead for bg_color/fg_color may work, at least for the current setup
and only for monochrome, (except perhaps 32-bit monochrome, if there is
such a thing)

I still prefer splitting fb_imageblit() into two though, and still keep
image->depth for logo drawing only, to allow for future expansion.
. 
> > Do we still use the LUT?  
> 
> Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there

Yes.  Which also means logo drawing will also work for quirky drivers,
and the upper layer will be finally totally independent of the low level
drivers.

> are enough number of colors). But since imageblit is done for the logo only,
> doing the transform from LUT index to pixel value in imageblit is OK, I think.
> 

Yes, I also prefer referring to the LUT whatever the format even for
character drawing.  I don't expect any noticeable performance penalty
except for logo drawing.  The way it's currently done is because,
looking at all drivers, not one fills up the pseudo_palette when bpp <=
8.

Tony



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: fb_imageblit semantic

[Geert Uytterhoeven]

On 17 Mar 2003, Antonino Daplas wrote:
> On Mon, 2003-03-17 at 21:47, Geert Uytterhoeven wrote:
> > BTW, I just realized there's no need to distinguish between monochrome copy and
> > monochrome-to-color expansion. The monochrome logo code just has to write the
> > correct values to fb_image.[fb]gcolor. I.e. all zeroes or all ones (number of
> > bits = var.bits_per_pixel, so it works for 8-bit monochrome, too).
> > 
> 
> I remember mentioning this to you before, and you said that there might
> be rare cases that fgcolor can be equal to bgcolor.  However, using -1
> instead for bg_color/fg_color may work, at least for the current setup
> and only for monochrome, (except perhaps 32-bit monochrome, if there is
> such a thing)

No, you wanted to distinguish between monochrome expansion and color copy by
setting fb_image.[fb]gcolor to -1.

> I still prefer splitting fb_imageblit() into two though, and still keep
> image->depth for logo drawing only, to allow for future expansion.

OK.

> > > Do we still use the LUT?  
> > 
> > Yes. An alternative is to enlarge the pseudo palette to 256 entries (if there
> 
> Yes.  Which also means logo drawing will also work for quirky drivers,
> and the upper layer will be finally totally independent of the low level
> drivers.
> 
> > are enough number of colors). But since imageblit is done for the logo only,
> > doing the transform from LUT index to pixel value in imageblit is OK, I think.
> > 
> 
> Yes, I also prefer referring to the LUT whatever the format even for
> character drawing.  I don't expect any noticeable performance penalty
> except for logo drawing.  The way it's currently done is because,
> looking at all drivers, not one fills up the pseudo_palette when bpp <=
> 8.

There are some, that have RGB332 truecolor.

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:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Detecting if the mode can be changed?

[Kendall Bennett]

Hi Guys,

I am working on implementing code to use the framebuffer console, and I 
want to know in advance of calling FBIOPUT_VSCREENINFO if the screen 
resolution and color depth can actually be changed at runtime or not. If 
the VESA driver is running, this ioctl() displays an error message on the 
screen, and I want to avoid this error message by knowing in advance if 
the ioctl() will work or not.

Is there a flag or way to determine this?

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Enumerating available display modes?

[Kendall Bennett]

Hi Again,

In working with the framebuffer console interface, it does not appear to 
support enumerating what display modes are available to be set via the 
/dev/fb interface. Am I right in thinking this, or am I missing something 
in the API? I am going to take a look at the source code, but some high 
level programming information would be well received at this end ;-)

Also I can't seem to find any code related to acceleration via /dev/fb. 
Is this not possible for user land apps to call the acceleration 
functions in /dev/fb? I guess I can check the XFree86 module to see how 
it does it....

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Enumerating available display modes?

[Kendall Bennett]

Jon Smirl <jonsmirl@yahoo.com> wrote:

> I just scanned a couple of the fbdrivers and there seems to be no
> way to enumerate the modes that the hardware can support. This
> feature is probably lacking since there was no real use for it
> without the DDC monitor info. 

Well without the DDC monitor info you cannot ensure that modes the 
hardware can support will work on the attached monitor, but it is better 
than now knowing what modes are available anyway. As it stands right now, 
apps can simply call into the driver and 'try' to set any more that might 
be supported, but good luck knowing if it will or if the monitor can 
handle it.

Also IMHO it is not a good idea to expect apps to pass down the CRTC and 
pixel clock timings for the graphics card. It is nice to have this 
programmable interface, but user land apps really just want to set a mode 
and not have to deal with that stuff. Rarely they even care about the 
refresh rate (just use a good one for the attached monitor).

> The fb modes are controlled via /etc/fb.modes 

How do you mean they are controlled by /etc/fb.modes?

> On the other hand, the X windows drivers know how to enumerate the
> hardware supported modes. Just look at your XFree log and you can
> see a list of card supported modes vs monitor supported modes, and
> finally the pairs that match. 

Yes, I am aware that XFree86 drivers can do this.

> The solution is to go lift the appropriate code out of the X
> windows drivers and add it to the fb ones. 

Actually IMHO a better solution is the vesafbd project, since it would 
allow framebuffer console drivers to be developed in user land, and could 
then use the existing XFree86 driver modules without having to 'port' 
them to the Linux kernel. Also with the vesafbd project it will be 
possible to add support for reading the complete EDID from the monitor 
using the VESA BIOS functions, so that the vesa framebuffer console 
driver *could* know about the attached monitor and filter the available 
modes that the VESA BIOS supports for the user applications.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en