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? > 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. > > 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. 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. Thanks for the info! Cheers, Tom ------------------------------------------------------------------------- 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
