[Linux-fbdev-users] [RFC] Does fbdev need a cursor API for userland?

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

Hi all,

I'm done with a little clean-up of the fbcon cursor code.  A problem still
remains with the cursor code in fbmem.c:fb_cursor(). This function is
accessible by the user through the FBIO_CURSOR ioctl.  However, just by
looking at it, I think it is broken. 

The question is, do we need to support this ioctl?  Coding for this correctly
is a bit complicated (very similar to coding for a rudimentary overlay).
However, if it's agreed upon to support this ioctl, here's a proposal and
questions for an implementation:

1. Below can be supported by the current cursor code.  Do we need more?

  - 2-color cursor
  - show, move, hide cursor
  - maximum dimensions of 64x64
  - invert and copy ROPs

2. Should fbdev implement a generic version, or should this be available only
to drivers with hardware cursors?

3. Additionally, code must be written for the following:
  - restriction for single use or locking for multiple use
  - save/restore framebuffer contents underlying the cursor (if a 
    software/generic version is supported) 

4. Implementation

A single ioctl is too unwieldy for usage.  It's probably better to split the
ioctl into at least following:

FBIO_CURSOR_ACTIVATE
	- activate/inactivate user-mode cursor.  This will disable/reenable the 
fbcon cursor, load initial data (colormap, image, map), etc.

FBIO_CURSOR_MOVE
	- show, move or hide cursor

FBIO_CURSOR_LOADCMAP
	- change cursor colormap

FBIO_CURSOR_LOADIMAGE
	- change cursor image and mask

IMO, I believe that the cursor ioctl should just be removed :-)

Comments?

Tony