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

[Andrey V. <av...@va...>]

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 eliminated.
> 
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?

-- 
Regards
Andrey Volkov