Re: Flicker-free boot in DRM

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2469 bytes --]

On Sat, 29 Oct 2011 00:05:22 -0700
"Keith Packard" <keithp@keithp.com> wrote:

> 
> 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...

Should be possible I think, but depends on the specific hardware rev.
Last time I tried lots of combinations was on Crestline for panel
fitting.  Scaling down or up with fitting worked w/o shutting down the
pipe, but to scale back up from a centered mode required a pipeconf
toggle.  I think BIOSes mostly use the fitter though, so it ought to be
possible.

>  *  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.

Easier to just copy the contents out of the current framebuffer into a
new one before flipping to the new buffer.

>  *  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 think that's already possible if we don't use the helper function for
mode setting.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx