Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

[Pauli Nieminen <suokkos@gmail.com>]

2010/3/11 Michel Dänzer <michel@daenzer.net>:
> On Wed, 2010-03-10 at 13:10 -0500, Alex Deucher wrote:
>> On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Wed, Mar 10, 2010 at 12:42 PM, James Simmons <jsimmons@infradead.org> wrote:
>> >>
>> >> 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.
>
> What do you think the average user will care about more?
>
>      * Seeing kernel oops/panic output about once in a lifetime.
>      * Being able to start/use X in the first place and enabling it to
>        use all of VRAM.
>
> Personally, I've never even seen any kernel oops/panic output despite
> numerous opportunities for that in the couple of months I've been using
> KMS. But I have spent considerable time and effort trying to get rid of
> the pinned fbcon BO. If the oops/panic output is the only thing
> preventing that, maybe that should only be enabled via some module
> option for developers.
>

+1

For me only way to capture oopses is netconsole. But I'm causing all
my oopses in radeon/ttm modules. That might prevent the system from
returning to framebuffer console.

Pinning framebuffer console is only for developers feature so it
should be non-default option. For users it is more important to have
all VRAM available when required and fully functional console if they
use it.
In case of kernel oops there should some different way to collect them
in users system. They should be stored in hard disk for easier
attaching to the bug report. Also oopses that are stored in hd can be
later uploaded automatically with kerneloops daemon.

------------------------------------------------------------------------------
Download Intel&#174; 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
--