From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sun, 7 Feb 1999 06:52:18 +0100 (MET)

Re: [linux-fbdev] Accel or not accel in kernel! (fwd)

Hi !

> Yes accels do not belong in fbcon! Here are my reasons.

> 1: 
>   Not every video card supports accels but every video card does support
>   setting at least one mode. This is the true purpose of fbdev. I know one
>   fear was the scattered accel API mess and what if people wanted to use
>   software accels in the kernel to make their cards behave like true HW
>   accelerated cards. 

This is nonsense, and people should know that it is. DON'T put software
"acceleration" in the kernel. That's really useless.

>   Its shouldn't have to handle this. Also what about video cards that
>   support accels but not framebuffers. 

How do you propose to set modes on these. In 1. you said, that is the
purpose of fbcon.

>   As you can see you have to open fb again to just use accels to avoid
>   the overhead of going threw Xlib. This also binds the accels API to
>   fbcon and not every card has accels and not every card that has accels
>   has a framebuffer.

So what ? If you open /dev/fb or /dev/gfx, what's the difference ?

>   Regular app in X -> Xlib -> Xserver -> fbdev or some other device.
>   Regular app in X -> Xlib -> Xserver -> X server wants to use /dev/gfx
>                                          for things like blits to move
>                                          windows fast. Independent of app
>                                          and if X uses fbdev or some other
>                                          device to set a mode.
>   Graphics app in X -> hit /dev/gfx directly for speed. 
>   Graphics app not in X -> hit /dev/gfx directly for speed.

Note the complexity behind that model: 

To do it _right_, like SGI does, you need to virtualize /dev/gfx on a
_per_window_ base. This is very messy stuff with most PC hardware.

And /dev/gfx would have to be able to distinguish between a "session
leader", the X server, that has enhanced access to stuff like clipping,
and the "clients", that have somewhat reduced access.

Also note, that you will _still_ need to map the framebuffer usually, as
it still is the fastest way to do stuff like paining small icons or text
or similar things.

Thus I rather suggest to integrate it with /dev/fb.

> As you can see the SGI model has its strong points. With this model fbcon
> will never hear about accels again. Does this purposal sound like
> something everyone can live with?

I can live with it, but it's adding additional overhead. Something that
should be avoided IMHO.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =