[Xorg] Kernel Summit and console design

[Alan Cox]

On Iau, 2004-07-15 at 11:24, Egbert Eich wrote:
> - The entire 2D code could be put into the kernel so it could be dealt with
>   the same way - not my favorite solution and not feasable for the range
>   of HW that is in use.

This pretty much essential for many non PC users so the code already
generally exists for bitmapped framebuffers in the kernel. It doesn't
need and frequently doesn't know any more about accelerators than to
wait for it.

>  > Now working from this assumption, the video driver must have a kernel
>  > entry point for drawing to the screen. This entry point has to be
>  > optionally able to force itself onto the screen.
> 
> Why? 
> The framebuffer is just a range in the memory address space of the
> kernel. So it can write to it whatever it wants. 

Not every framebuffer or similat device fits this description. In
essence you need chip specific function entry points for a lot of the
2D text rendering work. For almost all cards they happen to point to
the same functions

> 1. Keep track of which device currently has VGA access.
> 2. Control VGA access (bus routing etc).
> We probably want to do 1. in user space while 2. could be handled
> in kernel space.

#1 has to be partly in kernel space the moment there are multiple
independant X servers or other display engines around. hotplug, sak,
and the kernel itself may well be involved in wanting to touch VGA
register space.