Messages in this thread |  | | | Date | Mon, 12 Mar 2001 00:42:11 -0800 (PST) | | From | James Simmons <> | | Subject | Re: fbdev cursor management |
| |
>Guys, > >I've been taking a look at the cursor flashing code, >from the point of view of how it's affected by the >recent enabling of interrupts across the console code.
I see the problems. I just pursposed a new cursor api soe we can have a clean fbdev to fbcon abstraction. Also we really need to move the curent cursor code in fbcon.c:fbcon_startup. They really belong in their respected drivers.
>It all happens in timer handlers and interrupt handlers, >with no protection against mainline code accessing the >hardware simultaneously.
Many drivers use spinlocks to manage access.
>- Collapse all the various per-driver cursor flashing > routines into a single place - manage the timer from > drivers/video/fbcon.c and from there, call into the > driver layer if requested.
fbcon_cursor :-)
> The only way we have of doing this at present is to call > schedule_task() from within the timer handler. This works > fine, but it complicates the device close and module unload > problem somewhat. del_timer_sync + flush_scheduled_tasks > will be needed in the right places.
Yuck!!! I see this also a problem for VBL dependent drivers. Some drivers to require you sync with the VBL to do things like change the color map. Worst some of these drivers require you poll a bit to see if the VBL occured.
[snip] rivafb problems. These will be fixed now they are pointed out.
MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@linux-fbdev.org] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net - 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/
|  |