On 10 March 2010 19:47, James Simmons <jsimm...@infradead.org> wrote: > >> >> 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. > > Ah, the power of flags. We had the same issue with user requesting 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 you > will > have to deal also with the ability to change the resolution with tools like > stty. > I can easily see how to do this plus give you more memory like you want :-) > For the oops are you talking about printing oops to the screen > 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. >
Ability to print the oops over X does not seem to be that bad idea. Since with KMS the kernel finally knows what X is doing with the graphics it should be able to print it. Note that it may be the only way to see it in situations when the console dies in one way or another. Thanks Michal ------------------------------------------------------------------------------ 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
