From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Simmons Date: Mon, 15 Mar 2010 18:38:02 +0000 Subject: Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video Message-Id: List-Id: References: <1268302426.7444.117.camel@thor.local> <21d7e9971003121251v4bef7e96v67f3d98aa9ab384a@mail.gmail.com> <21d7e9971003131301r723f3311p3553ea8a1a86bf0a@mail.gmail.com> <1268566880.9302.65.camel@thor.local> In-Reply-To: <1268566880.9302.65.camel@thor.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: =?ISO-8859-15?Q?Michel_D=E4nzer?= Cc: Linux Fbdev development list , Paulius Zaleckas , Michal Suchanek , Alex Deucher , DRI development list > > 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.