Re: cursor maddnes and a solution

[Andrey Volkov <avolkov@varma-el.com>]

Jon Smirl wrote:
> On 8/10/05, Antonino A. Daplas <adaplas@gmail.com> 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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf