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

[Antonino A. D. <ad...@gm...>]

Jon Smirl wrote:
> 
> The hardware mouse cursor is relevant in graphics mode because you may
> not be able to generate screens in real time. If you can't the
> software mouse cursor lags and may become unusable. Hardware mouse
> cursor eliminates this problem.
> 

I don't have anything against hardware cursor support for userspace. And
I don't even mind if we remove hardware cursor support for fbcon (I don't
see the benefit anyway).  What I don't want is using fbops->fb_cursor
to support a userspace hardware cursor.  In it's current incarnation
it is just wrong.  Besides being a multiplexer with a 100-byte parameter,
it also requires information that are internal to fbdev only. And even if
we manage to make it work, we'll end up with a function with a multiple
personality disorder, it behaves differently when client is fbcon, and
changes behavior again when the client is userspace.

So let's keep fbops->fb_cursor for fbcon use only.  Better yet, let fbcon
call soft_cursor unconditionally, remove hardware cursor from all drivers,
then overhaul fbops->fb_cursor. Or if people think this is too radical,
let's create a new cursor API and gradually phase out the old API, as
proposed in my previous post. Here's one:

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);
};

struct fb_info {
	...
	struct fb_cursor_ops *cursor_ops;
	...
};

In cursor_load_image, we can make image to be always 32-bit truecolor and
just let the driver convert it to something the hardware can support.

In cursor_capabilities, it will either set the capabilities, or get it.
int caps may be t0o small to describe the capabilities so this can be changed.

Tony