Re: PATCH: move soft_cursor into fbconsole

quoted

        Now I was thinking instead of a massive move of the the software
cursor we add a flag FBINFO_HWACCEL_CURSOR to tell us if we are using a
hardware cursor. This way for the sysfs interface you can test to see if
it is a hardware cursor and only allow userland to access a hardware
cursor. Here is a patch for that. People please try it out.

Your code will work, but it is conceptually what we want to do?
Software cursors are application specific. The soft cursor implemented
in fbdev really belongs to fbconsole.  If we get another in-kernel
user with a different update pattern (maybe they use the GPU) they
will want a different soft cursor. Shouldn't we just move the current
soft cursor into fbconsole? Given that software cursors are
application specific fbdev should not contain one.

The only reason I'm against that is then when the developer with the 
different update pattern will create a new fbconsole. We could end up 
with several fbconsoles. I really like to keep it down to one. So I rather 
deal with several cursor implementation instead of several fbconsoles.
Also remember that the software cursor is generically wrapped around the
the imageblit function. Since imageblit is independent of the update 
pattern we will be okay.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click