Re: [BK FBDEV] A few more updates.

[Antonino Daplas <adaplas@pol.net>]

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.

But what I really meant was since accel_cursor() is already doing the
memory bookkeeping, why let softcursor do it too?  We can all do these
in the upper layer.

This is especially true if you are planning to expose cursor handling to
user space.  For example, softcursor refers to fields in
fb_info.fb_cursor, but this is a structure private to the driver. 
Worse, it refers to both the passed fb_cursor structure and the
fb_info.fb_cursor structure. Why not just make softcursor refer entirely
to the passed fb_cursor structure?  It's saner, less confusing and less
prone to bugs.  

Tony
 




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