[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

kernel graphics support (was: XFree86 4.0.1 works!)

nisse@lysator.liu.se (Niels Möller) writes:

> To get this right, one have to use some kind of frame buffer device
> instead of having the X server bang directly on the hardware. All
> Unices I've heard of have got this for ages, except Linux on PC
> hardware (not sure about the *bsd:s on PC hardware, though).

It's more a misfeature of PC hardware. On most other architectures you
have no choice, Only the PC still uses text mode as a performance
hack. It would indeed be interesting how other PC Unices do it,
especially things like Solaris that sprang from fb-only platforms.

> I believe things are getting better, but I haven't followed the
> linux framebuffer stuff and kgi closely enough to know.

Well, I'm using vesafb right now, which supports a wide range of
graphic cards. OTOH, it doesn't protect me from X crashes, because I
still use the normal X server, bypassing the framebuffer device. The
fbdev server can't do mode-switches with vesafb, and I think it is
still unaccelerated. So the problem under Linux is that you can still
access the bare hardware, with the expected consequences on crashes.

> You have the choice of putting the hardware-banging code into the
> kernel (like in those Linuxes that have /dev/fb), or putting it in
> some user-level process/translator. If you choose the second
> alternative, you still won't have much help from the kernel if the
> user-space program crashes, you have just moved the problem from the X
> server to some other user-level program.

The theory goes, that a smaller program should crash less often. While
the XFree86 people do a tremendous job in keeping the X server from
crashing, those things happen (more often in the case of version 4).

The rough picture I have looks like this:

A translator exist that regulates access to the video hardware. It
will take responsibility over the hw on bootup, when it is in a
defined state. Whenever a program (X server, but also /hurd/term)
wants to own the screen, it must request that from the video
translator, which hands out means to talk to the hw (mapped video
memory, io ports, ...) and keeps a channel open to the client program.
Some sensitive operations (e.g. changing video mode) must not be done
directly, but through the video translator[1]. When the program closes
the communication channel (because of a normal or abnormal
termination), the translator considers the client done, and puts the
previous owner into power again, resetting video mode et al to old

It should also be possible to build a protocol for changing ownership
between multiple active clients for the implementation of virtual
consoles. This may even be a pre-emptive model (it is cooperative
under Linux AFAIK).

[1]  Ideally, these operations are prohibited by the hardware (e.g.
access to some card registers is not allowed), when possible.
Otherwise, misbehaving programs may still wreak havoc. The chance of a
crashing program overwriting an unrecoverable value is nevertheless
smaller than failing to do proper de-initialization.


Attachment: signature.ng
Description: PGP signature

Reply to: