From: Antonino Daplas <adaplas@pol.net>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: James Simmons <jsimmons@infradead.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BK FBDEV] A few more updates.
Date: 26 Mar 2003 19:20:19 +0800 [thread overview]
Message-ID: <1048677567.1025.64.camel@localhost.localdomain> (raw)
In-Reply-To: <84D3825146@vcnet.vc.cvut.cz>
On Wed, 2003-03-26 at 18:42, Petr Vandrovec wrote:
> On 26 Mar 03 at 17:53, Antonino Daplas wrote:
> > 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.
>
> accel_cursor unconditionally sets FB_CUR_SETPOS. Can you write it
> down to the TODO list to eliminate this? Cursor position lives
> in different registers than cursor enable/disable on my hardware...
>
The patch that I submitted to James does that already.
> And if we could rename FB_CUR_SETCUR to FB_CUR_SETVISIBILITY and
> leave cursor->enable setting on accel_cursor's caller, it would
> be even better.
>
> And if we could change enable value to 0: disable; 1: enable;
> 2: disable due to blink (called from vbl), it would be even better,
> as then fbdev which does hardware blinking could just completely
> ignore changes which set only FB_CUR_SETVISIBILITY with enable == 2.
Okay.
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
WARNING: multiple messages have this Message-ID (diff)
From: Antonino Daplas <adaplas@pol.net>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: James Simmons <jsimmons@infradead.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Linux-fbdev-devel] [BK FBDEV] A few more updates.
Date: 26 Mar 2003 19:20:19 +0800 [thread overview]
Message-ID: <1048677567.1025.64.camel@localhost.localdomain> (raw)
In-Reply-To: <84D3825146@vcnet.vc.cvut.cz>
On Wed, 2003-03-26 at 18:42, Petr Vandrovec wrote:
> On 26 Mar 03 at 17:53, Antonino Daplas wrote:
> > 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.
>
> accel_cursor unconditionally sets FB_CUR_SETPOS. Can you write it
> down to the TODO list to eliminate this? Cursor position lives
> in different registers than cursor enable/disable on my hardware...
>
The patch that I submitted to James does that already.
> And if we could rename FB_CUR_SETCUR to FB_CUR_SETVISIBILITY and
> leave cursor->enable setting on accel_cursor's caller, it would
> be even better.
>
> And if we could change enable value to 0: disable; 1: enable;
> 2: disable due to blink (called from vbl), it would be even better,
> as then fbdev which does hardware blinking could just completely
> ignore changes which set only FB_CUR_SETVISIBILITY with enable == 2.
Okay.
Tony
next prev parent reply other threads:[~2003-03-26 11:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-26 10:42 [BK FBDEV] A few more updates Petr Vandrovec
2003-03-26 10:42 ` [Linux-fbdev-devel] " Petr Vandrovec
2003-03-26 11:20 ` Antonino Daplas [this message]
2003-03-26 11:20 ` Antonino Daplas
-- strict thread matches above, loose matches on Subject: below --
2003-03-26 10:53 Petr Vandrovec
2003-03-25 18:32 James Simmons
2003-03-25 18:32 ` James Simmons
2003-03-25 18:01 ` Russell King
2003-03-25 18:28 ` Benjamin Herrenschmidt
2003-03-25 18:28 ` Benjamin Herrenschmidt
2003-03-25 18:35 ` Benjamin Herrenschmidt
2003-03-25 18:35 ` Benjamin Herrenschmidt
2003-03-25 19:48 ` James Simmons
2003-03-25 19:48 ` James Simmons
2003-03-25 20:10 ` Benjamin Herrenschmidt
2003-03-25 20:10 ` Benjamin Herrenschmidt
2003-03-25 20:14 ` James Simmons
2003-03-25 18:44 ` James Simmons
2003-03-25 18:44 ` James Simmons
2003-03-26 3:37 ` Antonino Daplas
2003-03-26 5:34 ` James Simmons
2003-03-26 9:53 ` Antonino Daplas
2003-03-26 10:20 ` Antonino Daplas
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=1048677567.1025.64.camel@localhost.localdomain \
--to=adaplas@pol.net \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vandrove@vc.cvut.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.