linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zack <plinius@comcast.net>
To: adaplas@pol.net
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: framebuffer ioctl
Date: Mon, 06 Sep 2004 12:56:26 -0700	[thread overview]
Message-ID: <413CC0EA.8070709@comcast.net> (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. 
>
>Possibly, the only drawing function that can be used by userspace is copyarea 
>(bitblt).  Fillrect (color fill) and imageblit (color expand) cannot be used 
>since they rely on pseudo_palette which is limited to 16 colors.
>
>I believe that the kernel framebuffer should only support features that cannot 
>be done in user space, such as interrupt handling.  I really recommend to 
>concentrate on one library (I recommend DirectFB) and enhance that.
>
>Note that the framebuffer ABI is quite consistent since its inception. So you 
>can rely on libraries based on fbdev, ie DirectFB, even X, to consistently 
>work with whatever version of the kernel.
>
>Tony
>
I think you may be misinterpreting my intent. I am strictly anti-bloat,
so I don't want a larger kernel. By the same token, I don't use
X because it is bloated--X uses 16 megs minimum on my system,
and that is very much not to my taste.

Directfb seems geared toward being overly impressive,
which says to me that if it's not bloated already, it will be later.

My new routines are small.

>I believe that the kernel framebuffer should only support features that cannot 
>be done in user space, such as interrupt handling.  I really recommend to 
>concentrate on one library (I recommend DirectFB) and enhance that.


For other people reading this, the idea of putting everything into
userspace that can be put there is called an "exokernel" approach.
It's a matter of taste. To me it's just another way bloat is achieved.

Zack



-------------------------------------------------------
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

  parent reply	other threads:[~2004-09-06 19:56 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
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 [this message]
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=413CC0EA.8070709@comcast.net \
    --to=plinius@comcast.net \
    --cc=adaplas@pol.net \
    --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).