--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2004-05-18 at 01:13, Jon Smirl wrote:
> > 1) Boot console. This is implement via BIOS support. It is used to printk a
> > processor initialization failure or failure to find initramfs. Some embedded
> > systems might have to build one of these into the kernel but not a normal
> > desktop machine. This is the kind of console you use to write grub/lilo. It
> > looks like all non-86, non-Mac archs already have this.
>
> We can't use the BIOS that late. Currently the set up we have is that
> the normal console kicks in after PCI setup, and might be vga text mode,
> frame buffer or whatever. This is your "system console" and
> probably where predefined modes are used for nonvga devices, no
> acceleration and so on.
>
> We also have an early_vga PC console hack, and firmware console drivers
> that can kick in earlier (normally for debug) depending upon the
> platform. In the PC case the 16bit bios console services go away too
> early but EFI might provide help here if its ever adopted. Thats
> analogous to your bios console I guess ?
Boot console is a platform specific problem. It's only purpose is to get out an
error message saying that the system console can't be found or some other
similar type error.
> Agree with this level. The kernel provides the tty layer (Unix 98 ttys)
> and might need some userspace apps tweaking a little too - no big
> problems.
I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get
rid of the tty devices.
> > When User console is up it is using the full OpenGL driver. xserver would
> use
> > the same OpenGL driver. The User console app and xserver could even be the
> same
> > program. If User console/xserver dies, you can always user SAK to relaunch
> if it
> > doesn't happen automatically.
>
> s/OpenGL/Some drawing library/ - providing its using the kernel
> interfaces we don't care what. (eg the bogl console driver is very
> small, the opengl one would probably be rather larger and nicer)
I wasn't thinking that the kernel interface was standardized. For example DRM
has some common IOCTLs and then hundreds of per chipset ones. There is no
standard bitblt or draw char IOCTL.
I definitely don't want to try sharing the device driver on VT switch, that will
take us right back to where we are. Each device should have a single client
library driving it at a time. But this works if the program implement VT switch
is the owner of the device.
So you don't have any problem with pulling VT support out of the kernel?
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
