Re: cursor maddnes and a solution

["Antonino A. Daplas" <adaplas@gmail.com>]

James Simmons wrote:
> I still refuse to touch all drivers at a time. Instead I will merge in 

Why not?  The change is simple, logical and any bugs are easy to spot.

> soft_cursor into the internals of the fbcon cursor code. This will make 

The patch does that already. It's moving softcursor away from fbdev into
fbcon.

> soft cursor be longer used. Then we can remove the soft cursor from the
> drivers.

Yep, the patch does that too.

So, if I distill your arguments, it boils down to that your main concern is
the patch touches all drivers at once.  So you want 1 patch per driver
then? But Documentation/SubmittingPatches says:

	"On the other hand, if you make a single change to numerous files,
	 group those changes into a single patch.  Thus a single logical change
	 is contained within a single patch."

In the end, it seems that you, me and Jon have the same goal in mind. I don't
see any disagreement here.

>There will be no soft_cursor wrap around to imageb lit anymore.
> I think people can live with that.

And how do you propose to implement a softcursor that is not a wrapper to
imageblit?  Using fillrect?  That's fine with me. Just take into consideration
that an XOR Rop needs to read the contents of the framebuffer first before
writing.  And READS are slow on most PCI cards.

What I cannot understand is your aversion against softcursor.  For fbcon,
it works 100% of the time, guaranteed, for any kind of driver, fictional or
otherwise.

===========================================================================
Anyway, I really don't have a strong argument against adding FB_ACCEL_HWCUR
flag to fbdev.  What I'm against is the overloading of info->fbops->fb_cursor
for userspace. I'll try to clarify:

Almost all graphics hardware have support for a cursor, but they are designed
mainly for a mouse cursor, not a text cursor. So in fbdev/fbcon context,
what we have is a mouse cursor emulating a text cursor. The differences are:

1. Movement granularity of a text cursor is per character, mouse cursor is
per pixel. Also mouse cursor must have a low latency (try shaking your mouse)
and movement changes happen at a very fast rate.

2. A mouse cursor usually have a static image.  It does change from time to
time depending on the app. Basically, you load the image once and you can 
choose to forget about it. A text cursor image, on the other hand, changes
depending on the underlying character.

3. A mouse cursor usually has a static color.  A text cursor's color will
change a lot, especially if your editor has syntax highlighting enabled.

4. A mouse cursor is usually steady, a text cursor usually blinks.

5. The size of the cursor is unchanging for both mouse and text.

So we have these 5 characteristics of the cursor:

		text		mouse
-----------------------------------------
position	changing	changing (at a rapid rate)
size		static		static
image		changing	static
color		changing	static
show/hide	changing	static
 
Now, our info->fbops->fb_cursor() accepts a parameter struct fb_cursor which is
more than 100 bytes in size.  It has everything there in order to have a fully
functional cursor.  But, that's a lot of bytes to move.  This is probably okay
for the text cursor because the text cursor characteristics are usually in a
state of flux. For the mouse cursor, on the other hand, only the position is
usually changing.

So that's why I don't want info->fbops->fb_cursor to be used in user space.  It
is inefficient.  Why move 100 bytes of data to move the cursor to x,y? And then
you have to take into consideration that the rate of change is very rapid.

1. So what I want is to have another API for userspace use.  This API needs to
be broken down into something like below:

fb_cursor_move()
fb_cursor_size()
fb_cursor_load_image()
fb_cursor_load_color()
fb_cursor_show()

A typical app will call fb_cursor_move() magnitudes of times more compared
to the rest.  And if fb_cursor_move() accepts only 2 integers, x and y,
we're just moving 8 bytes, in contrast to 100 bytes.

If you think it's too much splitting, we can just split it into two, one for
the characteristics that changes a lot and another for characteristics that
are predominantly static.

Now this need not coexist side by side forever with fbcon's cursor. Once we
have appropriate testing of this new API, we can start porting drivers that
have a working implementation of the old API (there are 5 right now) to the
new one, Once all drivers are ported, we can remove the old API.  With this,
transition from the old API to the new need not be noticed by the general user.

OR 2. We can start overhauling info->fbops->fb_cursor right now, but at the
risk that any bugs will be felt painfully by the user.

OR 3. Let's forget about userspace cursor support.

Tony



-------------------------------------------------------
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