From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Deucher Subject: Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode Date: Wed, 10 Mar 2010 13:10:14 -0500 Message-ID: References: <21d7e9970911202027l1d4deec6p5750b8425cd6bb3f@mail.gmail.com> <21d7e9971003022102v232c099r441b0bd843b30313@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: James Simmons Cc: linux-fbdev-devel@lists.sourceforge.net, dri-devel@lists.sourceforge.net, Michal Suchanek , Paulius Zaleckas On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote: > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons 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. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. 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 --