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

[James S. <jsi...@in...>]

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

I like to see it broken up into smaller pieces. 

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

I'm talking about if fillrect is hardware accelerated and imageblit is 
not. In this case we want to use the fillrect.

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

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

Who said you have to move all that data at one time. We can have a struct 
fb_cursor in struct fb_info like we have for fb_cmap. Fill in default 
data. Fill in the values you want to change. Call fb_cursor fbops when you 
want the changes to take affect. Its not that hard to do.