All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: fb-devel <linux-fbdev-devel@lists.sourceforge.net>,
	DRI Devel <dri-devel@lists.sourceforge.net>
Subject: Re: OLS and console rearchitecture
Date: Wed, 28 Jul 2004 21:10:18 +0100	[thread overview]
Message-ID: <1091045416.31698.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20040728185346.36263.qmail@web14921.mail.yahoo.com>

On Mer, 2004-07-28 at 19:53, Jon Smirl wrote:
> First a basic definition. There are two consoles, the kernel one
> (printk, kdbg, OOPs, etc) and user one (normal console logins). There
> is no requirement that these consoles be handled with the same code
> even though they are today.

Not sure that was consensus 8)

> 2) VGA control - there needs to be a device for coordinating this. It
> would ensure that only a single VGA device gets enabled at a time. It
> would also adjust PCI bus routing as needed. It needs commands for
> disabling all VGA devices and then enabling a selected one. This device
> may need to coordinate with VGA console. You have to use this device
> even if you aren't using VGA console since it ensures that only a
> single VGA device gets enabled.

Some vendors have multiple vga routers according to bus, unclear how
much we care however.

> the mode registers. Early boot and normal user space will use the same
> hotplug apps so they need to be as small as possible (good luck IA64
> and emu86).

IA64 has EFI to get it up initially.

> 11) OOPs will cause an immediate screen clear and painting of the
> system console including the OOPs data. It is not needed to change the
> video mode. Further drawing to the screen will be blocked until SysReq
> returns to normal operation if possible.

No consensus on the screen clear bit - there are actually reasons to
argue against it.

> 16) accelerated, kernel based console drivers are not supported in this
> model. The only in kernel operations are simple ones like CR/scroll,
> clear, print text. It is possible to call existing DRM entry points
> from a kernel thread, but the code needed is complex.

Its not "unsupported" its merely potentially hard because an accelerated
driver may well have to be a DRI client.

> 18) A coordinated system for grouping console devices needs to be
> designed. This will be bad if each distro does it differently. One
> proposal is to use udev to create: /console/1/mouse,
> /console/1/keyboard, /console/1/usb_hub, /console/2/mouse,
> /console/3/keyboard, /console/4/usb_hub, etc.

Another is to use namespace mounts

> 19) SAK - secure attention key. We forgot to talk about this so we need
> a design.

Falls straight out of having the kernel + helper mode setting



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
--

  reply	other threads:[~2004-07-28 20:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28 18:53 OLS and console rearchitecture Jon Smirl
2004-07-28 20:10 ` Alan Cox [this message]
2004-07-28 21:31 ` Kronos
2004-07-28 22:57   ` [Linux-fbdev-devel] " Alan Cox
2004-07-29  0:23     ` Jon Smirl
2004-07-29  0:44     ` Ian Romanick
2004-07-29  1:19       ` Jon Smirl
2004-07-29  8:34         ` Geert Uytterhoeven
2004-07-30 22:19     ` Kronos
2004-07-30 23:31       ` Jon Smirl
  -- strict thread matches above, loose matches on Subject: below --
2004-08-02 14:24 Jon Smirl
2004-08-02 14:54 ` Alexander E. Patrakov
2004-08-02 16:07   ` Miquel van Smoorenburg
2004-08-02 16:21     ` Andreas Schwab
2004-08-02 17:40       ` Alan Cox
2004-08-03  8:44         ` Andreas Schwab
2004-08-02 16:16   ` Jon Smirl
2004-08-05 11:08     ` Martin Waitz
2004-08-02 18:33 ` Jesse Barnes
2004-08-03  0:01   ` Benjamin Herrenschmidt
2004-08-05  8:56 ` Helge Hafting
2004-08-05 20:32   ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1091045416.31698.13.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.