Bug 93523 - [IVB] laptop display eDP1 UEFI boots to letterboxed 16:9 display instead of full screen 16:10 2560x1600 (Macbook 13 retina)
Summary: [IVB] laptop display eDP1 UEFI boots to letterboxed 16:9 display instead of f...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-28 19:16 UTC by Chris Bainbridge
Modified: 2017-04-11 12:23 UTC (History)
1 user (show)

See Also:
i915 platform: IVB
i915 features: display/eDP


Attachments
dmesg-bad-boot-resolution (160.32 KB, text/plain)
2015-12-28 19:16 UTC, Chris Bainbridge
no flags Details

Description Chris Bainbridge 2015-12-28 19:16:09 UTC
Created attachment 120717 [details]
dmesg-bad-boot-resolution

Kernel: 4.4.0-rc7
Distribution: Debian stable (jessie)

This is possibly a long standing kernel bug, perhaps exposed now by an OSX firmware update, or a change in grub.

1. Grub boots and uses default 1920x1080 EFI GOP mode (looks like native 2560x1600 with 16:9 letterbox bars)
2. Linux boots and sets the video mode to 2560x1600

Result:
        After boot xrandr reports 2560x1600 but display is still 16:9 with letterbox black bars at the top and bottom of the screen as if 1920x1080 were still active.

Workaround:
        Suspend-to-ram and resume
        video mode is now correct 2560x1600 and display is 16:10 full screen with no letterbox bars


It looks like some setting of the initial boot mode 1920x1080 fb (used by grub) is preserved when the mode is set to 2560x1600 on first boot, but then cleared when the video is reinitialised on suspend resume.


[    0.420299] [drm:drm_atomic_set_mode_for_crtc] Set [MODE:2560x1600] for CRTC state ffff88008885f000
[    0.420379] [drm:drm_mode_debug_printmodeline] Modeline 0:"2560x1600" 60 268492 2560 2608 2640 2720 1600 1603 1609 1646 0x40 0xa
[    0.420382] [drm:drm_mode_debug_printmodeline] Modeline 0:"2560x1600" 60 268492 2560 2608 2640 2720 1600 1603 1609 1646 0x40 0xa
[    0.420383] [drm:intel_dump_crtc_timings] crtc timings: 268492 2560 2608 2640 2720 1600 1603 1609 1646, type: 0x40 flags: 0xa
[    0.420385] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[    0.420608] [drm:ironlake_get_initial_plane_config] pipe C with fb: size=1920x1080@32, offset=0, pitch 7680, size 0x7e9000
[    0.427050] [drm:drm_mode_debug_printmodeline] Modeline 35:"2560x1600" 60 268500 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9
[    0.596105] [drm:intel_fb_initial_config] connector eDP-1 on pipe C [CRTC:29]: 2560x1600
[    0.596119] [drm:drm_setup_crtcs] desired mode 2560x1600 set on crtc 29 (0,0)
[    0.598222] [drm:intelfb_create] allocated 2560x1600 fb: 0x0084d000, bo ffff880254a70000
[    0.598418] [drm:drm_atomic_set_mode_for_crtc] Set [MODE:2560x1600] for CRTC state ffff8800888ec000
[    0.598454] [drm:drm_mode_debug_printmodeline] Modeline 0:"2560x1600" 60 268500 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9
[    0.598456] [drm:drm_mode_debug_printmodeline] Modeline 0:"2560x1600" 60 268500 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9
[    0.598457] [drm:intel_dump_crtc_timings] crtc timings: 268500 2560 2608 2640 2720 1600 1603 1609 1646, type: 0x48 flags: 0x9
[    0.598458] [drm:intel_dump_pipe_config] pipe src size: 2560x1600
[    0.598466] [drm:intel_dump_pipe_config] 	FB:55, fb = 1920x1080 format = 0x34325258
Comment 1 Chris Bainbridge 2015-12-29 02:14:11 UTC
Another symptom of this bug is that attempting to change the display resolution with xrandr will result in a corrupt screen. After a suspend/resume cycle changing the display resolution will work ok.
Comment 2 Chris Bainbridge 2016-01-05 02:51:36 UTC
This bug only occurs on UEFI grub boot. On a BIOS boot (grub --target=i386-pc) with the same kernel the VESA BIOS mode 2560x1600 is available and will be used by grub so the aspect ratio is always 16:10. On a UEFI boot, the only mode grub reports as being available is 1920x1080 (which is letterboxed 16:9 aspect ratio) so it uses that and the kernel should properly switch to 16:10 aspect ratio for 2560x1600 mode.
Comment 3 Chris Bainbridge 2016-01-24 12:55:34 UTC
For reference, patch and mailing list comments are at http://comments.gmane.org/gmane.linux.kernel/2125878

Problem is that panel fitters are dynamically assigned to pipes on IVB and the boot firmware might use a different mapping then the kernel.
Comment 4 yann 2017-03-16 12:48:41 UTC
(In reply to Chris Bainbridge from comment #3)
> For reference, patch and mailing list comments are at
> http://comments.gmane.org/gmane.linux.kernel/2125878
> 
> Problem is that panel fitters are dynamically assigned to pipes on IVB and
> the boot firmware might use a different mapping then the kernel.

We seem to have neglected the bug a bit, apologies.

Chris Bainbridge, there were improvements pushed in kernel that will benefit to your system, so please re-test with latest kernel and mark as REOPENED if you can reproduce (and attach fresh kernel log) and RESOLVED/* if you cannot reproduce.
Comment 5 yann 2017-04-11 12:23:35 UTC
(In reply to yann from comment #4)
> (In reply to Chris Bainbridge from comment #3)
> > For reference, patch and mailing list comments are at
> > http://comments.gmane.org/gmane.linux.kernel/2125878
> > 
> > Problem is that panel fitters are dynamically assigned to pipes on IVB and
> > the boot firmware might use a different mapping then the kernel.
> 
> We seem to have neglected the bug a bit, apologies.
> 
> Chris Bainbridge, there were improvements pushed in kernel that will benefit
> to your system, so please re-test with latest kernel and mark as REOPENED if
> you can reproduce (and attach fresh kernel log) and RESOLVED/* if you cannot
> reproduce.

Timeout - assuming resolved+fixed.

If problem still persist with the latest kernels (preferable drm-tip from git://anongit.freedesktop.org/git/drm-tip), reopen this bug with latest logs as attachments.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.