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@xxxxxxxxxxxxxxxxxxxxx/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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
