On Wednesday 30 April 2008 10:59:03 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.
Ok... I think I see what you're getting at... So init launches this all-powerful master process as root, then launches 6 console processes, (one for each virtual console) as a non-root user. Each console process connects to the master (using sockets? DBus?), some authentication goes on to make sure they're allowed to access the DRM. The console process then opens the DRM, sets up a BO for the scan-out buffer & creates a psudo-terminal pair, with the slave end dangling ready to be attached to getty. The all-powerful master tells the console process it is now the current vt and can attach its scan-out buffer(s) to any crtc it is allowed to. When the user initiates a vt-switch, the master tells the console it is no-longer the current vt and should detach it's scanout buffer so the new current slave can attach it's scan-out buffer instead. > > > 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. I'm just thinking about how this is going to work on non-DRM graphics devices, where the driver is fbdev, DirectFB, proprietry, etc. Of course if there's a DRM driver, the DRM modesetting API sould be used. But the fbdev driver could potentially be used if DRM is unavaliable. In a perfect world, there would only be DRM. Actually I'm thinking about taking a look at writing a drm modesetting driver for very stupid hardware like an OMAP3 LCD controller. Everything, including the framebuffer & BOs would be stored in main memory as that's all these devices have! Could then look at how to handle video decoded by the OMAP's DSP in a DRM-friendly way. 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
