> > 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. > [0] Though that was really only about making it possible to unpin the > fbcon BO while it isn't being displayed, resizing it might involve other > issues I'm not aware of. Yeap, but both problems are related. Kill two birds with one stone. ------------------------------------------------------------------------------ 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
