On Thu, Dec 12, 2013 at 12:44 AM, Gerd Hoffmann <[email protected]> wrote: > Hi, > >> (1) When booting Linux with OVMF's GOP (doesn't matter with which video >> card), the first driver grabbing the card is the efifb driver. This is >> reported in dmesg as: >> >> [ 0.891094] efifb: probing for efifb >> [ 0.896161] efifb: framebuffer at 0xa4000000, mapped to >> 0xffffc90000780000, using 1876k, total 1875k >> [ 0.906944] efifb: mode is 800x600x32, linelength=3200, pages=1 >> [ 0.913958] efifb: scrolling: redraw >> [ 0.918211] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 >> [ 0.926951] Console: switching to colour frame buffer device 100x37 >> [ 0.935261] fb0: EFI VGA frame buffer device >> >> However, soon after, a card-specific FB driver comes along, and kicks >> off the efifb driver. > > Yep, efifb is basically the vesafb aequivalent in the efi world. > > BTW: Recent kernels seem to attempt unify them (and other > firmware-initialized framebuffers) as simplefb (and simpledrm), so if > you see them pop up somewhere you know what it is ;) > >> (2) So, let's consider four cases: >> >> - QXL with qxldrmfb >> - QXL with efifb (qxldrmfb blacklisted) >> - Cirrus with cirrusdrmfb >> - Cirrus with efifb (cirrusdrmfb blacklisted) > > There are two more players: > > * cirrusfb (CONFIG_FB_CIRRUS, not enabled by default in fedora > kernels). drm is the way to go though. But maybe worth testing S3 > and maybe borrow code to handle suspend/resume in drm/cirrus driver. > * http://www.kraxel.org/cgit/linux/log/?h=bochs-drm > [ need to bug airlied again about getting it merged ... ] > >> (2a) QXL with qxldrmfb >> >> One nit that I have is that the character console performance is really >> sluggish and the screen updates are ugly. But that's my fault, because I >> was too lazy to set up a SPICE display, and QXL is very likely not >> optimized for VNC (which is what I used). > > Visible with spice too. Probably something in the guest driver. > >> (2c) Cirrus with cirrusdrmfb >> >> I wrote an OVMF bootscript patch (more about it later), and the screen >> started to do *something* after resume, but it presented the typical >> sheared image of the stride being wrong. > > Sounds like card running with efifb modesetting but cirrus kernel driver > thinks its own, different config is active. > >> (2d) Cirrus with efifb (cirrusdrmfb blacklisted) >> >> This setup seems to rule out X11 at once (probably not a popular >> setup...), > > X11 can run on top of a framebuffer device just fine. Make sure you > have xorg-x11-drv-fbdev installed. > >> Maybe the guest could write a boot script via SMM, but resume support in >> a guest driver is probably better. > > Yes, we should fix drm/cirrus. > Did you try cirrus S3 with seabios btw?
Good question. Before this thread, I would have expected that seabios would not try to restore this on resume. And a meaner question... What happens with windows? Normally we would expect the OS graphics driver to restore this. But in this case, I guess we could argue that the cirrus device closely associated with x86 QEMU. It would essentially be a platform hack for a device where the OS drivers were known to be inadequate. (Obviously the more ideal fix is in the OS/driver.) -Jordan ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
