Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2003-03-14 10:19:11
|
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
|
|
From: Petr V. <VAN...@vc...> - 2003-03-14 10:53:04
|
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
van...@vc...
|
|
From: Antonino D. <ad...@po...> - 2003-03-16 23:04:00
|
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 |
|
From: Geert U. <ge...@li...> - 2003-03-17 10:33:55
|
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 -- ge...@li...
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
|
|
From: Petr V. <VAN...@vc...> - 2003-03-17 10:40:33
|
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
van...@vc...
|
|
From: Antonino D. <ad...@po...> - 2003-03-17 12:10:46
|
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 |
|
From: Geert U. <ge...@li...> - 2003-03-17 12:20:04
|
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 -- ge...@li...
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
|
|
From: Antonino D. <ad...@po...> - 2003-03-17 13:05:34
|
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 |
|
From: Petr V. <VAN...@vc...> - 2003-03-17 12:26:06
|
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
|
|
From: Geert U. <ge...@li...> - 2003-03-17 12:42:51
|
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 -- ge...@li...
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
|
|
From: Antonino D. <ad...@po...> - 2003-03-17 13:05:39
|
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 |
|
From: Geert U. <ge...@li...> - 2003-03-17 13:50:06
|
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 -- ge...@li...
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
|
|
From: Antonino D. <ad...@po...> - 2003-03-17 14:28:11
|
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 |
|
From: Geert U. <ge...@li...> - 2003-03-17 14:49:26
|
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 -- ge...@li...
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
|
|
From: Kendall B. <Ken...@sc...> - 2003-03-18 23:50:27
|
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! ~ |
|
From: Kendall B. <Ken...@sc...> - 2003-03-18 22:07:19
|
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! ~ |
|
From: Geert U. <ge...@li...> - 2003-03-14 10:42:44
|
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 -- ge...@li...
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
|
Thanks for helping keep SourceForge clean.
X