Re: [Linux-fbdev-devel] cursor maddnes and a solution

[Jon S. <jon...@gm...>]

On 8/10/05, Andrey Volkov <av...@va...> wrote:
>=20
>=20
> Jon Smirl wrote:
> > On 8/10/05, Antonino A. Daplas <ad...@gm...> wrote:
> >
> >>struct fb_cursor_ops {
> >>        int (*cursor_move)(int x, int y);
> >>        int (*cursor_show)(int show);
> >>        int (*cursor_load_image)(u32 *image, int width, int height);
> >>        int (*cursor_load_color)(struct fb_cmap *cmap);
> >>        int (*cursor_set_size)(int width, int height);
> >>        int (*cursor_capabilities)(int set, int caps);
> >>};
> >
> >
> > Doen't fb already support an image format with embedded color map? Can
> > we use it and merge:
> >
> >>        int (*cursor_load_image)(u32 *image, int width, int height);
> >>        int (*cursor_load_color)(struct fb_cmap *cmap);
> >
> >
> > The size can also be computed from the image so the size call can be el=
iminated.
> >
> You are omit hwd cursor size problem - very few (possible no one)
> graphics chips could support cursor with any size. Usually they support
> 32x32/64x64 pixels cursors only. For kernel fb its have not meaning,
> 'cause we always could fallback to the soft_cursor (in the fbcon or
> directly in a driver), BUT what to do with such crazy user who will wish
> to use, ex. 100x100 pix cursor in user space?

You would just get an error back if the hardware cursor doesn't
support the big size. Your user space app would then have to implement
a fallback software one. You always have to implement the software
fallback since not all hardware may expose the cursor.

You can't implement the software cursor for user space in the kernel
because there is no way to synchronize it with user space drawing. I
think the better solution is for user space apps to handle it than to
try and build a synchronization system into fbdev.

If you are writing X apps you don't have to deal with any of this, X
handles it all for you.

--=20
Jon Smirl
jon...@gm...