> > 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 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
