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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/