Re: fbdev cursor management

[James S. <jsi...@li...>]

>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  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net