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