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

[James S. <jsi...@in...>]

On Thu, 11 Mar 2010, Michal Suchanek wrote:

> On 11 March 2010 16:17, James Simmons <jsi...@in...> wrote:
> >
> >> >> 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. 
	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

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