On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote:
> Would you consider it a good idea to make DRI part of the source of a
> kernel? Direct 3d graphics supported from the boot sequence.
Hmm I thought DRI is part of the kernel? Perhaps you meant the DRM part of it.
> I'm really concerned about your answer. There was a whole thread on
> the linux-kernel mailing list about the hypothesis of the release of
> an X-Kernel, a kernel which would include built-in desktop support.
I think it is a great idea to have a kernel implementation of Xserver. But it
would have to be more modular than current XF86, and also have a highly
flexible structure, so that adding new types of devices and functionality
wouldn't pose problems. I think this is currently the biggest XF86's drawback.
It would allow many cool things that XF86 is now struggling with (e.g. check
xpert mailing list for thread about precise vsync coordination).
Each device would have flags like:
- can the device serve as a keyboard?
- can the device serve as a pointer (mouse, joystick, touchpad, ...)
- can it be used for video output?
- can it grab/capture?
- can it convert between colorspaces?
- can it do DMA?
This would allow to write drivers easily and also support combined devices
(keyboard+touchpad, video+capture, ...).
Second: provide data structures
- keypress
- mouse movement
- image
- font
etc.
and hooks for these devices to:
- input data (e.g. keypress).
- output data (e.g. draw pixel)
- transfer data (from/to other devices, system RAM, etc).
- combination of those (e.g. transfer an image from system ram and draw it)
- process data internally (e.g. deinterlace?)
- report status (refresh rate, vertical retrace, ...)
- do something (e.g. wait for nth vsync)
(think ioctl). Currently in XF86 (IMHO) for each new type of use a new
standard has to be made. In this "ioctl" version you simply define a new value
and add a function to a driver that should do it. Other drivers, or older X
(as they would have something like "switch (ioctl) default: return
E_UNSUPPORTED;") will return an error, but nothing will crash or seize to
work.
Another thing is code reuse, so that several drivers can call generic
functions for doing the same thing (I think the "combination of transfer +
output" is a very good candidate for this). This is also a problem in XF86
imho.
> Most people answered, no, this would be ridiculous,
I wouldn't put it on a server there because imho server shouldn't even have a
monitor (mine don't). But for embedded and desktop, all way.
But supposing you want to use a graphical interface on a box, then this kind
of stuff simply DOES belong to the kernel (no I'm not an idiot and I don't
have MSWindows anywhere on my computers).
> other said, yes, but hardware manufacturers are too unhelpful therefore
> this would be totally a totally unstable release.
There isn't a reason why Xserver in kernel should be more unstable than
user-space Xserver. Both have direct access to all memory and hardware and can
lock up the machine.
One thing though: There should be an interface to reload a driver that is
currently in use, so that when developing it I wouldn't have to reboot
everytime I recompile it.
Oh and one more thing: the driver should autodetect if it is running on the
same videocard as the virtual terminal stuff, so that the first card will
simply open a new VT but secondary card will run independently of this VT
stuff. This would finally allow a decent way to concurrently run 2 separate X
sessions on the same machine using local hardware.
> Others said.. other various things.
Ok I'll check the thread.
> So, what do you think?
So, what do YOU think? :-)
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Reboot America.
PGP signature
