> >> 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.

------------------------------------------------------------------------------
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

Reply via email to