On Tue, Jun 12, 2012 at 12:58:20PM +0100, Chris Wilson wrote: > On Tue, 12 Jun 2012 11:43:50 +0000, "Singh, Satyeshwar" > <[email protected]> wrote: > > Hi, > > I just want to confirm something here. We have a situation where we draw a > > splash screen through our firmware's graphics component (UEFI GOP driver) > > onto its frame buffer which resides in stolen memory. When we transition > > from firmware to the kernel, we would like to ensure that the same splash > > screen seamlessly continues to be displayed so we remap the pages from > > stolen memory into GTT. If we have purged firmware framebuffers before > > claiming the gtt, then would we have not essentially lost the chance to > > remap those pages? > > That's a separate issue. What this patch is addressing is removing a > conflicting fbdev driver. If you have such a driver loaded all bets are > off concerning the state of memory from the transition of UEFI to KMS > (rule: don't use more one driver for the same hw). The challenge of > preserving the contents and mode of UEFI is the task of Jesse's fastboot > work. As noted elsewhere, using the GOP queries might simplify the task > of reading back hw state -- except that we need such information anyway > whether or not we have a UEFI system.
Actually, this patch should also help in kicking the native uefi framebuffer driver - in case people use such a thing. But otherwise Chris is right - preserving the existing output state and framebuffer contents is a fully orthogonal issue. This patch only solves driver arbitrage within the linux kernel. -Daniel -- Daniel Vetter Mail: [email protected] Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
