Re: PATCH: move soft_cursor into fbconsole

On 6/20/05, James Simmons [off-list ref] wrote:

I agree we should not fall back to the software cursor when the hardware
cursor fails. Do we really want to eliminate the cursor from the device
interface if it is not a hardware cursor? Shouldn't the cursor always
work? That is the question.

I don't think there really is a choice here. Fbdev has to implement
the hardware cursor. The software one is application specific.
fbconsole and X implement it completely differently. I don't think
there is a way to implement a general software cursor.

fbdev provides hardware or nothing
if no hardware cursor, cursor is up to app
fbconsole and X then provide two different fallback schemes.

For example I don't think we have enough info to implement X's
software cursor in the fbdev driver. We would need some way to know
when X is updating the screen via paint or buffer swaps. Wouldn't that
be a total mess for fbdev to track and a new API would be needed.

We just never noticed the problem before since only one client
(fbconsole) was using the cursor. Current X is programming the
hardware cursor from user space.

After this change it would probably be cleaner to just eliminate the
softcursor module and compile softcursor into fbconsole. softcursor.c
would be moved to the fbconsole subdir if you can figure out how to
tell git to do a mv. But we can always save these changes for later.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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_idt77&alloc_id492&op=click