OLS and console rearchitecture

OLS and console rearchitecture

[Jon Smirl]

After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal but there is still disagreement about the exact path to
get there.

This is a first pass for the fbdev/DRM people. I will incorporate
comments and repost to lkml for the final pass. I'm sure everyone will
let me know if I've misinterpreted some of the design points.

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.

1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
track the boot video device and expose the contents of C000:0 for that
special case.

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.

3) Secondary card reset - Handled by an initial hotplug event. We need
a volunteer to write clean vm86 and emu86 apps for running the ROM
initialization. Resetting needs #1 and #2 to work since resetting a
card will enable it's VGA mode. I have an implementation of this but it
needs a lot of clean up.

4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.

5) Multihead cards will expose one device file per head. Many IOCTLs
exposed by these devices will be common. Some, like mode setting, will
be per head.

6) Mode setting before early user space - this was decided to be a
platform specific problem. With minor adjustment the kernel can be made
to boot without printing anything except errors before early user space
starts. Platform specific code will need to handle these error messages
if any. This includes INT10, Openfirmware, mainframe serial consoles,
VGA mode. Suppressing informatory printing before early user space
starts allows a clean boot straight into graphics mode.

7) Mode setting from normal user space - devices will have a standard
IOCTL accepting a mode string like fbdev currently uses. This IOCTL
will lock the device and optionally trigger a hotplug mode event. Mode
setting for some fixed devices is simple enough to avoid the hotplug
event. In the hotplug event the mode line will be decoded, DDC queried,
etc. Some classes of devices (for example Intel 810,830,915) have to
have their mode set using vm86 and the video BIOS. Others might use a
small C app to query DDC and then use a device specific IOCTL to set
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).

8) Merged fbmode - per head mode lists will include merged fb modes if
the other heads aren't in use. Setting a merged fb mode will lock out
the other head devices. It was decided that this was a better design
than having a control device.

9) printk - setting the mode will also record the fb location, size,
stride. Combining this info with the current fbconsole code will allow
printk/oops to print in all modes.

10) a new system console UI is proposed. SysReq blanks the current
screen and replaces it with the system console. System console will
also support runing kdbg. Hit SysReq again and whatever you were doing
is restored. This operation does not change the video mode.

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.

12) interrupt time printk - certain hardware implements
non-interruptible operations. Most modern hardware does not do this.
For older hardware these non-interruptible operations will need to be
wrapped by the device driver. The complete data needed to finish the
operation will be provided in the IOCTL. Doing this enables an
interrupt time printk to call into the driver, make sure the hardware
is free by completing the pending operation, and then write to the
framebuffer. No older hardware currently implements this protection;
without this protection there is potential for locking the machine.

13) all of the features being discussed are implemented by a single
device driver plus a supporting set of library drivers. Multitasking of
multiple controlling device drivers for a single piece of hardware is
not allowed.

14) A new framebuffer memory manager is needed for mesa GL support. Ian
is working on it. The memory manager will be part of the support
library driver code. 

15) Over time user space console will be moved to a model where VT's
are implemented in user space. This allows user space console access to
fully accelerated drawing libraries. This might allow removal of all of
the tty/vc layer code avoiding the need to fix it for SMP.

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.

17) A user space console implementation also makes supporting multiple
users on multiple heads/card easier. The kernel will not need to be
modified for multi-user VT support. User mode console allows pretty
text and Asian scripts.

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.

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

20) A PAM login would assign ownership of the console group devices to
the logged in user. A mechanism needs to be designed for assigning
ownership of secondary heads for the merged fb case. X should run as
the logged in user and not require root if the hardware allows.

21) It was also discussed the X should stop implementing OS level
features and instead use the features of the underlying OS. If the
underlying OS is lacking support the support would be implemented in a
library external to X. Examples of moving from X to OS support include:
PCI bus, input, console groupings, etc.

22) A goal this design is to discourage user space video driver
implementations when a kernel one exists. An example of this would be
X's radeon XAA driver. X would instead use the DRM driver via mesa.

23) The old schemes are not going to be removed. If your ancient 2D
card only has an fbdev and XAA driver it will still work. We're not
going to remove old drivers if new ones don't exist. But don't expect
the composting X server to turn your clunker 2D card in to a Radeon
X800.



=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
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
--

Re: OLS and console rearchitecture

[Alan Cox]

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
--

Re: OLS and console rearchitecture

[Kronos]

Hi Jon

Il Wed, Jul 28, 2004 at 11:53:46AM -0700, Jon Smirl ha scritto: 
> 3) Secondary card reset - Handled by an initial hotplug event. We need
> a volunteer to write clean vm86 and emu86 apps for running the ROM
> initialization.

There was a thread on acpi-devel about POSTing VGA ROM after resume:

http://marc.theaimsgroup.com/?l=acpi4linux&m=109023076427394&w=2

The code does a real mode switch in kernel and execute the ROM. Ok, doing
that in userspace is more elegant, but that code is not a mess (though
it's arch dependant).
 
Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that
there's x86 code in their ROM...

> 7) Mode setting from normal user space - devices will have a standard
> IOCTL accepting a mode string like fbdev currently uses.

sysfs? I sent a patch a while ago but didn't get much feedback.

> 14) A new framebuffer memory manager is needed for mesa GL support. Ian
> is working on it. The memory manager will be part of the support
> library driver code.

sisfb has a memory manager for fb/drm, it may be worth a closer look.

Luca
-- 
Home: http://kronoz.cjb.net
La differenza fra l'intelligenza e la stupidita`?
All'intelligenza c'e` un limite.


-------------------------------------------------------
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

Re: [Linux-fbdev-devel] OLS and console rearchitecture

[Alan Cox]

On Mer, 2004-07-28 at 22:31, Kronos wrote:
> There was a thread on acpi-devel about POSTing VGA ROM after resume:
> 
> http://marc.theaimsgroup.com/?l=acpi4linux&m=109023076427394&w=2
> 
> The code does a real mode switch in kernel and execute the ROM. Ok, doing
> that in userspace is more elegant, but that code is not a mess (though
> it's arch dependant).

And also some cards do rather deep magic or don't even have a real
video ROM but a BIOS hack that goes away. This got discussed - its fun

> Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that
> there's x86 code in their ROM...

Same way X does - x86emu

> > 7) Mode setting from normal user space - devices will have a standard
> > IOCTL accepting a mode string like fbdev currently uses.
> 
> sysfs? I sent a patch a while ago but didn't get much feedback.

How do you atomically tie sysfs objects to fbdev and X permissions
models ?

> > 14) A new framebuffer memory manager is needed for mesa GL support. Ian
> > is working on it. The memory manager will be part of the support
> > library driver code.
> 
> sisfb has a memory manager for fb/drm, it may be worth a closer look.

Its way too slow and doesn't deal with a lot of things it should, its a
problem even on DRI today. Ian has some design for a mostly user space
allocator which is critical as DRI can hit 100K allocs/second.




-------------------------------------------------------
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
--

Re: [Linux-fbdev-devel] OLS and console rearchitecture

[Jon Smirl]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > sysfs? I sent a patch a while ago but didn't get much feedback.
> 
> How do you atomically tie sysfs objects to fbdev and X permissions
> models ?

I think the plan here is for ROM export to be implemented by the PCI
driver not the video ones since other things besides video cards have
ROMs. For example some SCSI cards have a ROM so they can be boot
devices. Reading the ROM from sysfs will require root. But since all of
the hotplug events run in root context this is not a problem.

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
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
--

Re: [Linux-fbdev-devel] OLS and console rearchitecture

[Ian Romanick]

Alan Cox wrote:

> On Mer, 2004-07-28 at 22:31, Kronos wrote:
> 
>>Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think that
>>there's x86 code in their ROM...
> 
> Same way X does - x86emu

I think he meant using OpenFirmware video cards on x86 boxes.  Does 
x86emu take care of that?  In any case, that's probably much less common 
than people wanting to use x86 cards on OpenFirmware systems.




-------------------------------------------------------
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
--

Re: OLS and console rearchitecture

[Jon Smirl]

I asked this at OLS and no one knew of an open source x86 Open Firmware
emulator.

99% of the time it is people wanting to use cheap x86 cards in Open
Firmware systems to avoid having to pay $$ for those added valued ROMs.

--- Ian Romanick <idr@us.ibm.com> wrote:

> Alan Cox wrote:
> 
> > On Mer, 2004-07-28 at 22:31, Kronos wrote:
> > 
> >>Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think
> that
> >>there's x86 code in their ROM...
> > 
> > Same way X does - x86emu
> 
> I think he meant using OpenFirmware video cards on x86 boxes.  Does 
> x86emu take care of that?  In any case, that's probably much less
> common 
> than people wanting to use x86 cards on OpenFirmware systems.
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 


=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
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

Re: OLS and console rearchitecture

[Geert Uytterhoeven]

On Wed, 28 Jul 2004, Jon Smirl wrote:
> I asked this at OLS and no one knew of an open source x86 Open Firmware
> emulator.

How do the NetBSD guys handle it? I heard (at OLS :-) they do run OF ROMs.

> --- Ian Romanick <idr@us.ibm.com> wrote:
> > Alan Cox wrote:
> > > On Mer, 2004-07-28 at 22:31, Kronos wrote:
> > >>Btw, how do we POST non-x86 (eg. ppc) video boards? I don't think
> > that
> > >>there's x86 code in their ROM...
> > >
> > > Same way X does - x86emu
> >
> > I think he meant using OpenFirmware video cards on x86 boxes.  Does
> > x86emu take care of that?  In any case, that's probably much less
> > common
> > than people wanting to use x86 cards on OpenFirmware systems.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: OLS and console rearchitecture

[Kronos]

Il Wed, Jul 28, 2004 at 11:57:59PM +0100, Alan Cox ha scritto: 
> 
> > > 7) Mode setting from normal user space - devices will have a standard
> > > IOCTL accepting a mode string like fbdev currently uses.
> > 
> > sysfs? I sent a patch a while ago but didn't get much feedback.
> 
> How do you atomically tie sysfs objects to fbdev and X permissions
> models?

It's not atomic right now, the attribute is attached to a class_device
object after register_framebuffer (which init & register the
class_device). Is this a problem?

Luca
-- 
Home: http://kronoz.cjb.net
Windows NT crashed.
I'm the Blue Screen of Death.
No one hears your screams.


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: OLS and console rearchitecture

[Jon Smirl]

There is a big thread about this on lkml currently.

--- Kronos <kronos@people.it> wrote:

> Il Wed, Jul 28, 2004 at 11:57:59PM +0100, Alan Cox ha scritto: 
> > 
> > > > 7) Mode setting from normal user space - devices will have a
> standard
> > > > IOCTL accepting a mode string like fbdev currently uses.
> > > 
> > > sysfs? I sent a patch a while ago but didn't get much feedback.
> > 
> > How do you atomically tie sysfs objects to fbdev and X permissions
> > models?
> 
> It's not atomic right now, the attribute is attached to a
> class_device
> object after register_framebuffer (which init & register the
> class_device). Is this a problem?
> 
> Luca
> -- 
> Home: http://kronoz.cjb.net
> Windows NT crashed.
> I'm the Blue Screen of Death.
> No one hears your screams.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks?
> Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 


=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com