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 15:06:08 -0500 Message-ID: References: <21d7e9970911202027l1d4deec6p5750b8425cd6bb3f@mail.gmail.com> <21d7e9971003022102v232c099r441b0bd843b30313@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Old FrameBuffer List , DRI development list , Michal Suchanek , Paulius Zaleckas On Wed, Mar 10, 2010 at 1:47 PM, James Simmons wro= te: > >> >> Yuck. See my other post about what fbdev really means in its historic= al >> >> 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 framebuff= er. >> >> What the driver does is splits the framebuffer in two and assigned ea= ch >> >> 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. > > =A0 =A0 =A0 =A0Ah, the power of flags. We had the same issue with user re= questing a mode > change or fbcon asking for a different mode. We handled it with the flag > FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon y= ou will > have to deal also with the ability to change the resolution with tools li= ke stty. > I can easily see how to do this plus give you more memory like you want := -) > =A0 =A0 =A0 =A0For the oops are you talking about printing oops to the sc= reen > while X is running ? Otherwise if you experience a oops and go back to > console mode you should be able to view it. The console text buffer is > independent of the graphics card memory system. > Right now we keep the console buffer pinned in vram and we switch to it when there is an oops or when you switch VTs. 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 --