linux-fbdev-devel

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

[Paulius Z. <pau...@gm...>]

Hi,

On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation:

int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
			    struct fb_info *info)
{
[...]
	if (var->pixclock == -1 || !var->pixclock)
		return -EINVAL;
[...]

int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
	if (var->pixclock != -1) {
		DRM_ERROR("PIXEL CLCOK SET\n");
		return -EINVAL;
	}
[...]

One of these evaluations will fail regardless of pixclock value.

P.S. check CLCOK spelling :)

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

[Clemens L. <cl...@la...>]

Paulius Zaleckas wrote:
> On drivers using drm_fb_helper's in fb_ops it is not possible to change
> video mode, because of different var->pixclock evaluation: ...

patch:
http://www.mail-archive.com/dri...@li.../msg44369.html

> P.S. check CLCOK spelling :)

This patch got lost during fb helper reorganization:
http://git.kernel.org/linus/1bcbf3948876e31a8ece28597dec447611ad9c8b


Regards,
Clemens

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

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

> Paulius Zaleckas wrote:
> > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > video mode, because of different var->pixclock evaluation: ...
> 
> patch:
> http://www.mail-archive.com/dri...@li.../msg44369.html

Those patches will enable fbdev apps to run properly. More patches are 
needed if you want to support mode switching using the fbdev emulation 
layer. I noticed my patches and yours where lost. Who do you send patches 
too that can merge them ?  
 

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

[Andrew M. <ak...@li...>]

On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)
James Simmons <jsi...@in...> wrote:

> 
> > Paulius Zaleckas wrote:
> > > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > > video mode, because of different var->pixclock evaluation: ...
> > 
> > patch:
> > http://www.mail-archive.com/dri...@li.../msg44369.html
> 
> Those patches will enable fbdev apps to run properly. More patches are 
> needed if you want to support mode switching using the fbdev emulation 
> layer. I noticed my patches and yours where lost. Who do you send patches 
> too that can merge them ?  

y:/usr/src/git26> perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c
David Airlie <ai...@li...>
Dave Airlie <ai...@re...>
Jesse Barnes <jb...@vi...>
Mikael Pettersson <mi...@it...>
dri...@li...
lin...@vg...

That's accurate enough.

Generally, if nothing has happened in a week, the chances that it's
lost are very high.  Resend.  If you like, cc me and I'll maintain the patches
and resend them for you.

cheers,
lkml resendbot.

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

[Paulius Z. <pau...@gm...>]

On 11/20/2009 09:05 PM, Andrew Morton wrote:
> On Fri, 20 Nov 2009 18:53:37 +0000 (GMT)
> James Simmons<jsi...@in...>  wrote:
>
>>
>>> Paulius Zaleckas wrote:
>>>> On drivers using drm_fb_helper's in fb_ops it is not possible to change
>>>> video mode, because of different var->pixclock evaluation: ...
>>>
>>> patch:
>>> http://www.mail-archive.com/dri...@li.../msg44369.html
>>
>> Those patches will enable fbdev apps to run properly. More patches are
>> needed if you want to support mode switching using the fbdev emulation
>> layer. I noticed my patches and yours where lost. Who do you send patches
>> too that can merge them ?
>
> y:/usr/src/git26>  perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c
> David Airlie<ai...@li...>
> Dave Airlie<ai...@re...>
> Jesse Barnes<jb...@vi...>
> Mikael Pettersson<mi...@it...>
> dri...@li...
> lin...@vg...
>
> That's accurate enough.
>
> Generally, if nothing has happened in a week, the chances that it's
> lost are very high.  Resend.  If you like, cc me and I'll maintain the patches
> and resend them for you.

You can add Tested-by: Paulius Zaleckas <pau...@gm...>
for http://www.mail-archive.com/dri...@li.../msg44369.html
as this was preventing DirectFB from running on my Asus Eee PC 701.

While at this patch maybe you should fix that spelling issue as well.

> cheers,
> lkml resendbot.

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

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

> > > > Paulius Zaleckas wrote:
> > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > change
> > > > > video mode, because of different var->pixclock evaluation: ...
> > > > 
> > > > patch:
> > > > http://www.mail-archive.com/dri...@li.../msg44369.html
> > > 
> > > Those patches will enable fbdev apps to run properly. More patches are
> > > needed if you want to support mode switching using the fbdev emulation
> > > layer. I noticed my patches and yours where lost. Who do you send patches
> > > too that can merge them ?
> > 
> > y:/usr/src/git26>  perl scripts/get_maintainer.pl -f
> > drivers/gpu/drm/drm_fb_helper.c
> > David Airlie<ai...@li...>
> > Dave Airlie<ai...@re...>
> > Jesse Barnes<jb...@vi...>
> > Mikael Pettersson<mi...@it...>
> > dri...@li...
> > lin...@vg...
> > 
> > That's accurate enough.
> > 
> > Generally, if nothing has happened in a week, the chances that it's
> > lost are very high.  Resend.  If you like, cc me and I'll maintain the
> > patches
> > and resend them for you.
> 
> You can add Tested-by: Paulius Zaleckas <pau...@gm...>
> for http://www.mail-archive.com/dri...@li.../msg44369.html
> as this was preventing DirectFB from running on my Asus Eee PC 701.

I tested it as well with the both my 3Dfx driver that I wrote with KMS and 
the nouveau driver. We just need to make sure that the patches end up in 
the drm-next tree or these patches will be lost when drm-next gets merged 
to linus tree.

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

[Paulius Z. <pau...@gm...>]

On 11/20/2009 10:01 PM, James Simmons wrote:
>
>>>>> Paulius Zaleckas wrote:
>>>>>> On drivers using drm_fb_helper's in fb_ops it is not possible to
>>>>>> change
>>>>>> video mode, because of different var->pixclock evaluation: ...
>>>>>
>>>>> patch:
>>>>> http://www.mail-archive.com/dri...@li.../msg44369.html
>>>>
>>>> Those patches will enable fbdev apps to run properly. More patches are
>>>> needed if you want to support mode switching using the fbdev emulation
>>>> layer. I noticed my patches and yours where lost. Who do you send patches
>>>> too that can merge them ?
>>>
>>> y:/usr/src/git26>   perl scripts/get_maintainer.pl -f
>>> drivers/gpu/drm/drm_fb_helper.c
>>> David Airlie<ai...@li...>
>>> Dave Airlie<ai...@re...>
>>> Jesse Barnes<jb...@vi...>
>>> Mikael Pettersson<mi...@it...>
>>> dri...@li...
>>> lin...@vg...
>>>
>>> That's accurate enough.
>>>
>>> Generally, if nothing has happened in a week, the chances that it's
>>> lost are very high.  Resend.  If you like, cc me and I'll maintain the
>>> patches
>>> and resend them for you.
>>
>> You can add Tested-by: Paulius Zaleckas<pau...@gm...>
>> for http://www.mail-archive.com/dri...@li.../msg44369.html
>> as this was preventing DirectFB from running on my Asus Eee PC 701.
>
> I tested it as well with the both my 3Dfx driver that I wrote with KMS and
> the nouveau driver. We just need to make sure that the patches end up in
> the drm-next tree or these patches will be lost when drm-next gets merged
> to linus tree.

IMHO this patch should end up in current (2.6.32) kernel and we should
send it to stable ML.

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

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

On Fri, 20 Nov 2009, Paulius Zaleckas wrote:

> On 11/20/2009 10:01 PM, James Simmons wrote:
> > 
> > > > > > Paulius Zaleckas wrote:
> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > > > change
> > > > > > > video mode, because of different var->pixclock evaluation: ...
> > > > > > 
> > > > > > patch:
> > > > > > http://www.mail-archive.com/dri...@li.../msg44369.html
> > > > > 
> > > > > Those patches will enable fbdev apps to run properly. More patches are
> > > > > needed if you want to support mode switching using the fbdev emulation
> > > > > layer. I noticed my patches and yours where lost. Who do you send
> > > > > patches
> > > > > too that can merge them ?
> > > > 
> > > > y:/usr/src/git26>   perl scripts/get_maintainer.pl -f
> > > > drivers/gpu/drm/drm_fb_helper.c
> > > > David Airlie<ai...@li...>
> > > > Dave Airlie<ai...@re...>
> > > > Jesse Barnes<jb...@vi...>
> > > > Mikael Pettersson<mi...@it...>
> > > > dri...@li...
> > > > lin...@vg...
> > > > 
> > > > That's accurate enough.
> > > > 
> > > > Generally, if nothing has happened in a week, the chances that it's
> > > > lost are very high.  Resend.  If you like, cc me and I'll maintain the
> > > > patches
> > > > and resend them for you.
> > > 
> > > You can add Tested-by: Paulius Zaleckas<pau...@gm...>
> > > for
> > > http://www.mail-archive.com/dri...@li.../msg44369.html
> > > as this was preventing DirectFB from running on my Asus Eee PC 701.
> > 
> > I tested it as well with the both my 3Dfx driver that I wrote with KMS and
> > the nouveau driver. We just need to make sure that the patches end up in
> > the drm-next tree or these patches will be lost when drm-next gets merged
> > to linus tree.
> 
> IMHO this patch should end up in current (2.6.32) kernel and we should
> send it to stable ML.

Honestly I like to see it there as well.

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

[Dave A. <ai...@gm...>]

On Sat, Nov 21, 2009 at 6:48 AM, James Simmons <jsi...@in...> wrote:
>
>
> On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
>
>> On 11/20/2009 10:01 PM, James Simmons wrote:
>> >
>> > > > > > Paulius Zaleckas wrote:
>> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
>> > > > > > > change
>> > > > > > > video mode, because of different var->pixclock evaluation: ...
>> > > > > >
>> > > > > > patch:
>> > > > > > http://www.mail-archive.com/dri...@li.../msg44369.html
>> > > > >
>> > > > > Those patches will enable fbdev apps to run properly. More patches are
>> > > > > needed if you want to support mode switching using the fbdev emulation
>> > > > > layer. I noticed my patches and yours where lost. Who do you send
>> > > > > patches
>> > > > > too that can merge them ?
>> > > >
>> > > > y:/usr/src/git26>   perl scripts/get_maintainer.pl -f
>> > > > drivers/gpu/drm/drm_fb_helper.c
>> > > > David Airlie<ai...@li...>
>> > > > Dave Airlie<ai...@re...>
>> > > > Jesse Barnes<jb...@vi...>
>> > > > Mikael Pettersson<mi...@it...>
>> > > > dri...@li...
>> > > > lin...@vg...
>> > > >
>> > > > That's accurate enough.
>> > > >
>> > > > Generally, if nothing has happened in a week, the chances that it's
>> > > > lost are very high.  Resend.  If you like, cc me and I'll maintain the
>> > > > patches
>> > > > and resend them for you.
>> > >
>> > > You can add Tested-by: Paulius Zaleckas<pau...@gm...>
>> > > for
>> > > http://www.mail-archive.com/dri...@li.../msg44369.html
>> > > as this was preventing DirectFB from running on my Asus Eee PC 701.
>> >
>> > I tested it as well with the both my 3Dfx driver that I wrote with KMS and
>> > the nouveau driver. We just need to make sure that the patches end up in
>> > the drm-next tree or these patches will be lost when drm-next gets merged
>> > to linus tree.
>>
>> IMHO this patch should end up in current (2.6.32) kernel and we should
>> send it to stable ML.
>
> Honestly I like to see it there as well.
>

I have them queued for drm-next already at least locally, I wasn't aware
they were suitable for final, I didn't get a chance to really test them until
last week and make sure they didn't hide any side effects. I can
ask for them to go to stable when the merge window opens, I think
its too late for final.

Dave.

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

[Dave A. <ai...@gm...>]

On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
<pau...@gm...> wrote:
> Hi,
>
> On drivers using drm_fb_helper's in fb_ops it is not possible to change
> video mode, because of different var->pixclock evaluation:
>
> int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
>                            struct fb_info *info)
> {
> [...]
>        if (var->pixclock == -1 || !var->pixclock)
>                return -EINVAL;
> [...]
>
> int drm_fb_helper_set_par(struct fb_info *info)
> {
> [...]
>        if (var->pixclock != -1) {
>                DRM_ERROR("PIXEL CLCOK SET\n");
>                return -EINVAL;
>        }
> [...]
>
> One of these evaluations will fail regardless of pixclock value.
>

At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,

Now if a user runs fbset, I'm not sure what the right answer is,
a) pick a head in advance via sysfs maybe and set it on that.
b) try and set the mode on both heads cloned (what to do if
there is no common mode is another issue).

Dave.

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

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

> >> At the moment the problem with fbset is what to do with it in the
> >> dual head case. Currently we create an fb console that is lowest
> >> common size of the two heads and set native modes on both,
> >
> > Does that mean that fbset is supposed to work (set resolution) on drmfb?
> 
> No we've never hooked it up but it could be made work.

I had it to the point of almost working. I plan on working on getting it 
working again.
 
> > Schemes which would make a multihead setup look like a single screen
> > get complicated quite easily. Perhaps an option to turn off some
> > outputs so that the native resolution of one output is used (instead
> > of clone) would work.
> >
> 
> I've only really got two answer for this:
> 
> (a) hook up another /dev/dri/card_fb device and use the current KMS
> ioctls to control the framebuffer, have the drm callback into fbdev/fbcon
> to mention resizes etc. Or add one or two info gathering ioctls and
> allow use of the /dev/dri/control device to control stuff.
> 
> (b) add a lot of ioctls to KMS fbdev device, which implement some sort
> of sane multi-output settings.
> 
> Now the second sounds like a lot of work if not the correct solution,
> you basically needs a way to pretty much expose what the KMS ioctls
> expose on the fb device, and then upgrade fbset to make sense of it all.

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.

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

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

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

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

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

> > 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.
> >
> 
> So you get the layering naturally. On fbset - fbev layer you can
> choose from the resolutions available in the current output setup, in
> kmset or whatever - drm layer you can set up the outputs, merge
> multiple outputs into single cloned fbdev or separate them, ..
> 
> It's obviously nice if you can set the resolution on all of fbcons,
> fbdev and drm layers but getting it work on at least one layer with
> proper propagation up and down also works. BTW I don't know any
> application which sets linux console (or xterm for that matter)
> resolution through the terminal API.

I agree. The mode setting should be done in one layer. Its a matter of 
doing the proper emulation of the fbdev layer.

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

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

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

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.

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

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

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

Searching the TTM code I couldn't find the handle code so easily. I see 
that the vmwgfx driver provides a example of using ttm.
 
> >        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.

Sorry I should of stated what I was planing to do. I like to see drmfb 
have the ablitiy to change the resolution via fbset. To do that we need to 
be able to create and destory the framebuffer memory if the memory doesn't 
fit the size of the new resolution. Plus it gives us the bonus of being 
able to unpin the memory when the VT is in KD_GRAPHICS mode. The problem 
is that the functions like fb_create are tied to a handle which is not 
present for the internal framebuffer used by fbdev. Sorry for the junk 
above. It just took me awhile to figure out the code. Their is steep 
learning curve. I have patches that should address this coming soon.

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

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

> > Searching the TTM code I couldn't find the handle code so easily. I see
> > that the vmwgfx driver provides a example of using ttm.
> 
> So handles are purely a userspace interface, in-kernel we don't use handles
> for buffer management, the vmwgfx TTM interface has vmw_user_surface_lookup_handle
> to do the bo lookups.

Yeap, some how userland has to tell which buffer is which. I also noticed 
their is a ttm_base_object_lookup which does the same thing :-)