Em Qua, 2016-03-23 às 09:50 +0100, Daniel Vetter escreveu: > On Tue, Mar 22, 2016 at 09:35:36PM +0000, Zanoni, Paulo R wrote: > > > > Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu: > > > > > > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote: > > > > > > > > > > > > The sna_mode_wants_tear_free() function tries to detect FBC and > > > > PSR > > > > based on Kernel module parameters. Currently it fails to detect > > > > FBC > > > > due to the default enable_fbc value being -1. While this can > > > > easily > > > > be > > > > fixed in the Kernel, I had a conversation with Daniel and he > > > > expressed > > > > unhappiness with that solution, claiming that yet another > > > > different > > > > code path just for a feature that should be transparent is not > > > > a > > > > good > > > > way to go, and that we should do proper frontbuffer rendering. > > > > > > > > So with this patch, we'll have the DDX issuing dirtyfb calls > > > > even > > > > if > > > > TearFree is not enabled, fixing FBC when i915.enable_fbc=-1. > > > > > > > > This fixes a bug that happens on SKL with FBC enabled: if you > > > > run > > > > lightdm, your login/password won't appear as you type on your > > > > keyboard. You have to move the mouse over the input box for > > > > them to > > > > be > > > > displayed. > > > > > > > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > > > I thought we need this anyway to get the kernel to allow fbc, > > > since > > > SNA > > > ends up mmap some of the drm_framebuffer. Even when they're not > > > frontbuffers. > > If we merge patch 2/4, we won't need this one since TearFree will > > be in > > use, and it seems TearFree doesn't touch frontbuffers, so we'll > > always > > get the flush calls during page flips. > I'd thought that TearFree would still do rendering with the cpu > sometimes, > but only always to the back buffer. So we'd still have cpu mmaps, and > hence the kernel w/a would still potentially kick in and prevent fbc. > So > that's not the case then, and we get fbc reliably with the kernel > patch, > even without this patch? Oh, you're right. But at least we won't have bugs, and we'll have FBC on things like xf86-video-modesetting, which some distros seem to already be using for SKL. Well, now that I think a little more about this, maybe we could add little hack to DDX so it does a single sw_finish/dirty_fb call to TearFree framebuffers upon creation so the workaround gets disabled... Hmm.. > -Daniel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
