Bug 71977 - [BYT] Modesetting on Dell Venue 8 Pro (Bay Trail) produces garbled output (3.11, 3.12) or blank screen (3.13)
Summary: [BYT] Modesetting on Dell Venue 8 Pro (Bay Trail) produces garbled output (3....
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Paulo Zanoni
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-25 03:50 UTC by Adam Williamson
Modified: 2017-07-24 22:56 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
partial logs from a 3.13 boot with drm.debug set (117.92 KB, text/plain)
2013-11-26 04:52 UTC, Adam Williamson
no flags Details
dmesg from 3.13rc2 + check vbt for edp patch, with drm.debug set (83.01 KB, text/plain)
2013-11-30 21:06 UTC, Adam Williamson
no flags Details
dmesg from 3.13rc8 + fixes for 68291 and 67861 (65.69 KB, text/plain)
2014-01-16 22:50 UTC, Adam Williamson
no flags Details
xorg.conf with 800x1280 modeset (384 bytes, text/plain)
2014-01-24 04:14 UTC, Benjamin Tissoires
no flags Details
quick_dump.py -a output on v8p (35.14 KB, text/plain)
2014-02-11 17:43 UTC, Adam Williamson
no flags Details
full journalctl from a boot with 3.14.0-0.rc2.git1.1.1awb (hotplug detection enabled, video=800x1280@75e) (323.01 KB, text/plain)
2014-02-12 06:54 UTC, Adam Williamson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Williamson 2013-11-25 03:50:07 UTC
I just bought a Dell Venue 8 Pro - an 8" tablet based on the Bay Trail platform - to try and get Fedora running on it.

After hacking things up to produce a bootable 32-bit UEFI image, next come the kernel bugs :)

If I boot an image with a 3.11 or 3.12 kernel and default boot arguments, the display becomes badly garbled as soon as modesetting kicks in; it looks like it selects the wrong mode. If I boot an image with kernel 3.13.0-0.rc1.git0.1 , the screen just goes blank (backlight still working) when modesetting kicks in.

For now I have no further details, as I don't have a USB hub to hand so there's no way I can get any out. I'm going to pick up a USB hub tomorrow so I can have both the boot media and a keyboard connected, and I should be able to get some more useful info at that point.
Comment 1 Daniel Vetter 2013-11-25 09:30:34 UTC
Hm, smells like a DSI panel ...

Can you please boot with drm.debug=0xe and (somehow) grab the complete dmesg and attach it? Also please try to do this on the very latest kernels, preferably drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/
Comment 2 Adam Williamson 2013-11-26 04:52:08 UTC
Created attachment 89807 [details]
partial logs from a 3.13 boot with drm.debug set

I'm having fun getting debug output out of the system (nice 'somehow' :>), but here's what I've got. This is what journald managed to capture from a boot of 3.13.0-0.rc1.git2.1.fc21 with drm.debug set. Boot actually fails later on with 3.13 - see https://bugzilla.kernel.org/show_bug.cgi?id=65841 - so the log isn't complete, but it may have what you need.
Comment 3 Daniel Vetter 2013-11-26 07:27:47 UTC
Well we didn't find a single panel, neither eDP or a DSI one :( Are there any external outputs to make life easier with debugging? The kernel thinks there is something ...
Comment 4 Chris Wilson 2013-11-26 09:56:35 UTC
Didn't Jesse or Jani send a patch to fix detection of rogue eDP panels on the other DP port? I think that is in drm-intel-next.
Comment 5 Adam Williamson 2013-11-26 16:54:26 UTC
"Are there any external outputs to make life easier with debugging?"

Hah - it's like you think Dell exists to make my life _easy_ or something ;) The thing has precisely one port, which is approximately a micro USB port. I believe it may be possible to plug in an adapter that makes it act as an HDMI port, but I haven't looked into it at all yet. Maybe I'll have to? :/

Note that thing about 3.11 and 3.12 producing garbled output on the panel, not just _nothing_ - any idea if that's significant? Would similar logs from either of those kernels be any use?

I can try and get a drm-intel-nightly or drm-intel-next tree built and booted today, I'll do my best.
Comment 6 Adam Williamson 2013-11-26 17:49:05 UTC
Chris: is https://bugs.freedesktop.org/show_bug.cgi?id=71051 what you're thinking of? Just found that when I tweaked my search terms (apparently we don't believe in spaces when it comes to codenames, I should be searching for 'baytrail' not 'bay trail' :>)
Comment 7 Chris Wilson 2013-11-26 17:59:14 UTC
Aye, that's the one. I admittedly didn't search very hard earlier...
Comment 8 Adam Williamson 2013-11-26 18:06:26 UTC
Ok. I'll try and get a kernel built with that fix and see how it goes.
Comment 9 Adam Williamson 2013-11-30 21:05:57 UTC
OK, so I have a 3.13rc2-based kernel built, with the patch generated from commit http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=5d8a77529bd6864361005117c3a611b6d810aa77 - "Check VBT for eDP ports on VLV" - applied. Still doesn't work, still the screen goes blank when modesetting kicks in. :/ I've managed to get the dmesg output, which I'll attach.
Comment 10 Adam Williamson 2013-11-30 21:06:42 UTC
Created attachment 90043 [details]
dmesg from 3.13rc2 + check vbt for edp patch, with drm.debug set
Comment 11 Adam Williamson 2013-12-03 03:33:29 UTC
Good news! I did a build based off the latest Fedora kernel (few git revs past rc2) and added simplify-dp-vs-edp.patch - http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=3b32a35b31b19c8f9340d3b3a149062fce1cd89f - and that gives me working KMS.

X startup fails, without any apparent useful output to any logs; Xorg.0.log just sorta ends, nothing in the journal. But at least we got further. I'll try building latest intel DDX and stuff before reporting that one. Looks like this one is OK at least with drm-intel-fixes.
Comment 12 Jesse Barnes 2013-12-05 20:35:55 UTC
Great, thanks Adam.  If the new DDX still doesn't work you could try with -verbose and drm.debug=0x6 to see if anything weird is going on.  Maybe it's more backlight fail.
Comment 13 Adam Williamson 2013-12-05 20:54:14 UTC
No dice with the X issue with an F21 image that has pretty recent versions of DDX and everything else in the stack, unfortunately. I haven't had time to debug it any further, been running around fighting Fedora 20 release fires :) When things quiet down a bit I'll take another crack at it and file a bug in the appropriate place.
Comment 14 Adam Williamson 2013-12-30 02:34:30 UTC
X is still failing with current bits from Rawhide, filed as https://bugs.freedesktop.org/show_bug.cgi?id=73133 .
Comment 15 Adam Williamson 2014-01-16 22:07:17 UTC
Hrm. Now I'm not 100% sure this is actually fixed. I think instead another bug may have showed up and messed with us:

https://bugzilla.kernel.org/show_bug.cgi?id=68291

whenever I started getting the Baytrail pinctrl driver enabled in my kernel builds - which unfortunately I'm not keeping really strict records about :( - that bug started happening to me. It's a crash early in boot when initializing the graphics hardware; once that's happened, I think modesetting becomes a dead letter.

Now we've figured out a fix/workaround for that bug...I'm back to KMS producing a black screen :(

That is, with a 3.13rc8 kernel and the patches for https://bugzilla.kernel.org/show_bug.cgi?id=68291 and https://bugzilla.kernel.org/show_bug.cgi?id=67911 applied, I get a blank screen when KMS kicks in. Booting with nomodeset is successful.

The two patches we thought fixed this - "Check VBT for eDP ports on VLV" and "Simplify DP vs. eDP detection" - were merged into Linus' tree on 2013-11-28, so I'm pretty sure they ought to be in rc8, right?
Comment 16 Adam Williamson 2014-01-16 22:50:19 UTC
Created attachment 92249 [details]
dmesg from 3.13rc8 + fixes for 68291 and 67861

Here's my latest dmesg, anything different?
Comment 17 Jacek Danecki 2014-01-20 23:24:07 UTC
I've observed similar issues on Asus T100.

For kernel 3.12 I've added parameter video=VGA-1:1368x768@60 to kernel command line, and it fixed issue with screen.

For kernel 3.13-rc8 from git://people.freedesktop.org/~danvet/drm-intel
branch: for-linux-next commit: 16b23af I've reverted below commit, and now 
I can boot without black screen.

commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Sep 10 14:54:42 2013 -0700

    drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT
Comment 18 Jani Nikula 2014-01-21 11:14:19 UTC
(In reply to comment #17)
> I've observed similar issues on Asus T100.
> 
> For kernel 3.12 I've added parameter video=VGA-1:1368x768@60 to kernel
> command line, and it fixed issue with screen.
> 
> For kernel 3.13-rc8 from git://people.freedesktop.org/~danvet/drm-intel
> branch: for-linux-next commit: 16b23af I've reverted below commit, and now 
> I can boot without black screen.

Generally prefer the drm-intel-nightly branch.

> commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Tue Sep 10 14:54:42 2013 -0700
> 
>     drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT

Adam, does reverting the above commit fix the issue for you?
Comment 19 Adam Williamson 2014-01-21 15:04:55 UTC
Jani: I'll find that out today.
Comment 20 Benjamin Tissoires 2014-01-24 04:14:43 UTC
Created attachment 92711 [details]
xorg.conf with 800x1280 modeset

I managed to get kms + X working on a Lenovo Miix 2 today (basically same chip that the Dell Venue pro 8) with 3.13 + F20:
I used both hints given by Jacek: append "video=VGA-1:800x1280@60" to the command line and revert commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a.

This gives a good kms on a 3.13 kernel (no black screen anymore, console OK), but X fails with garbled display. So I just add the correct mode to xorg.conf (attached), and it's ok now.

I will try later the latest intel-drm tree to see if it has been fixed upstream, but I think it is "just" that the intel CRC do not manage to get the correct EDID to the attached display.
Comment 21 Adam Williamson 2014-01-24 04:15:55 UTC
Sorry I didn't get back yet, got distracted. I just built a new image, but I think my V8P's battery died, I'm charging it back up again now...
Comment 22 Adam Williamson 2014-01-24 07:00:59 UTC
My latest live image just flat out doesn't boot past grub, for some reason. No idea what's going on. Two confirmations sounds good, though. I'll poke at mine tomorrow if I get the time.
Comment 23 Adam Williamson 2014-02-07 09:08:52 UTC
OK, after I finally bashed my way past a bunch of other bugs, can confirm what others report: reverting "re-enable hotplug detect based probing on VLV/BYT" 'fixes' this for me too, and I can get KMS console and X by forcing an 800x1280 video mode after reverting that patch,

I'll open a new bug for the problem with auto-detecting the mode.
Comment 24 Adam Williamson 2014-02-07 09:14:48 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=74657 for the mode detection issue.
Comment 25 Adam Williamson 2014-02-11 03:02:11 UTC
https://bugzilla.kernel.org/show_bug.cgi?id=68451 is probably relevant here: Ville seems to have figured out that the displays on these devices are actually connected via DSI.
Comment 26 Jani Nikula 2014-02-11 07:23:20 UTC
(In reply to comment #25)
> https://bugzilla.kernel.org/show_bug.cgi?id=68451 is probably relevant here:
> Ville seems to have figured out that the displays on these devices are
> actually connected via DSI.

They *may* be connected via DSI. To make sure, please provide register dump using 'tools/quick_dump/quick_dump.py -a' from intel-gpu-tools [1].

If this one uses a DSI panel, I'm not sure how we should handle it, as there's no VBT block for MIPI DSI:

[    8.813116] [drm:parse_mipi], No MIPI BDB found


[1] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Comment 27 Adam Williamson 2014-02-11 07:59:48 UTC
I've been trying. quick_dump does not run when compiled and installed as part of fedora's xorg-x11-drv-intel. it looks like its attempt to find the _chipset module that seems to be compiled into I915ChipsetPython.so does not work. I've got almost no experience with how that stuff works in python3, so I really can't fix it.
Comment 28 Adam Williamson 2014-02-11 08:10:09 UTC
i'll get a compiled tree over to the tablet somehow and run it that way, it's just i have a nice clean setup for doing things via package builds and not so much for raw source tree builds...
Comment 29 Jani Nikula 2014-02-11 08:15:57 UTC
(In reply to comment #28)
> i'll get a compiled tree over to the tablet somehow and run it that way,
> it's just i have a nice clean setup for doing things via package builds and
> not so much for raw source tree builds...

That would be appreciated. I've only ever used self built igt, so don't know about packaging... We should also fix intel_reg_dumper for BYT; for now only the quick_dump.py tool works.
Comment 30 Adam Williamson 2014-02-11 17:43:23 UTC
Created attachment 93877 [details]
quick_dump.py -a output on v8p

Adding the quick_dump.py -a output from a v8p here too.
Comment 31 Daniel Vetter 2014-02-11 20:17:21 UTC
Note to everyone for whom the video=VGA-1:1366x768 w/a doesn't work any more: You need to add an e at the end, like this: video=VGA-1:1366x768e
Comment 32 Jacek Danecki 2014-02-11 22:47:13 UTC
I've checked today's on Asus T100TA
drm-intel-nightly: 2014y-02m-11d-17h-13m-38s integration manifest
with parameters:
video=VGA-1:1366x768@60e
or
video=VGA-1:1366x768@60 
and
with or without reverted commit 16b23af.
All of these configurations finished with black screen after i915 was loaded.

When I've switched back to
 drm-intel-nightly: 2014y-02m-07d-17h-04m-06s integration manifest
configuration with video=VGA-1:1366x768@60 and reverted commit 16b23af worked fine.
Comment 33 Adam Williamson 2014-02-11 23:45:26 UTC
jacek: so, that sounds like a new bug in drm-intel-nightly, possibly to be filed separately? this one's already getting a tad jumbled.
Comment 34 Jacek Danecki 2014-02-11 23:52:00 UTC
Yeah, it looks like new bug, but I've no time for bisection yet.
Comment 35 Adam Williamson 2014-02-12 03:52:58 UTC
The 'e' trick works here too, though it causes a whole bunch of warn_slowpath_common's , it looks like. More later.
Comment 36 Adam Williamson 2014-02-12 03:53:57 UTC
er, sorry - that is, I can drop the reversion of the hotplug change and still get successful modesetting if I use the 'e' trick, but I get a bunch of warn_slowpath_commons which look like they come from the output detection code.
Comment 37 Adam Williamson 2014-02-12 06:52:36 UTC
Oh, it's not a warn_slowpath_common, doesn't look like, just a warn. Here's the first untainted one, will attach the complete boot log:

Feb 11 14:46:17 fedlet.happyassassin.net kernel: ------------[ cut here ]------------
Feb 11 14:46:17 fedlet.happyassassin.net kernel: WARNING: CPU: 0 PID: 253 at drivers/gpu/drm/i915/intel_dp.c:109 intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915]()
Feb 11 14:46:17 fedlet.happyassassin.net kernel: invalid max DP link bw val 0, using 1.62Gbps
Feb 11 14:46:17 fedlet.happyassassin.net kernel: Modules linked in: mmc_block i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video sdhci_acpi sdhci mmc_core usb_storage
Feb 11 14:46:17 fedlet.happyassassin.net kernel: CPU: 0 PID: 253 Comm: systemd-udevd Not tainted 3.14.0-0.rc2.git1.1.1awb.i686 #1
Feb 11 14:46:17 fedlet.happyassassin.net kernel: Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A04 12/04/2013
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  c0d679c7 2230178a 00000000 f64979fc c0abbcdb f6497a3c f6497a2c c04514ee
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  f91d7ca0 f6497a5c 000000fd f91d7abc 0000006d f919241f f919241f f6401300
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  00006257 f6a6d800 f6497a48 c045154e 00000009 f6497a3c f91d7ca0 f6497a5c
Feb 11 14:46:17 fedlet.happyassassin.net kernel: Call Trace:
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0abbcdb>] dump_stack+0x48/0x60
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04514ee>] warn_slowpath_common+0x7e/0xa0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f919241f>] ? intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f919241f>] ? intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c045154e>] warn_slowpath_fmt+0x3e/0x60
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f919241f>] intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f91928fe>] intel_dp_mode_valid+0x2e/0xd0 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f80f5167>] drm_helper_probe_single_connector_modes+0x1b7/0x360 [drm_kms_helper]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f80f75e1>] drm_fb_helper_probe_connector_modes.isra.3+0x41/0x60 [drm_kms_helper]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f80f8515>] drm_fb_helper_initial_config+0x165/0x490 [drm_kms_helper]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04a902b>] ? trace_hardirqs_on+0xb/0x10
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f91beafe>] intel_fbdev_initial_config+0x1e/0x20 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f914ffee>] i915_driver_load+0xd7e/0xdb0 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0974250>] ? intel_alloc_coherent+0x120/0x120
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f8c4b60c>] drm_dev_register+0x6c/0x140 [drm]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f8c4d6ea>] drm_get_pci_dev+0x8a/0x1e0 [drm]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04a902b>] ? trace_hardirqs_on+0xb/0x10
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f914c665>] i915_pci_probe+0x35/0x60 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0753c7f>] pci_device_probe+0x6f/0xc0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c061d475>] ? sysfs_create_link+0x25/0x40
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0825260>] driver_probe_device+0x110/0x380
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0753bd2>] ? pci_match_device+0xb2/0xc0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0825589>] __driver_attach+0x79/0x80
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0825510>] ? __device_attach+0x40/0x40
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c08234e7>] bus_for_each_dev+0x57/0xa0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0824c8e>] driver_attach+0x1e/0x20
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0825510>] ? __device_attach+0x40/0x40
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c08248a7>] bus_add_driver+0x157/0x230
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0825b69>] driver_register+0x59/0xe0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c075261a>] __pci_register_driver+0x4a/0x50
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f8c4d945>] drm_pci_init+0x105/0x110 [drm]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f85d8000>] ? 0xf85d7fff
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f85d8062>] i915_init+0x62/0x64 [i915]
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04004a2>] do_one_initcall+0xd2/0x190
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<f85d8000>] ? 0xf85d7fff
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0442f57>] ? set_memory_ro+0x37/0x40
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04dd62c>] load_module+0x1a7c/0x2480
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04d9559>] ? copy_module_from_fd.isra.46+0x109/0x1a0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c04de1dd>] SyS_finit_module+0x8d/0xd0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0564af3>] ? vm_mmap_pgoff+0x93/0xb0
Feb 11 14:46:17 fedlet.happyassassin.net kernel:  [<c0acd70d>] sysenter_do_call+0x12/0x38
Feb 11 14:46:17 fedlet.happyassassin.net kernel: ---[ end trace ab0ef9173a974a7f ]---
Feb 11 14:46:17 fedlet.happyassassin.net kernel: ------------[ cut here ]------------

So yeah, it looks like the hotplug reversion is not needed if you add 'e' to the video= force.
Comment 38 Adam Williamson 2014-02-12 06:54:11 UTC
Created attachment 93903 [details]
full journalctl from a boot with 3.14.0-0.rc2.git1.1.1awb (hotplug detection enabled, video=800x1280@75e)
Comment 39 Adam Williamson 2014-02-12 06:57:22 UTC
So...do we still need this open for anything? I don't think I'm carrying anything in Fedlet for this specific bug ATM, and we're covering the 'display detection / mode selection doesn't work because DSI' stuff in https://bugs.freedesktop.org/show_bug.cgi?id=74657 . I think we can close this one now. Let me know if there's a reason to keep it open.

Is the warning worth reporting separately?
Comment 40 Jani Nikula 2014-02-12 10:20:30 UTC
(In reply to comment #39)
> So...do we still need this open for anything? I don't think I'm carrying
> anything in Fedlet for this specific bug ATM, and we're covering the
> 'display detection / mode selection doesn't work because DSI' stuff in
> https://bugs.freedesktop.org/show_bug.cgi?id=74657 . I think we can close
> this one now. Let me know if there's a reason to keep it open.
> 
> Is the warning worth reporting separately?

I'm not sure. Either it's a PEBKAC/feature or a bug.

I think it's caused by you omitting the connector name in your video= parameter, which leads to connector ->fill_modes() callback for display port, which in turn fails because there is no monitor in the DP.

Please try with video=VGA-1:800x1280@75e.


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.