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

[Dave Airlie <airlied@gmail.com>]

>> >
>> >> >> 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.
>> >>
>> >> I'm all for it!
>> >
>> > I'm looking into the details for this. It will require some changes to
>> > internal apis to make it to work.
>> >
>>
>> Can't it print the oops on whatever is currently displayed?
>>
>> It need not be a dedicated buffer as long as there is always some buffer.
>>
>> But perhaps this is more complex than that.
>
>        Yes it is very complex. Reading the code and drm specs you come to
> realize buffer handling is done with GEM, TTM, or for older drivers drm_maps.
> Drivers often handle a combine of those, meaning no real wrapper from one
> api to another :-( From the code it appears GEM is the main userland interface
> when using KMS. Some how TTM is also usable from userland but I never found a
> clear example of how that is done. So to the average userland app writer it is
> a mystery. As for hardware that has a static front buffer I can see how to
> use drm_maps or TTM but I don't see a easy way to map it to the GEM api.
> Also their exist ioctl for gem but it appears no one actually uses them
> but instead write their own :-( So you can see the confusion here.

Userspace buffer management interfaces are pre-driver, the only requirement
if that they have a 32-bit handle to identify buffers uniquely. Pre-KMS drivers
don't exist for the purposes of fb interaction, so drm_maps are ignorable from
that pov.

>        Outside of what I described above the drm_framebuffer handling is
> a mess. From what I can see with the code you can only create a
> drm_framebuffer with the GEM api. With this case the two most important
> functions to provide are

This isn't correct. You get a drm_file and a handle, the driver then uses
these to do whatever it wants to do. This means lookup a GEM object or
whatever but there is no reliance on GEM or any other memory manager
outside the driver. Again a handle a file priv are in no way GEM specific.

>
> dev->mode_config.funcs->fb_create(dev, file_priv, r)
>
> and
>
> fb->funcs->create_handle(fb, file_priv, &r->handle);
>
> As you can see if the functions they depend on a handle and a drm_file. To
> make it possible to create a framebuffer internally using a common code we
> would remove those requirements.

We already have an internal framebuffer creation for fbdev, there is
an fb_create
callback that does this, its not up to dynamic fbdev creation.

>        This gets me to point of where to go from here. We have two choices.
> The first being we could just make the drm_framebuffer code totally gem
> dependent thus we could cleanup the drivers code up by moving gem code
> there. The second option is to make the drm_framebuffer code agnostic to the gem
> layer. So I have been pondering on how to make the second option work.
> There is one thing that all these layers do share in common. That is they
> have some sort of drm_hash with a object lookup. Still pondering how that
> would be done.

I'm not sure either of these makes sense, can you clearly state the
goal and maybe
we can work out what you need.

Dave.

------------------------------------------------------------------------------
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
--