On Wed, 30 Apr 2008 09:43:31 +0200 Tom Cooksey <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 April 2008 17:29:24 Jerome Glisse wrote: > > For console we had the idea of building a full userspace console things > > instead of having this whole things in the kernel. Which would mean to > > write some userspace program using the modesetting API and providing > > the console. I believe there is several advantages (i talk about drawbacks > > latter) for instance you can do a fency console, or have multiple > > console at the same time by dividing screen, or have efficient multi-seat > > console with nice screen & input association. Well many things worth > > having for the XXI century where car flies and robots wash the house and > > do the laundry. > > I'm not sure I quite follow on the user-space console thing. Do you mean that > tty0-5 get removed & replaced with ptys? In fact the only real ttys left are > serial ports? A daemon process is created by init which opens the drm & input > devices, creates 6 or so ptys for each vt. It then implements a framebuffer > vt102 or something and lets init attach gettys or whatever to the slave ptys. > The daemon watches for Alt+Fx etc. and switches framebuffers & which pty > it sends keyboard input to. Have I understood correctly? It seems like vt's > become a completely user-space thing. This is great for console applications, > but what about graphics applications? Is that where this multi-master thing > comes in to play? Graphic applications like X are just another client and handled the same way. Some master will be in charge to switch btw terminal and X or others client. What i mean is that the console is a program in itself, different from the master and a client of it. > > Main drawback i see, is for rescue case, ie we likely need to keep a > > minimal console in kernel as in rescue we can't rely on userspace to > > be their or operational. Their is likely others drawback but none of > > importance come to my mind. > > There's also the boot splash before the kernel brings up userspace (although > I think userspace is brought up pretty quickly with initramfs). There's also > all the fbdev drivers, although I guess the user-space console could also > support the fbdev interface too. fbdev driver of drm supported card will be removed. Likely only keep a fbdev emulation layer in drm but i guess we highly prefer native drm user than one using such emulation layer. > > > > Anyway i believe such things need to be discused on lkml but as the API > > and things like multi-master, DRM2, ... are not yet worked out i believe > > its a bit too early to bring this topic on lkml (given that this might > > proove to lead to some nice flamewar :() Still you might be interested > > in writing a proof of concept user space console. Adapting it to > > API change won't be that hard. > > Yeah, you seem to be talking about some fairly major changes to Linux. > Where is all this discussion going on? Is there a DRI2 mailing list > somewhere? I'd quite like to follow what's being planned. I guess this are discussed on IRC but i think now most people are pretty agree with broadline of redesign. http://dri.freedesktop.org/wiki/DRMRedesign > As for userspace console, it seems fairly strait forward. I guess the easiest > thing would be to grab an existing terminal emulator which renders to a > framebuffer & adapt it? Either fbcon or something like rxvt/similar. Yes, i am confident that there is many code on which to build such things. Doing the drm kernel side is more cumberstone. Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
