On Mon, 2010-03-15 at 18:38 +0000, James Simmons wrote: > > > 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 > > > > Actually AFAIR (and reading through it again seems to confirm this) > > userspace mappings should be fully handled by the last patch series I > > posted back then[0]. The problem was that the struct fb_ops hooks may be > > called by the kernel from pretty much any context, and neither I nor > > Thomas was sure how to handle the TTM locking given that. Maybe James > > has ideas for this given his better familiarity with fbdev internals. > > The fb_ops can only be called from fbcon or the fbdev userland interface. > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now > with the DRM backend we have the advantage of creating a mapping seperate > from the console mapping. A fb_open/fb_close could be used to cleaning up > the userland mmap as well as handle the console pinning. We can supply > your own fb_mmap hook.
Again, the issue is not userspace but that fb_ops hooks can be called from interrupt context etc. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ 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
