linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: James Simmons <jsimmons@infradead.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Frame Buffer Device Development
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: const fb_{fillrect,copyarea,image}?
Date: 10 Jan 2003 18:28:38 +0800	[thread overview]
Message-ID: <1042181502.933.301.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0301091814550.5660-100000@phoenix.infradead.org>

On Fri, 2003-01-10 at 02:16, James Simmons wrote: 

>  
> > BTW, is it possible that someone passes data that is larger (except for bugs)?
> > We have control over what happens in the kernel. Data passed from userspace is
> > a different issue, of course.
> 
> Yes. Soon the standard ioctl for a cursor will be truly in place. This 
> means cfb_imageblit could be a issue from userland.
> 
If you are going to export the cursor API to userland, then soft_cursor
is useless, because it implies that we always have a copy of the screen
under the cursor (so we can restore it when we move the cursor) and it
also implies that fb_imageblit can support transparency (so the mask
bits will work).  For soft cursors, the userland has to take care of it.

For those with hardware cursors, this is exportable to user space. 

The structure fbcursor has one field that is console specific
fbcursor.dest which we basically use to invert the cursor image.  So the
structure that is passed via the cursor ioctl will be slightly
different, it should not have the 'dest' field.  So when it gets passed
to fb_cursor(), dest == NULL.  Then this is how drivers can respond: 

1. soft_cursor - if cursor->dest == NULL, always exit with an error. 

2. hardware cursors which cannot do invert - if cursor->dest == NULL and
rop == ROP_XOR, exit with an error, otherwise (ROP_COPY), proceed. 

3. hardware cursors with invert - cursor->dest will be ignored so it has
full support. 

The rivafb_cursor() and i810fb_cursor() already behaves like #2 already.

Anyway, inverting the cursor image is not commonly used in GUI apps.
Typically, they just need an opaque cursor + a transparency mask to
"shape" the cursor. 

Tony  





-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

      reply	other threads:[~2003-01-10 10:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-30 10:31 const fb_{fillrect,copyarea,image}? Geert Uytterhoeven
2003-01-07 21:21 ` James Simmons
2003-01-07 21:31   ` Geert Uytterhoeven
2003-01-09 18:16     ` James Simmons
2003-01-10 10:28       ` Antonino Daplas [this message]

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=1042181502.933.301.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=geert@linux-m68k.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@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).