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

[Dave Airlie <airlied@gmail.com>]

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

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

Okay first up, there are two sets of codepaths, please ignore vmwgfx
for now, its
_fb implementation is not yet using the drm_fb_helper.c code and it needs to be
converted if possible. Originally all the drivers had their own fb
code, but its was
mostly pointless, the helper allows for drivers to optionally use the
shared code,
ideally we'd like all drivers to use that code so we get consistent
operation across
drivers, so user experience isn't driver dependent unless unavoidable.

The big issue we have with resizing the buffer is userspace mmaps of the fbdev
device, and invalidation.
Previous thread of unresolvedness is here.
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg41878.html

If you look at the current fb code, when we get a hotplug event in
theory, we try and
reuse the current framebuffer.

I suppose initially it would be worth trying the resize downwards and keep the
current fbdev, but the whole mmap area was the cause of most of the problems
and it seemed like a real pain to fix.

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