On Tue, 29 Apr 2008 15:08:12 +0200 Tom Cooksey <[EMAIL PROTECTED]> wrote:
> I've started playing with the modesetting branch of DRM and managed to get it > to work on my GMA 965 based laptop (after working out I needed to pass > modeset=1 as a parameter to the i915 module). > > On my laptop, I get /dev/fb0 & /dev/fb1, with /dev/fb0 connected to my laptop > screen (LVDS?) and fb1 connected to VGA out. I can successfully run > Qt/Embedded on fb1 (using the normal fbdev interface... not started writing > drm modesetting code yet). > > What would be nice is to have a tool like fbset which not only sets the mode, > but also chooses which crtc (correct terminology?) is connected to which > framebuffer. On the OMAP framebuffer, this can be controlled through a sysfs > interface. > > However, my understanding is that the i915 driver provides a linuxfb > emulation > driver it registers with the kernel during probe? The fbcon then binds to the > (first) fbdev device? So the tool would in fact just configure i915's linuxfb > emulation and not be very useful or portable. Have I understood things > correctly? > > I'm getting a bit confused about how things should look inside the kernel > (This is mainly because I'm having a hard time working out how consoles, > virtual terminals & vt-switching fit together... but I'm picking it up > bit-by-bit). It seems to me that a completely new console driver needs to be > written which uses the drm modesetting interface, rather than the fbdev > interface? So the tool to set modes & change crtcs would only talk to the > console driver. > > User-space applications like X & Qt/Embedded seem pretty strait-forward. They > just use mode setting functions in libdrm. I.e. They provide their own way of > configuring which output goes to which crtc. What about vt-switches? Will an > application still be responsible for re-drawing itself after a vt-switch? Or > will vt-switches now become completely transparent to userspace applications? > > > Please let me know what I've got wrong. Eventually, I'd quite like to have a > go at writing some in-kernel stuff using the drm. If there's any boring > low-hanging fruit I could start to learn on, let me know (like an fbset-like > utility). > > > Cheers, > > Tom Modesetting API is not set in rock and i believe their is plan to make some modifications to it. My last understanding (as things move quickly in this area this might be as outdated as stone age) is that the drm rework (DRM multi-master things) will significantly impact this modesetting things. IIRC we want to have a master in charge of ack mode request or giving permission to other program to change mode. Such master would be in charge of vt switch. Their is also many plan on widering the kernel object usage in this DRM2 so we can take advantage of linux object framework (like filesystem stuff). 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. 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. 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. Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
