On Wed, 2009-08-05 at 10:59 +0200, Thomas Hellström wrote: > Michel Dänzer wrote: > > From: Michel Dänzer <daen...@vmware.com> > > > > Use the fb_mmap hook for userspace and re-create the kernel mapping > > whenever the > > fbcon BO moves back into VRAM. KMS will pin it when necessary. This way we > > aren't wasting precious VRAM when we're e.g. in X. > > > > fbcon shouldn't (and IME doesn't) touch the BO contents while it isn't > > displaying. > We had some issues with this and Poulsbo KMS. In particular, cursor > blinking seemed to hit the fb kernel pointer even when the X server was > switched in.
What kernel version was that with? IIRC from the linux-fbdev-devel list there were some bugs in that area which have been fixed. > > If userspace tries to access /dev/fb* with read/write while the BO > > isn't in VRAM, we re-create the kernel mapping with vmap(). > > > Note that vmapping requires the bo to be either reserved or pinned. > Otherwise a bo move or swapout may invalidate the vmap at any point. > There is a safe ,unoptimized and untested way to do this: > ttm_bo_fbdev_io() (ttm_bo_vm.c) should perform a safe read- or write > operation regardless where the bo is currently located. Okay, I'll try that. Dave, please hold off on patches 2 and 3, I'll resend them after incorporating Thomas' feedback (thanks!). -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
