From: James Simmons <jsimmons@linux-fbdev.org>
To: Andrew Morton <andrewm@uow.edu.au>
Cc: Linux console project <linuxconsole-dev@lists.sourceforge.net>,
FrameBuffer List <linux-fbdev@vuser.vu.union.edu>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: fbdev cursor management
Date: Mon, 12 Mar 2001 00:42:11 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.31.0103120034300.1143-100000@linux.local> (raw)
>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
next reply other threads:[~2001-03-12 16:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-12 8:42 James Simmons [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-03-11 10:40 fbdev cursor management Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.31.0103120034300.1143-100000@linux.local \
--to=jsimmons@linux-fbdev.org \
--cc=andrewm@uow.edu.au \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-fbdev@vuser.vu.union.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxconsole-dev@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).