From: Otto Wyss <otto.wyss@orpatec.ch>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: framebuffer ioctl
Date: Mon, 06 Sep 2004 17:36:23 +0200 [thread overview]
Message-ID: <413C83F7.D4CB1EAD@orpatec.ch> (raw)
In-Reply-To: 200409060926.07163.adaplas@hotpop.com
"Antonino A. Daplas" wrote:
>
> On Monday 06 September 2004 01:13, Zack wrote:
> > 4. new features would be optional anyway: fullscreen-guis need not
> > recognize their existence, but would benefit from doing so
> > since some fb drivers would override the generic routines
> > to implement accelerated routines.
> >
>
> One of the limitations of the in-kernel drawing routines is that they were
> never designed to be used in user space. This has been discussed a long time
> ago so that the upper layer need not know the characteristics of the
> low-level driver.
>
I'm neither pro nor contra moving drawing routines into the kernel but
this has to be discussed and written down.
The question is not if its kernel or user space but what functionality
has to be provided by a graphic driver. I don't care if it's a
monolithic solution or if it's divided into user and kernel part but
it's necessary that this is now nailed down so anyone can use this API
and work on a common goal. Also it makes it easier to code drivers when
everything is collected into on place.
O. Wyss
--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
next prev parent reply other threads:[~2004-09-06 15:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 11:04 framebuffer ioctl (fwd) Geert Uytterhoeven
2004-09-04 21:44 ` Otto Wyss
2004-09-05 17:13 ` framebuffer ioctl Zack
2004-09-06 1:33 ` Antonino A. Daplas
2004-09-06 15:36 ` Otto Wyss [this message]
2004-09-06 21:21 ` Antonino A. Daplas
2004-09-06 21:58 ` Zack
2004-09-06 23:05 ` Antonino A. Daplas
2004-09-06 19:56 ` Zack
2004-09-06 21:02 ` Jon Smirl
2004-09-06 21:11 ` [OT] " Otto Solares
2004-09-06 21:39 ` Jon Smirl
2004-09-07 0:01 ` Otto Solares
2004-09-07 0:11 ` Jon Smirl
2004-09-06 21:24 ` Michel Dänzer
2004-09-07 14:17 ` Jon Smirl
2004-09-07 14:26 ` Geert Uytterhoeven
2004-09-07 14:38 ` Jon Smirl
2004-09-07 15:58 ` Otto Wyss
2004-09-07 14:45 ` Jon Smirl
2004-09-07 15:52 ` Michel Dänzer
2004-09-08 5:43 ` Jon Smirl
2004-09-08 13:59 ` Ville Syrjälä
2004-09-08 22:47 ` Jon Smirl
2004-09-13 15:54 ` vga softboot code repository Richard Smith
2004-09-13 16:00 ` vga softboot code repository oops Richard Smith
2004-09-13 16:06 ` vga softboot code repository Jon Smirl
2004-09-06 18:43 ` framebuffer ioctl Otto Solares
2004-09-06 19:08 ` Jon Smirl
2004-09-06 19:24 ` Otto Solares
2004-09-06 19:33 ` Jon Smirl
2004-09-07 15:48 ` Otto Wyss
2004-09-07 16:01 ` Jon Smirl
2004-09-07 18:09 ` Otto Solares
2004-09-06 19:33 ` Jon Smirl
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=413C83F7.D4CB1EAD@orpatec.ch \
--to=otto.wyss@orpatec.ch \
--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).