Re: fb_imageblit semantic

Re: fb_imageblit semantic

[Petr Vandrovec]

On 14 Mar 03 at 10:22, Geert Uytterhoeven wrote:
> On Thu, 13 Mar 2003, Petr Vandrovec wrote:
> > Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> > when logo image is in reality always 8bpp, as quick look at 
> > cfb_imageblit revealed?
> 
> Should indeed be 8.
> 
> > Should I just assume that image.depth == 1 means that data are
> > 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> > input?
> 
> This was changed from 1 to 0 in James' latest tree.

WTF? Color depth 0 means that whole picture is single-color, and
imageblit degenerates to rectfill in such case. Please, either
use 'depth' as source image color depth, or do not name it depth.
                                                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 Fri, 14 Mar 2003, Petr Vandrovec wrote:
> On 14 Mar 03 at 10:22, Geert Uytterhoeven wrote:
> > On Thu, 13 Mar 2003, Petr Vandrovec wrote:
> > > Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> > > when logo image is in reality always 8bpp, as quick look at 
> > > cfb_imageblit revealed?
> > 
> > Should indeed be 8.
> > 
> > > Should I just assume that image.depth == 1 means that data are
> > > 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> > > input?
> > 
> > This was changed from 1 to 0 in James' latest tree.
> 
> WTF? Color depth 0 means that whole picture is single-color, and
> imageblit degenerates to rectfill in such case. Please, either
> use 'depth' as source image color depth, or do not name it depth.

It's 0 (expand [bf]gcol) to differentiate from 1 (copy monochrome).

Splitting imageblit into separate routines for both operations would be
trivial, though.

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

[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

Re: fb_imageblit semantic

[Petr Vandrovec]

On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
> On 17 Mar 2003, Antonino Daplas wrote:
> > As Geert said, it's not just trivial, but logical to split fb_imageblit
> > into two.
> 
> So, are we gonna split it? This will also make hardware acceleration support
> more clean. E.g. most sbus drivers do color expansion in hardware, and fall
> back to cfb_imageblit() for the logo.
> 
> > > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> > > while if depth != 0, then palette is in info->pseudo_palette ?
> > 
> > Yes.  You can also say that if image->depth != var->bits_per_pixel, do
> > color expansion or reduction, whatever the case may be.
> 
> Hmmm... Note that image->depth can be larger than 8, while the image data is
> still 8-bit. This is an inconsistency.

image->depth for logo must change to 8. Or remove depth completely after
splitting imageblit to paintchar & paintlogo, as currently depth is
useless anyway: target format is defined by framebuffer layout, not
by image->depth, and source format is hardwired to the code.
                                                        Petr Vandrovec
                                                        vandrove@vc.cvut.cz



-------------------------------------------------------
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 18:40, Petr Vandrovec wrote:
> On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
> > On 17 Mar 2003, Antonino Daplas wrote:
> > > As Geert said, it's not just trivial, but logical to split fb_imageblit
> > > into two.
> > 
> > So, are we gonna split it? This will also make hardware acceleration support
> > more clean. E.g. most sbus drivers do color expansion in hardware, and fall
> > back to cfb_imageblit() for the logo.
> > 

It's up to James, though I vote for it.  And I don't think any driver
has accelerated versions of fb_imageblit for the logo, since any
performance gained is probably minimal and it will involve too much work
for something that's going to be done only once.
  
> > > > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> > > > while if depth != 0, then palette is in info->pseudo_palette ?
> > > 
> > > Yes.  You can also say that if image->depth != var->bits_per_pixel, do
> > > color expansion or reduction, whatever the case may be.
> > 
> > Hmmm... Note that image->depth can be larger than 8, while the image data is
> > still 8-bit. This is an inconsistency.

I was thinking that if image->depth=8 and var->bits_per_pixel=4, then
the driver is in danger of going out of bounds when referring to the
pseudo_palette.  But I forgot that the fb_show_logo() takes care of
avoiding that :-)  And yes, current usage of image->depth is pretty
inconsistent and basically useless.

> 
> image->depth for logo must change to 8. Or remove depth completely after
> splitting imageblit to paintchar & paintlogo, as currently depth is
> useless anyway: target format is defined by framebuffer layout, not
> by image->depth, and source format is hardwired to the code.

You're correct.  If it's going to be split, image->depth becomes
redundant.

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 18:40, Petr Vandrovec wrote:
> > On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
> > > On 17 Mar 2003, Antonino Daplas wrote:
> > > > As Geert said, it's not just trivial, but logical to split fb_imageblit
> > > > into two.
> > > 
> > > So, are we gonna split it? This will also make hardware acceleration support
> > > more clean. E.g. most sbus drivers do color expansion in hardware, and fall
> > > back to cfb_imageblit() for the logo.
> 
> It's up to James, though I vote for it.  And I don't think any driver
> has accelerated versions of fb_imageblit for the logo, since any
> performance gained is probably minimal and it will involve too much work
> for something that's going to be done only once.

Wait until someone wants 256-color fonts ;-)

> > > > > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> > > > > while if depth != 0, then palette is in info->pseudo_palette ?
> > > > 
> > > > Yes.  You can also say that if image->depth != var->bits_per_pixel, do
> > > > color expansion or reduction, whatever the case may be.
> > > 
> > > Hmmm... Note that image->depth can be larger than 8, while the image data is
> > > still 8-bit. This is an inconsistency.
> 
> I was thinking that if image->depth=8 and var->bits_per_pixel=4, then
> the driver is in danger of going out of bounds when referring to the
> pseudo_palette.  But I forgot that the fb_show_logo() takes care of
> avoiding that :-)  And yes, current usage of image->depth is pretty
> inconsistent and basically useless.
> 
> > image->depth for logo must change to 8. Or remove depth completely after
> > splitting imageblit to paintchar & paintlogo, as currently depth is
> > useless anyway: target format is defined by framebuffer layout, not
> > by image->depth, and source format is hardwired to the code.
> 
> You're correct.  If it's going to be split, image->depth becomes
> redundant.

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.

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

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:18, Geert Uytterhoeven wrote:
> On 17 Mar 2003, Antonino Daplas wrote:
> > On Mon, 2003-03-17 at 18:40, Petr Vandrovec wrote:
> > > On 17 Mar 03 at 11:31, Geert Uytterhoeven wrote:
> > > > On 17 Mar 2003, Antonino Daplas wrote:
> > > > > As Geert said, it's not just trivial, but logical to split fb_imageblit
> > > > > into two.
> > > > 
> > > > So, are we gonna split it? This will also make hardware acceleration support
> > > > more clean. E.g. most sbus drivers do color expansion in hardware, and fall
> > > > back to cfb_imageblit() for the logo.
> > 
> > It's up to James, though I vote for it.  And I don't think any driver
> > has accelerated versions of fb_imageblit for the logo, since any
> > performance gained is probably minimal and it will involve too much work
> > for something that's going to be done only once.
> 
> Wait until someone wants 256-color fonts ;-)

When we do get that to that point, the entire interface will be
revamped.  Imagine passing 128 bytes to draw a single character.  This
is where Tile Blitting comes in.

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

[Petr Vandrovec]

On 14 Mar 03 at 11:40, Geert Uytterhoeven wrote:
> On Fri, 14 Mar 2003, Petr Vandrovec wrote:
> > On 14 Mar 03 at 10:22, Geert Uytterhoeven wrote:
> > > On Thu, 13 Mar 2003, Petr Vandrovec wrote:
> > > > Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> > > > when logo image is in reality always 8bpp, as quick look at 
> > > > cfb_imageblit revealed?
> > > 
> > > Should indeed be 8.
> > > 
> > > > Should I just assume that image.depth == 1 means that data are
> > > > 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> > > > input?
> > > 
> > > This was changed from 1 to 0 in James' latest tree.
> > 
> > WTF? Color depth 0 means that whole picture is single-color, and
> > imageblit degenerates to rectfill in such case. Please, either
> > use 'depth' as source image color depth, or do not name it depth.
> 
> It's 0 (expand [bf]gcol) to differentiate from 1 (copy monochrome).
> 
> Splitting imageblit into separate routines for both operations would be
> trivial, though.

There is no such thing as copy monochrome if target is not monochrome,
you have to put palette somewhere. If you'll look at cfb_imageblit,
you'll find that there is already defined way to do that: code uses
artifically created 256 entry pseudopalette... If target is monochrome,
it just copies data. If target is not monochrome, it has somehow expand
data to fit to screen format. Nothing differs between font painting
and copying 1bpp bitmap to Xbpp display. 

OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
while if depth != 0, then palette is in info->pseudo_palette ?
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                



-------------------------------------------------------
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 Fri, 2003-03-14 at 18:52, Petr Vandrovec wrote:
> On 14 Mar 03 at 11:40, Geert Uytterhoeven wrote:
> > On Fri, 14 Mar 2003, Petr Vandrovec wrote:
> > > On 14 Mar 03 at 10:22, Geert Uytterhoeven wrote:
> > > > On Thu, 13 Mar 2003, Petr Vandrovec wrote:
> > > > > Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> > > > > when logo image is in reality always 8bpp, as quick look at 
> > > > > cfb_imageblit revealed?
> > > > 
> > > > Should indeed be 8.
> > > > 
> > > > > Should I just assume that image.depth == 1 means that data are
> > > > > 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> > > > > input?
> > > > 
> > > > This was changed from 1 to 0 in James' latest tree.
> > > 
> > > WTF? Color depth 0 means that whole picture is single-color, and
> > > imageblit degenerates to rectfill in such case. Please, either
> > > use 'depth' as source image color depth, or do not name it depth.
> > 
> > It's 0 (expand [bf]gcol) to differentiate from 1 (copy monochrome).
> > 
> > Splitting imageblit into separate routines for both operations would be
> > trivial, though.
> 
> There is no such thing as copy monochrome if target is not monochrome,
> you have to put palette somewhere. If you'll look at cfb_imageblit,
> you'll find that there is already defined way to do that: code uses
> artifically created 256 entry pseudopalette... If target is monochrome,
> it just copies data. If target is not monochrome, it has somehow expand
> data to fit to screen format. Nothing differs between font painting
> and copying 1bpp bitmap to Xbpp display. 
> 

It's mainly code consistency and simplicity.

1.  character painting - monochrome input with color in fg_color and
bg_color

2.  logo drawing -  array of 8-bit color indices which may or may not
point to info->pseudo_palette

Unfortunately, monochrome framebuffers will be affected (how does it
interpret if request is character painting or logo drawing). One
solution is to make an exception for monochrome so we always pass it
packed mono data whether character or logo drawing.  The second, to
avoid the former's inconsistency but has a more confusing semantics, is
make image->depth=0 to mean monochrome expansion.


As Geert said, it's not just trivial, but logical to split fb_imageblit
into two.

> OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> while if depth != 0, then palette is in info->pseudo_palette ?

Yes.  You can also say that if image->depth != var->bits_per_pixel, do
color expansion or reduction, whatever the case may be.

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:
> As Geert said, it's not just trivial, but logical to split fb_imageblit
> into two.

So, are we gonna split it? This will also make hardware acceleration support
more clean. E.g. most sbus drivers do color expansion in hardware, and fall
back to cfb_imageblit() for the logo.

> > OK, so rule is that if depth=0, input is 1bpp with palette in bgcol/fgcol,
> > while if depth != 0, then palette is in info->pseudo_palette ?
> 
> Yes.  You can also say that if image->depth != var->bits_per_pixel, do
> color expansion or reduction, whatever the case may be.

Hmmm... Note that image->depth can be larger than 8, while the image data is
still 8-bit. This is an inconsistency.

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

FBdev updates.

[James Simmons]

New updates to the fbdev layer. You can grab the diff from 

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

or do a pull

	bk pull http://gkernel.bkbits.net/fbdev-2.5

This will update the following files:

 drivers/video/maxinefb.h                   |   37 
 drivers/video/pm2fb.h                      |  218 ---
 drivers/video/pm3fb.h                      | 1284 --------------------
 drivers/video/pmag-ba-fb.h                 |   24 
 drivers/video/pmagb-b-fb.h                 |   32 
 drivers/video/sstfb.h                      |  355 -----
 arch/mips64/Kconfig                        |    4 
 arch/ppc/syslib/prom.c                     |    3 
 arch/ppc/syslib/prom_init.c                |   28 
 arch/ppc64/kernel/prom.c                   |   27 
 drivers/char/vt.c                          |    8 
 drivers/video/Kconfig                      |   17 
 drivers/video/Makefile                     |    3 
 drivers/video/aty/atyfb.h                  |   86 -
 drivers/video/aty/atyfb_base.c             | 1804 ++++++++++++++---------------
 drivers/video/aty/mach64_accel.c           |   51 
 drivers/video/aty/mach64_ct.c              |  356 +++--
 drivers/video/aty/mach64_cursor.c          |    4 
 drivers/video/aty/mach64_gx.c              |   18 
 drivers/video/aty128fb.c                   |  162 +-
 drivers/video/cfbcopyarea.c                |   42 
 drivers/video/cfbfillrect.c                |   12 
 drivers/video/cfbimgblt.c                  |  100 -
 drivers/video/console/fbcon.c              |  333 -----
 drivers/video/console/fbcon.h              |    3 
 drivers/video/console/newport_con.c        |   69 -
 drivers/video/console/vgacon.c             |  673 +++++-----
 drivers/video/fbmem.c                      |  306 ++--
 drivers/video/fbmon.c                      |    3 
 drivers/video/hgafb.c                      |    9 
 drivers/video/i810/i810.h                  |    9 
 drivers/video/i810/i810_accel.c            |  150 +-
 drivers/video/i810/i810_main.c             |  486 ++-----
 drivers/video/i810/i810_main.h             |   14 
 drivers/video/logo/Kconfig                 |   67 +
 drivers/video/logo/Makefile                |   27 
 drivers/video/logo/logo.c                  |  100 +
 drivers/video/logo/logo_dec_clut224.ppm    | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_linux_clut224.ppm  | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_linux_mono.pbm     |  202 +++
 drivers/video/logo/logo_linux_vga16.ppm    | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_mac_clut224.ppm    | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_parisc_clut224.ppm | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_sgi_clut224.ppm    | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_sun_clut224.ppm    | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_superh_clut224.ppm | 1603 +++++++++++++++++++++++++
 drivers/video/logo/logo_superh_mono.pbm    |  202 +++
 drivers/video/logo/logo_superh_vga16.ppm   | 1603 +++++++++++++++++++++++++
 drivers/video/maxinefb.c                   |    2 
 drivers/video/modedb.c                     |    8 
 drivers/video/neofb.c                      |   81 -
 drivers/video/pm2fb.c                      |    2 
 drivers/video/pm3fb.c                      |    3 
 drivers/video/pmag-ba-fb.c                 |    2 
 drivers/video/pmagb-b-fb.c                 |    2 
 drivers/video/radeonfb.c                   |    1 
 drivers/video/riva/fbdev.c                 |  323 ++---
 drivers/video/riva/nv_driver.c             |  156 ++
 drivers/video/riva/rivafb.h                |    2 
 drivers/video/sgivwfb.c                    |  192 ++-
 drivers/video/skeletonfb.c                 |    6 
 drivers/video/sstfb.c                      |   14 
 drivers/video/tdfxfb.c                     |    6 
 drivers/video/tgafb.c                      |    2 
 drivers/video/tridentfb.c                  |    2 
 drivers/video/vga16fb.c                    |  127 +-
 include/linux/fb.h                         |   19 
 include/linux/linux_logo.h                 | 1435 -----------------------
 include/video/mach64.h                     |   61 
 include/video/maxinefb.h                   |   37 
 include/video/pm3fb.h                      | 1284 ++++++++++++++++++++
 include/video/pmag-ba-fb.h                 |   24 
 include/video/pmagb-b-fb.h                 |   32 
 include/video/sgivw.h                      |   40 
 include/video/sstfb.h                      |  355 +++++
 include/video/vga.h                        |   16 
 scripts/Makefile                           |    4 
 scripts/pnmtologo                          |binary
 scripts/pnmtologo.c                        |  498 ++++++++
 79 files changed, 20264 insertions(+), 6227 deletions(-)

through these ChangeSets:

<jsimmons@maxwell.earthlink.net> (03/02/19 1.913.1.3)
   [FBDEEV] Need to add support to build pnmtologo.

<jsimmons@maxwell.earthlink.net> (03/02/19 1.913.1.1)
   Removed obsolete functions in fbcon.c and re-enabled mapping console(s) to a framebuffer device. A few compile fixes for rivafb and using standard macros for vgacon.c.

<jsimmons@maxwell.earthlink.net> (03/02/16 1.913)
   [FBDEV] Data in struct fb_image is now const.
   
   [FBDEV] Updates to the logo code. We seperated it into two functions.
   
   [I810 FBDEV] Updates to the driver. PCI hooks for PCI supsend and resume to save the AGP GART mapping during power saving.
   
   [ATY 128] Add proper support for two graphics cards. Also added support for two more models of the Rage 128.
   
   [SGIVW FBDEV] Updates for the SGI Visual Workstation framebuffer.
   

<jsimmons@maxwell.earthlink.net> (03/02/13 1.910)
   [LOGO] New better logo code. 
   
   [FBDEV] Moved a few more header files.

<jsimmons@maxwell.earthlink.net> (03/02/11 1.909)
   [FBCON] Removal of useless code.

<jsimmons@maxwell.earthlink.net> (03/02/11 1.906)
   [ATY FBDEV] Reversed mobilty patches. They busted every other card.  

<jsimmons@maxwell.earthlink.net> (03/02/09 1.900)
   [ATY FBDEV] Updates to support Rage Mobility Chipstes.

<jsimmons@maxwell.earthlink.net> (03/01/30 1.899)
   [RIVA FBDEV] SUpprot Directcolor mode. Needed for some cards.

<jsimmons@kozmo.(none)> (03/01/28 1.897)
   [NEOMAGIC FBDEV] Fix to work with no 21xx versions of the chip.

<jsimmons@maxwell.earthlink.net> (03/01/28 1.889.52.3)
   [RADEON FBDEV] Add cursor support. Now the cursor is back.
   [RIVA FBDEV] Added support for interlace mode and are now using TRUECOLOR instead of DIRECTCOLOR. Setting the graphics card in DIRECTCOLOR confusses the X server.

<jsimmons@maxwell.earthlink.net> (03/01/26 1.889.52.2)
   Accel rountines pass in constant data into each function. The reason being was some of the code in the upper layers depended on the data being passed to the low level function not be altered because the upper layers was altering the data themselves.
   
   Pan display fix for fbcon.c. p->vrow needed to be updated.
   
   PPC build fix for fbmon.c
   
   I810 fbdev updates. 

<jsimmons@maxwell.earthlink.net> (03/01/17 1.889.52.1)
   [GENERIC ACCELERATION] Fixed the generic image drawing function tfor 64 bit machines.
   
   [RIVA FBDEV] The cursor and imageblit functions have been fixed.

Re: FBdev updates.

[Dave Jones]

On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote:

 > New updates to the fbdev layer. You can grab the diff from 
 > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

James,
 Whats the current status with matroxfb ? Its been broken
for months now, and hasn't seen any progress wrt getting it
back on its feet.

I understand Petr had some concerns with the new API, but
*something* needs to be done to get this back up and running.

I'd understand if this was a neglected hardly-used-by-anyone
driver, but there's an awful lot of matrox cards out there.

This was first reported broken way back in 2.5.53, but I believe
was broken even longer before that.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: FBdev updates.

[Petr Vandrovec]

On Thu, Feb 20, 2003 at 03:02:01PM +0000, Dave Jones wrote:
> On Thu, Feb 20, 2003 at 01:09:33AM +0000, James Simmons wrote:
> 
>  > New updates to the fbdev layer. You can grab the diff from 
>  > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> James,
>  Whats the current status with matroxfb ? Its been broken
> for months now, and hasn't seen any progress wrt getting it
> back on its feet.
> 
> I understand Petr had some concerns with the new API, but
> *something* needs to be done to get this back up and running.
> 
> I'd understand if this was a neglected hardly-used-by-anyone
> driver, but there's an awful lot of matrox cards out there.
> 
> This was first reported broken way back in 2.5.53, but I believe
> was broken even longer before that.

Since 2.5.51, when rewrite came in... 

You can get patch which reverts most of James's work at
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.59.gz.

I was for five weeks in U.S., so I did not do anything with
matroxfb during that time. I plan to use fillrect and copyrect
from generic code (although it means unnecessary multiply on
generic side, and division in matroxfb, but well, if we gave
up on reasonable speed for fbdev long ago...). But I simply
want loadfont and putcs hooks for character painting. And if 
fbdev maintainer does not want to give me them, well, then 
matroxfb and fbdev are not compatible.

I refuse to remove features from matroxfb driver, and textmode
support is one of current features (needed and required to be
able to run VMware on fullscreen - and as main part of my
job happens in VMware...). So there is couple of choices:
(1) new maintainer, or
(2) remove matroxfb from kernel, or
(3) persuade me that I want to write matroxcon and forget about fbcon at all, or
(4) something else I do not know about.

Besides that with that strange additional copy in accel_putcs
I get much slower output than with 2.4.x... and although I
understand that for 2.6.x we'll all have faster computers than
we had for 2.4.x, I still think that speed should be primary
concern, and code extensibility and readability secondary.
But well, I told it dozens of time, so why I bother. I do
not want to end up as Larry.
					Petr Vandrovec
					vandrove@vc.cvut.cz



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: Re: FBdev updates.

[Antonino Daplas]

On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> 
> I was for five weeks in U.S., so I did not do anything with
> matroxfb during that time. I plan to use fillrect and copyrect
> from generic code (although it means unnecessary multiply on
> generic side, and division in matroxfb, but well, if we gave
> up on reasonable speed for fbdev long ago...). But I simply
> want loadfont and putcs hooks for character painting. And if 
> fbdev maintainer does not want to give me them, well, then 
> matroxfb and fbdev are not compatible.

Petr,

I submitted the Tile Blitting patch to James some time ago, it has
tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
"multiply in fbcon, divide in driver" bottleneck.

It should result in the same behavior as you would expect in the the 2.4
API, so you can use text mode with your matroxfb driver.  These same
hooks will also help optimize drawing if we need to use fonts like
12x22.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Petr Vandrovec]

On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > 
> > I was for five weeks in U.S., so I did not do anything with
> > matroxfb during that time. I plan to use fillrect and copyrect
> > from generic code (although it means unnecessary multiply on
> > generic side, and division in matroxfb, but well, if we gave
> > up on reasonable speed for fbdev long ago...). But I simply
> > want loadfont and putcs hooks for character painting. And if 
> > fbdev maintainer does not want to give me them, well, then 
> > matroxfb and fbdev are not compatible.
> 
> Petr,
> 
> I submitted the Tile Blitting patch to James some time ago, it has
> tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
> "multiply in fbcon, divide in driver" bottleneck.
>
> It should result in the same behavior as you would expect in the the 2.4
> API, so you can use text mode with your matroxfb driver.  These same
> hooks will also help optimize drawing if we need to use fonts like
> 12x22.

Hi,
  while waiting on these updates I updated matroxfb a bit
(ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
so that it now uses fb_* for cfb modes, and putcs/... hooks for
text mode. I have still dozen of changes in fbcon.c which I have
to eliminate (mainly logo painting and cursor handling - for now
I still use revc method, mainly because of I did not make into it yet).

  But main thing is that I'd like to apologize to James - character
painting is much faster for 8x16 fonts under 2.5.x than it was under 2.4.x,
8bpp unaccelerated 8x16 under 2.5.x is even faster than accelerated
under 2.4.x.

  Algorithm for obtaining times was same as described in 
Documentation/fb/matroxfb.txt, with two differences: (1) hardware is 
G550 in P4/1.6GHz, and (2) there was 30MBps video stream feed to 
secondary G550 head of G550 during 2.4.19-pre6 tests, so I made 2.5.x 
tests twice, once with fbtv running and once without.

  My main concern now is 12x22 font... Accelerator setup
is so costly for each separate painted character that for 8bpp 
accelerated version is even slower than unaccelerated one :-(
(and almost twice as slow when compared with 2.4.x).

  And one (or two...) generic questions: why is not pseudo_palette
u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
And why we do not fill this pseudo_palette with
i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
pseudocolor? This allowed me to remove couple of switches and tests
from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
but I did not changed these two in my benchmarks below).

						Best regards,
							Petr Vandrovec
							vandrove@vc.cvut.cz


NOACCEL, 8x16
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	10.02		 6.96		 5.62
16bpp	20.05		13.25		10.62
24bpp	30.03		19.05		15.13
32bpp	45.00		25.74		20.54

ACCEL, 8x16
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	 7.48		 3.38		 3.00
16bpp	 7.50		 3.38		 3.01
24bpp	 7.53		 3.56		 3.53
32bpp	 8.95		 4.37		 4.33

NOACCEL, 12x22
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	11.54		13.35		10.93
16bpp	20.00		22.02		18.03
24bpp	30.03		35.83		29.53
32bpp	40.12		44.48		36.75

ACCEL, 12x22
	2.4.19+fbtv	2.5.63+fbtv	2.5.63
8bpp	 8.57		14.87		12.90
16bpp	 8.57		14.93		12.92
24bpp	 8.56		15.13		13.10
32bpp	 8.56		15.52		13.76

Re: Re: FBdev updates.

[Jurriaan]

From: Petr Vandrovec <vandrove@vc.cvut.cz>
Date: Mon, Mar 03, 2003 at 09:35:00PM +0100
> On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> > On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > > 
> > > I was for five weeks in U.S., so I did not do anything with
> > > matroxfb during that time. I plan to use fillrect and copyrect
> > > from generic code (although it means unnecessary multiply on
> > > generic side, and division in matroxfb, but well, if we gave
> > > up on reasonable speed for fbdev long ago...). But I simply
> > > want loadfont and putcs hooks for character painting. And if 
> > > fbdev maintainer does not want to give me them, well, then 
> > > matroxfb and fbdev are not compatible.
> > 
> > Petr,
> > 
> > I submitted the Tile Blitting patch to James some time ago, it has
> > tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
> > "multiply in fbcon, divide in driver" bottleneck.
> >
> > It should result in the same behavior as you would expect in the the 2.4
> > API, so you can use text mode with your matroxfb driver.  These same
> > hooks will also help optimize drawing if we need to use fonts like
> > 12x22.
> 
> Hi,
>   while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode.

There is a regression here: I boot my kernel like this:

kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1

and have the following .config:

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y
CONFIG_RAW_DRIVER=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONTS=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_ACCEL=y

matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1600x1200x16bpp (virtual: 1600x5241)
matroxfb: framebuffer at 0xD4000000, mapped to 0xe0805000, size 33554432
Console: switching to colour frame buffer device 133x54
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 266T chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xd0000000
[drm] Initialized mga 3.1.0 20021029 on minor 0

I see a continuous strip of alternating blocks, of sub-character size,
at the extreme right end of my screen. The colors seem linked to the
color of the line with the cursor in some way.

After leaving XFRee, a piece of chbg's background picture is shown for a
short while, then the blocks return.

Kind regards,
Jurriaan


-- 
But the threat of disapproval had terrified me
No more my soul will I reveal
	Wargasm - Chameleon
GNU/Linux 2.5.63 SMP/ReiserFS 1x2793 bogomips load av: 1.18 0.46 0.17


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

Hi James,
  I tried to use fb_cursor and I have quite a lot problems with
it:
(1) it uses global variables for storing last cursor value -
    - but there is no global hardware, so after switching from
    one fbdev to another you can have cursor with wrong shape,
    wrong color and so on...
(2) callback from timer for cursor blinking may set almost any
    FB_CUR_* bits. But in this case fb_cursor callback may be
    called from interrupt context, while accelerator is busy
    and so on... Did I miss some synchronization? Best for me
    would be disabling blinking code in fbcon completely:
    in VGA mode cursor blinks automatically, and in graphics mode
    more lightweight only 'flash' callback is more appropriate
    for me. But then there is problem with
(3) cursor_undrawn... I have no idea how is this supposed to work
    if fbdev provides hardware cursor... And HZ/50 delay after
    putcs makes orientation on screen very complicated, as there
    is no cursor while new characters are appearing on screen.
    
					Thanks,
						Petr Vandrovec
						vandrove@vc.cvut.cz


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Antonino Daplas]

On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> Hi James,
>   I tried to use fb_cursor and I have quite a lot problems with
> it:
> (1) it uses global variables for storing last cursor value -
>     - but there is no global hardware, so after switching from
>     one fbdev to another you can have cursor with wrong shape,
>     wrong color and so on...
> (2) callback from timer for cursor blinking may set almost any
>     FB_CUR_* bits. But in this case fb_cursor callback may be
>     called from interrupt context, while accelerator is busy
>     and so on... Did I miss some synchronization? Best for me
>     would be disabling blinking code in fbcon completely:
>     in VGA mode cursor blinks automatically, and in graphics mode
>     more lightweight only 'flash' callback is more appropriate
>     for me. But then there is problem with

I've also noticed problems with 1 and 2, and I submitted a patch to
James that allocates resources on a per device basis instead of being
global and statically allocated.  This includes the cursor data
structures, cursor timer/vbl interrupt service, putcs buffer, and
optionally the softback buffer.  The last is probably not very important
for the present setup but may become useful later on (ie, multiple
active consoles).

As for synchronization, I was meaning to ask some pointers on that.  The
setup currently works like this:

                        (blink)
fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
     |                     |
     -----------------------
               |
           accel_cursor
               |
     -----------------------
     |                      |
  hardware              soft_cursor    accel_putcs    accel_putc
                            |              |               |
                            -------------- -----------------
                                           | 
                                   fb_get_buffer_offset
                                           |
                                     xxxfb_imageblit
                                           |
                                  -------------------
                                  |                  |
                              hardware           software


I was thinking of placing locks in accel_cursor and
fb_get_buffer_offset, but I'm not sure.
  
> (3) cursor_undrawn... I have no idea how is this supposed to work

In the present cursor api, the driver just needs to draw/undraw the
cursor whether by software or hardware.  So the problem here is with
cursors that does it's own blinking, such as text modes.

>     if fbdev provides hardware cursor... And HZ/50 delay after
>     putcs makes orientation on screen very complicated, as there
>     is no cursor while new characters are appearing on screen.

The delay is only for the blinking.  After drawing a character/stream of
characters, an explicit "draw cursor" command immediately follows (I
think) via fbcon_cursor.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Re: FBdev updates.

[Petr Vandrovec]

On Mon, Mar 10, 2003 at 06:27:14AM +0800, Antonino Daplas wrote:
> On Mon, 2003-03-10 at 05:29, Petr Vandrovec wrote:
> 
> As for synchronization, I was meaning to ask some pointers on that.  The
> setup currently works like this:
> 
>                         (blink)
> fbcon_cursor         fbcon_vbl_handler (interrupt or timer)   
>      |                     |
>      -----------------------
>                |
>            accel_cursor
>                |
>      -----------------------
>      |                      |
>   hardware              soft_cursor    accel_putcs    accel_putc
>                             |              |               |
>                             -------------- -----------------
>                                            | 
>                                    fb_get_buffer_offset
>                                            |
>                                      xxxfb_imageblit
>                                            |
>                                   -------------------
>                                   |                  |
>                               hardware           software
> 
> 
> I was thinking of placing locks in accel_cursor and
> fb_get_buffer_offset, but I'm not sure.

Maybe just auditing code is enough: cursor_on should be zero while
we are inside accel_putc/putcs (or inside any other fb function), and
if cursor_on is zero, fbcon_vbl_handler should do nothing. So just making
sure that fbcon_vbl_handler is not running on other CPU while we set
cursor_on = 0 should be enough.

> >     if fbdev provides hardware cursor... And HZ/50 delay after
> >     putcs makes orientation on screen very complicated, as there
> >     is no cursor while new characters are appearing on screen.
> 
> The delay is only for the blinking.  After drawing a character/stream of
> characters, an explicit "draw cursor" command immediately follows (I
> think) via fbcon_cursor.

Why we schedule cursor painting at all then? While we are inside putcs,
we cannot paint cursor anyway (as we are busy with painting characters
at cursor position...) and fbcon_cursor(CM_DRAW) should restart timer interval
anyway (so you see cursor while you type characters, and not like Solaris
where cursor appears after you stop typing characters) (unfortunately when 
I tried to verify how it behaves on secondary head of matrox (which does not
have hardware cursor), I made a typo and ...

Unable to handle kernel NULL pointer dereference at virtual address 00000196
 printing eip:
c02f9258
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<c02f9258>]    Tainted: PFS
EFLAGS: 00010202
EIP is at fb_open+0x28/0xf0
eax: c6ed2c30   ebx: 00000020   ecx: 00000001   edx: c04848e0
esi: 00000002   edi: 00000000   ebp: c6ed2c30   esp: c4bb3f18
ds: 007b   es: 007b   ss: 0068
Process con2fb (pid: 18180, threadinfo=c4bb2000 task=d874d940)
Stack: 00000006 c8a8aae4 c4bb2000 00000000 c8a8aae4 c01669ea c6ed2c30 c8a8aae4
       dffe6830 c01435e3 c8a8aae4 c6ed2c30 dffe6830 00000000 c015af91 c6ed2c30
       c8a8aae4 00000002 bffffe7a dcaa5000 c4bb2000 c015adb7 ca74978c dffe6830
Call Trace:
 [<c01669ea>] chrdev_open+0xaa/0x110
 [<c01435e3>] file_ra_state_init+0x23/0x40
 [<c015af91>] dentry_open+0x1d1/0x1f0
 [<c015adb7>] filp_open+0x67/0x70
 [<c015b26b>] sys_open+0x5b/0x90
 [<c0109983>] syscall_call+0x7/0xb

Code: 8b 86 94 01 00 00 b9 01 00 00 00 8b 10 85 d2 74 1c b8 00 e0

so I'll have to check it tomorrow on real dualhead system...)

						Petr Vandrovec
						vandrove@vc.cvut.cz





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

fb_imageblit semantic

[Petr Vandrovec]

Hi James,
  after I spent two hours trying to find why my accelerated
fb_imageblit oopses (or paints garbage) when painting logo 
for bpp != 8 I have one simple question for you:

Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
when logo image is in reality always 8bpp, as quick look at 
cfb_imageblit revealed?

Should I just assume that image.depth == 1 means that data are
1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
input?
				Thanks,
					Petr Vandrovec
					vandrove@vc.cvut.cz


-------------------------------------------------------
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 Thu, 13 Mar 2003, Petr Vandrovec wrote:
> Why do you pass image.depth == 16 (or 24 or 32) to fb_imageblit
> when logo image is in reality always 8bpp, as quick look at 
> cfb_imageblit revealed?

Should indeed be 8.

> Should I just assume that image.depth == 1 means that data are
> 1bpp with fgcol/bgcol valid, and all other depths mean 8bpp
> input?

This was changed from 1 to 0 in James' latest tree.

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