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
|
