From: Antonino D. <ad...@po...> - 2003-03-26 11:34:58
|
On Wed, 2003-03-26 at 18:42, Petr Vandrovec wrote: > On 26 Mar 03 at 17:53, Antonino Daplas wrote: > > On Wed, 2003-03-26 at 13:34, James Simmons wrote: > > > > > > > 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... > The patch that I submitted to James does that already. > 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. Okay. Tony |