Re: cursor maddnes and a solution

Jon Smirl wrote:

On 8/10/05, Antonino A. Daplas [off-list ref] wrote:

quoted

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:

quoted

       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