From: James S. <jsi...@in...> - 2010-03-10 18:47:38
|
> >> 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. |