[RFC] Does fbdev need a cursor API for userland?

[RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

Hi all,

I'm done with a little clean-up of the fbcon cursor code.  A problem still
remains with the cursor code in fbmem.c:fb_cursor(). This function is
accessible by the user through the FBIO_CURSOR ioctl.  However, just by
looking at it, I think it is broken. 

The question is, do we need to support this ioctl?  Coding for this correctly
is a bit complicated (very similar to coding for a rudimentary overlay).
However, if it's agreed upon to support this ioctl, here's a proposal and
questions for an implementation:

1. Below can be supported by the current cursor code.  Do we need more?

  - 2-color cursor
  - show, move, hide cursor
  - maximum dimensions of 64x64
  - invert and copy ROPs

2. Should fbdev implement a generic version, or should this be available only
to drivers with hardware cursors?

3. Additionally, code must be written for the following:
  - restriction for single use or locking for multiple use
  - save/restore framebuffer contents underlying the cursor (if a 
    software/generic version is supported) 

4. Implementation

A single ioctl is too unwieldy for usage.  It's probably better to split the
ioctl into at least following:

FBIO_CURSOR_ACTIVATE
	- activate/inactivate user-mode cursor.  This will disable/reenable the 
fbcon cursor, load initial data (colormap, image, map), etc.

FBIO_CURSOR_MOVE
	- show, move or hide cursor

FBIO_CURSOR_LOADCMAP
	- change cursor colormap

FBIO_CURSOR_LOADIMAGE
	- change cursor image and mask

IMO, I believe that the cursor ioctl should just be removed :-)

Comments?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Zachary Smith]

Antonino A. Daplas wrote:

> IMO, I believe that the cursor ioctl should just be removed :-)

Well I don't need a cursor from userland, but I do need a way to
manage the hardware cursor (sprite) if it exists from within
the kernel.

Zack


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 01:18, Zachary Smith wrote:
> Antonino A. Daplas wrote:
> > IMO, I believe that the cursor ioctl should just be removed :-)
>
> Well I don't need a cursor from userland, but I do need a way to
> manage the hardware cursor (sprite) if it exists from within
> the kernel.
>

I'm not sure I understand.

What I'm proposing is removal of kernel support of the cursor for userland
fbdev applications. The fbcon->fbdev cursor interface will still exist.  The
sprite, whether by hardware or software, is managed by fbcon.  The cursor
characteristics, albeit limited, are changed via the vt->fbcon->fbdev
pathway (see Documentation/ VGA-softcursor.txt).

Should the console cursor have other modifiable characteristics besides
changing the shape (underline, block, half-block, etc), and changing the
color?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Jon Smirl]

On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:

> IMO, I believe that the cursor ioctl should just be removed :-)

The merged fbdev/DRM needs hardware cursor support in fbdev but it
doesn't need the fbdev cursor IOCTL. Moving cursor support to fbcon
won't work either. Implementing cursor support in merged fbdev/DRM
probably means a modified API since we have to deal with multiple
heads.

Are there cards still out there with no hardware cursor support?
How many apps use the user space fbdev interface?

Also, a some point I would like to revisit the fbcon/fbdev interface
and reduce the number of fbdev variables fbcon can access but doesn't
use. fbcon shouldn't have direct access to the fb_info struct, there
should be more of an interface there.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Zachary Smith]

Jon Smirl wrote:

> Are there cards still out there with no hardware cursor support?

The fallbacks for not having a driver are VESA and VGA, which lack it.

 > How many apps use the user space fbdev interface?

Any app that uses FBUI (my in-kernel GUI) at least opens /dev/fb/0.
Then it uses my ioctls.

Zack


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 07:49, Zachary Smith wrote:
> Jon Smirl wrote:
>  > How many apps use the user space fbdev interface?
>
> Any app that uses FBUI (my in-kernel GUI) at least opens /dev/fb/0.
> Then it uses my ioctls.

The FBIO_CURSOR is new in 2.6 and the implementation is broken.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 06:25, Jon Smirl wrote:
> On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> wrote:
> > IMO, I believe that the cursor ioctl should just be removed :-)
>
> The merged fbdev/DRM needs hardware cursor support in fbdev but it

A kernel-to-kernel interface to the hardware cursor is easier to implement since
we always trust kernel data, so that is not much of a problem. The problematic
area is the generic, non-fbcon specific cursor implementation, and exporting
the interface to userspace. All are doable of course, and I'm willing to code it
if people want it.

> doesn't need the fbdev cursor IOCTL. Moving cursor support to fbcon
> won't work either. Implementing cursor support in merged fbdev/DRM
> probably means a modified API since we have to deal with multiple
> heads.
>
> Are there cards still out there with no hardware cursor support?

All hardware, except for the platform ones, probably have hardware cursor
support, but most are unimplemented.  In 2.6, only i810fb and rivafb have a 
hardware cursor implementation.  The rest, tdfxfb, imsttfb, mach64fb, neofb,
etc are broken and the code is commented out, so they use softcursor
instead.  There is a patch for mach64 though that fixes the hardware cursor
implementation, but it's not in mainline yet.
 
> How many apps use the user space fbdev interface?

The standard user fbdev interface are used by a lot of applications.
However, the cursor ioctl interface is new in 2.6, and since it's broken, I
doubt if any major apps use it.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Jon Smirl]

On Mon, 18 Oct 2004 09:20:39 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:
> On Monday 18 October 2004 06:25, Jon Smirl wrote:
> > On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
> >
> > <adaplas@hotpop.com> wrote:
> > > IMO, I believe that the cursor ioctl should just be removed :-)
> >
> > The merged fbdev/DRM needs hardware cursor support in fbdev but it
> 
> A kernel-to-kernel interface to the hardware cursor is easier to implement since
> we always trust kernel data, so that is not much of a problem. The problematic
> area is the generic, non-fbcon specific cursor implementation, and exporting
> the interface to userspace. All are doable of course, and I'm willing to code it
> if people want it.

Merged fbdev/DRM is being built as a platform to run mesa-solo on.
mesa-solo is the standalone OpenGL implementation. X on GL will then
run on top of mesa-solo. Do this will get X out of the device driver
business.

The downside is that Merged fbdev/DRM has to pick up the load that the
2D XAA drivers were carrying and part of that is support for the
hardware cursor. The other major component is mode setting support.

Another large area I am working on is making all heads work on
multihead cards with the merged fbdev/DRM driver. Bringing up multi
head in this environment has exposed some design problems in the
fb_info structures. The structure doesn't sort out things that there
are only one of vs multiple ones.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 10:46, Jon Smirl wrote:
> On Mon, 18 Oct 2004 09:20:39 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> wrote:
> > On Monday 18 October 2004 06:25, Jon Smirl wrote:
> > > On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
> > >
> > > <adaplas@hotpop.com> wrote:
> > > > IMO, I believe that the cursor ioctl should just be removed :-)
> > >
> > > The merged fbdev/DRM needs hardware cursor support in fbdev but it
> >
> > A kernel-to-kernel interface to the hardware cursor is easier to
> > implement since we always trust kernel data, so that is not much of a
> > problem. The problematic area is the generic, non-fbcon specific cursor
> > implementation, and exporting the interface to userspace. All are doable
> > of course, and I'm willing to code it if people want it.
>
> Merged fbdev/DRM is being built as a platform to run mesa-solo on.
> mesa-solo is the standalone OpenGL implementation. X on GL will then
> run on top of mesa-solo. Do this will get X out of the device driver
> business.
>
> The downside is that Merged fbdev/DRM has to pick up the load that the
> 2D XAA drivers were carrying and part of that is support for the
> hardware cursor. The other major component is mode setting support.
>

Ok, adding a cursor interface that _only_ supports drivers with a hardware
cursor implementation is easy to do, and the current fbdev cursor API is
quite capable of handling the task with just a few minor modifications, such
as support for transparent cursors.

The difficult part is the software cursor implementation.  Software
implementation is basically done this way:

show_cursor:
save_fb_contents->draw _cursor

hide_cursor:
restore_fb_contents

move_cursor:
restore_fb_contents->move_cursor->save_fb_contents->draw_cursor

The restore_fb_contents/save_fb_contents cannot be done generically.  Not
all framebuffers have a linear format, there are some that are planar such
as amifb and vga16fb.  This means that we need to add per-driver hooks just
to save and restore the framebuffer contents.

In the case of fbcon, saving and restoring the content underneath the cursor
is easy to do because we always know that the contents are just monochrome
character bitmaps, and the exact character underneath the cursor is provided
by the vt layer. Also, the cursor movement granularity is always a
character. So coding an fbcon->fbdev cursor interface is trivial.

So if this cursor interface is needed, here are the possible options:

1. provide a cursor interface that works universally for all drivers

2. same as #1 but exclude drivers with a non-linear format

3. only provide an interface for drivers with a hardware implementation.

If driver has no hardware implementation, then:
  For #1, per-driver save/restore functions are necessary.
  For #2, only a generic save/restore function is needed.
  For #3, minimal change, we can add the interface now.

So, which one do you think is acceptable?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 10:46, Jon Smirl wrote:
> On Mon, 18 Oct 2004 09:20:39 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> wrote:
> head in this environment has exposed some design problems in the
> fb_info structures. The structure doesn't sort out things that there
> are only one of vs multiple ones.

I don't think you can expect a single fb_info structure to represent more
than 1 display. If the card happens to support multihead, then the driver must
be able to register the driver more than once so it creates /dev/fb0,
/dev/fb1, etc, one for each head.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Geert Uytterhoeven]

On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> The restore_fb_contents/save_fb_contents cannot be done generically.  Not
> all framebuffers have a linear format, there are some that are planar such
> as amifb and vga16fb.  This means that we need to add per-driver hooks just
> to save and restore the framebuffer contents.

Can't we use fb_imageblit() for restore? Then al we need to add is a
get_image() routine.

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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > The restore_fb_contents/save_fb_contents cannot be done generically.  Not
> > all framebuffers have a linear format, there are some that are planar
> > such as amifb and vga16fb.  This means that we need to add per-driver
> > hooks just to save and restore the framebuffer contents.
>
> Can't we use fb_imageblit() for restore? 

fb_imageblit() is limited because it uses the pseudo_palette.  Even if
we expand the palette to 256 entries, it won't be able to handle formats >
8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to
1->bpp, and 8->bpp expansion.

> Then al we need to add is a get_image() routine.

I guess if we can add get_image(), it's simple enough to write a
corresponding set_image().  Your amifb is one driver that's going to
be affected, so if you say 'yes' to the above, then let's go for a 
universal cursor implementation.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Geert Uytterhoeven]

On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > The restore_fb_contents/save_fb_contents cannot be done generically.  Not
> > > all framebuffers have a linear format, there are some that are planar
> > > such as amifb and vga16fb.  This means that we need to add per-driver
> > > hooks just to save and restore the framebuffer contents.
> >
> > Can't we use fb_imageblit() for restore? 
> 
> fb_imageblit() is limited because it uses the pseudo_palette.  Even if
> we expand the palette to 256 entries, it won't be able to handle formats >
> 8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to
> 1->bpp, and 8->bpp expansion.

What about expanding fb_imageblit() to handle 32-bit ARGB as well? Then it can
handle most canonical formats (1 bpp monochrome, 8-bit CLUT, 32-bit
ARGB). We still would have problems with e.g. 10-bit CLUT.

> > Then al we need to add is a get_image() routine.
> 
> I guess if we can add get_image(), it's simple enough to write a
> corresponding set_image().  Your amifb is one driver that's going to
> be affected, so if you say 'yes' to the above, then let's go for a 
> universal cursor implementation.

For me having to add a planar get_image() to amifb is OK.

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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Geert Uytterhoeven]

On Mon, 18 Oct 2004, Geert Uytterhoeven wrote:
> On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > The restore_fb_contents/save_fb_contents cannot be done generically.  Not
> > > > all framebuffers have a linear format, there are some that are planar
> > > > such as amifb and vga16fb.  This means that we need to add per-driver
> > > > hooks just to save and restore the framebuffer contents.
> > >
> > > Can't we use fb_imageblit() for restore? 
> > 
> > fb_imageblit() is limited because it uses the pseudo_palette.  Even if
> > we expand the palette to 256 entries, it won't be able to handle formats >
> > 8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to
> > 1->bpp, and 8->bpp expansion.
> 
> What about expanding fb_imageblit() to handle 32-bit ARGB as well? Then it can
> handle most canonical formats (1 bpp monochrome, 8-bit CLUT, 32-bit
> ARGB). We still would have problems with e.g. 10-bit CLUT.

BTW, for save/restore this doesn't matter much. As long as restore/save match,
it's OK, so it would be possible to save the 10-bit CLUT pixel data in a
32-bit ARGB block.

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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote:
> On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > The restore_fb_contents/save_fb_contents cannot be done generically. 
> > > > Not all framebuffers have a linear format, there are some that are
> > > > planar such as amifb and vga16fb.  This means that we need to add
> > > > per-driver hooks just to save and restore the framebuffer contents.
> > >
> > > Can't we use fb_imageblit() for restore?
> >
> > fb_imageblit() is limited because it uses the pseudo_palette.  Even if
> > we expand the palette to 256 entries, it won't be able to handle formats
> > > 8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to
> > 1->bpp, and 8->bpp expansion.
>
> What about expanding fb_imageblit() to handle 32-bit ARGB as well? Then it
> can handle most canonical formats (1 bpp monochrome, 8-bit CLUT, 32-bit

Meaning, fb_imageblit needs to do 32-bit ARGB to native fb format conversion
on the fly.  How can we do that generically without fb_imageblit knowing the
format of the framebuffer? For example, how do we convert 32-bit ARGB to
8-bit Pseudocolor?

Isn't it much simpler to just have a set_image() where the source block is
in the same format as the framebuffer so it doesn't have to do format
conversions?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Geert Uytterhoeven]

On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote:
> > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > > The restore_fb_contents/save_fb_contents cannot be done generically. 
> > > > > Not all framebuffers have a linear format, there are some that are
> > > > > planar such as amifb and vga16fb.  This means that we need to add
> > > > > per-driver hooks just to save and restore the framebuffer contents.
> > > >
> > > > Can't we use fb_imageblit() for restore?
> > >
> > > fb_imageblit() is limited because it uses the pseudo_palette.  Even if
> > > we expand the palette to 256 entries, it won't be able to handle formats
> > > > 8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to
> > > 1->bpp, and 8->bpp expansion.
> >
> > What about expanding fb_imageblit() to handle 32-bit ARGB as well? Then it
> > can handle most canonical formats (1 bpp monochrome, 8-bit CLUT, 32-bit
> 
> Meaning, fb_imageblit needs to do 32-bit ARGB to native fb format conversion
> on the fly.  How can we do that generically without fb_imageblit knowing the
> format of the framebuffer? For example, how do we convert 32-bit ARGB to

Remember, fb_imageblit() is just a function pointer set up by the fbdev. In
most cases it's just cfb, though.

> 8-bit Pseudocolor?

I didn't intend it to do conversions. 32-bit ARGB would be used for truecolor
visuals only.

> Isn't it much simpler to just have a set_image() where the source block is
> in the same format as the framebuffer so it doesn't have to do format
> conversions?

Yes it is.

The fb_imageblit() approach is just more generic, and could (in theory) be used
from user space as well, allowing applications to not have to care about the
actual frame buffer format anymore. All they have to handle is 1-bit
monochrome, 8-bit pseudocolor and 32-bit ARGB 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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Tuesday 19 October 2004 05:00, Geert Uytterhoeven wrote:
> On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> > On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote:
> > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
>
> I didn't intend it to do conversions. 32-bit ARGB would be used for
> truecolor visuals only.
>
> > Isn't it much simpler to just have a set_image() where the source block
> > is in the same format as the framebuffer so it doesn't have to do format
> > conversions?
>
> Yes it is.
>
> The fb_imageblit() approach is just more generic, and could (in theory) be
> used from user space as well, allowing applications to not have to care
> about the actual frame buffer format anymore. All they have to handle is
> 1-bit monochrome, 8-bit pseudocolor and 32-bit ARGB truecolor.
>

We still have to do conversions, say from 32-bit ARGB to RGB565.  And this
is just for truecolor.  How about directcolor?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Geert Uytterhoeven]

On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> On Tuesday 19 October 2004 05:00, Geert Uytterhoeven wrote:
> > On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> > > On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote:
> > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> >
> > I didn't intend it to do conversions. 32-bit ARGB would be used for
> > truecolor visuals only.
> >
> > > Isn't it much simpler to just have a set_image() where the source block
> > > is in the same format as the framebuffer so it doesn't have to do format
> > > conversions?
> >
> > Yes it is.
> >
> > The fb_imageblit() approach is just more generic, and could (in theory) be
> > used from user space as well, allowing applications to not have to care
> > about the actual frame buffer format anymore. All they have to handle is
> > 1-bit monochrome, 8-bit pseudocolor and 32-bit ARGB truecolor.
> >
> 
> We still have to do conversions, say from 32-bit ARGB to RGB565.  And this
> is just for truecolor.

Indeed.

> How about directcolor?

You're right. And currently directcolor is treated like pseudocolor w.r.t. the
console and the penguin logo.

Hmm, bad idea, at least for saving/restore for the cursor.

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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Does fbdev need a cursor API for userland?

[Antonino A. Daplas]

On Tuesday 19 October 2004 16:01, Geert Uytterhoeven wrote:
> On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> > On Tuesday 19 October 2004 05:00, Geert Uytterhoeven wrote:
> > > On Tue, 19 Oct 2004, Antonino A. Daplas wrote:
> > > > On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote:
> > > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > > > > > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote:
> > > > > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote:
> > >
> > > I didn't intend it to do conversions. 32-bit ARGB would be used for
> > > truecolor visuals only.
> > >
> > > > Isn't it much simpler to just have a set_image() where the source
> > > > block is in the same format as the framebuffer so it doesn't have to
> > > > do format conversions?
> > >
> > > Yes it is.
> > >
> > > The fb_imageblit() approach is just more generic, and could (in theory)
> > > be used from user space as well, allowing applications to not have to
> > > care about the actual frame buffer format anymore. All they have to
> > > handle is 1-bit monochrome, 8-bit pseudocolor and 32-bit ARGB
> > > truecolor.
> >
> > We still have to do conversions, say from 32-bit ARGB to RGB565.  And
> > this is just for truecolor.
>
> Indeed.
>
> > How about directcolor?
>
> You're right. And currently directcolor is treated like pseudocolor w.r.t.
> the console and the penguin logo.
>
> Hmm, bad idea, at least for saving/restore for the cursor.

Well, your proposal sounds useful though. We can still expand imageblit so it has
these additional functions:

32-bit ARGB truecolor ->any truecolor format
32-bit ARGB directcolor-> any directcolor format
8-bit pseudocolor -> all formats <= 8 bpp && !directcolor && !truecolor 

(First and second is easy to add. The third may be a bit tricky because
it conflicts with already existing code for the penguin, but I think it's
fixable. The logo code in fbmem.c and color_imageblit need to be rewritten.)

I think with the above we cover everything for packed-pixel formats.

Then for the cursor (if people still want it), we just add get_image_raw()
and set_image_raw() hooks which gets/sets the contents in native framebuffer
format.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl