On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimm...@infradead.org> wrote: > >> >> At the moment the problem with fbset is what to do with it in the >> >> dual head case. Currently we create an fb console that is lowest >> >> common size of the two heads and set native modes on both, >> > >> > Does that mean that fbset is supposed to work (set resolution) on drmfb? >> >> No we've never hooked it up but it could be made work. > > I had it to the point of almost working. I plan on working on getting it > working again. > >> > Schemes which would make a multihead setup look like a single screen >> > get complicated quite easily. Perhaps an option to turn off some >> > outputs so that the native resolution of one output is used (instead >> > of clone) would work. >> > >> >> I've only really got two answer for this: >> >> (a) hook up another /dev/dri/card_fb device and use the current KMS >> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon >> to mention resizes etc. Or add one or two info gathering ioctls and >> allow use of the /dev/dri/control device to control stuff. >> >> (b) add a lot of ioctls to KMS fbdev device, which implement some sort >> of sane multi-output settings. >> >> Now the second sounds like a lot of work if not the correct solution, >> you basically needs a way to pretty much expose what the KMS ioctls >> expose on the fb device, and then upgrade fbset to make sense of it all. > > Yuck. See my other post about what fbdev really means in its historical > context. The struct fb_info really maps better to drm_crtc than to > drm_framebuffer. In fact take the case of the matrox fbdev driver. It > creates two framebuffer devices even tho it used one static framebuffer. > What the driver does is splits the framebuffer in two and assigned each > part to a CRTC.
The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. Alex ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
