Re: [BK FBDEV] A few more updates.
From: Petr Vandrovec <hidden>
Date: 2003-03-26 10:31:35
Also in:
lkml
On 26 Mar 03 at 17:53, Antonino Daplas wrote:
On Wed, 2003-03-26 at 13:34, James Simmons wrote:quoted
quoted
5. softcursor should not concern itself with memory bookkeeping, and must be able to function with just the parameter passed to it in order to keep it as simple as possible. These tasks are moved to accel_cursor.We do if we make a ioctl for cursors. I'm trying to avoid reprogramming the hardware over and over again if the properties of the cursor don't change. The idea is similar to passing in var and comparing it to the var in struct fb_info.Of course, that's what the fb_cursor.set field is for, and drivers have the option of ignoring or not ignoring bits in this field. Whoever calls fb_cursor has the responsibility of setting any cursor state changes. Unlike fb_set_var(), cursor states change very frequently (ie, each blink or movement of the cursor are considered state changes), so just forego the memcmp() and call fb_cursor unconditionally. Let the low-level method sort it out by checking bits in fb_cursor.set.
accel_cursor unconditionally sets FB_CUR_SETPOS. Can you write it
down to the TODO list to eliminate this? Cursor position lives
in different registers than cursor enable/disable on my hardware...
And if we could rename FB_CUR_SETCUR to FB_CUR_SETVISIBILITY and
leave cursor->enable setting on accel_cursor's caller, it would
be even better.
And if we could change enable value to 0: disable; 1: enable;
2: disable due to blink (called from vbl), it would be even better,
as then fbdev which does hardware blinking could just completely
ignore changes which set only FB_CUR_SETVISIBILITY with enable == 2.
Petr Vandrovec
vandrove@vc.cvut.cz
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en