Steve Langasek came over today and we hacked on the i915 driver initialization code to try and avoid the initial mode set. I thought I'd summarize what we found out.
* Ubuntu has hacked up grub2 so that it gets the boot monitor running in a reasonable configuration using VBE calls if possible. In particular, it does try to find a 32bpp mode. Unfortunately, this won't actually work on many machines as the BIOS is often missing the native mode for the panel. So, we'll often need to deal with situations where the BIOS has got the panel running in the right mode, but there's a scaler running and the pipe and plane are wrong. I wonder if it's possible to change the plane/pipe/scaler configuration without turning the panel off and without causing any visible artifacts on the screen. My (limited) testing generated quite the visual fireworks... * Would UEFI do any better? It does provide a native mode on my MBA, it would be nice to know if this is at all common on regular PC hardware that has UEFI support. * I've got LVDS pulling the current mode out of the hardware, and nearly have eDP doing the same. eDP is a bit harder because computing the nominal pixel clock from the hw clock and M/N ratios is harder than just pulling the PLL values out. * Constructing a fake drm_framebuffer is a pain; there are a million places that assume all kinds of things about the frame buffer on a crtc. * DRM destroys all references to the current mode before crtc->mode_set is called. This makes it impossible to short-circuit pieces of mode_set internally. There's absolutely no reason for this; all of the changed data are available as parameters to the underlying functions. * drm should let the driver decide whether mode_set_base will work to switch frame buffers. Otherwise, there are all kinds of cases which the hardware supports and which it will refuse to let through. I think it should return -EAGAIN or some such to signal that the system should try to do a full mode set. I'll try changing the interface to mode_set_base and see how much further I get. All of the preliminary patches I've done are on my panel-takeover branch on git://people.freedesktop.org/~keithp/linux -- keith.pack...@intel.com
pgpKypyqtvMuJ.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx