Created attachment 131526 [details] Syslog for the faulty Pipo X8S (Z3735F) unit I have two very similar Baytrail devices: Pipo X8 and Pipo X8S. The former (X8) is based on Z3736F and runs fine. The latter (X8S) is based on Z3735F and gets a blank screen once the i915 driver is loaded. Both units run identical set up software-wise: distro: Gentoo kernel: drm-tip branch (713f8e of 16 May) xorg: 1.19.2 xf86-video-intel: 2.99.917_p20170216 Comparing the logs I can see the faulty unit seems to be missing some MIPI initialization commands. Here is the diff of the logs between the good unit (left) and the faulty one (right): https://www.diffchecker.com/tv4c7jTl The HDMI output on the faulty unit works fine. Attached are the logs for both the good and the faulty units with drm.debug=0x1e
Created attachment 131527 [details] Syslog for the good Pipo X8 (Z3736F) unit
The backlight is working fine on both units with drm-tip branch. I've tried kernel 4.11.1 with same results (except the backlight does not work on either of the units).
libdrm: 2.4.75 mesa: 13.0.5 I will try later versions to see if it makes a difference.
(In reply to Innocent Bystander from comment #3) > libdrm: 2.4.75 > mesa: 13.0.5 > > I will try later versions to see if it makes a difference. Never mind, I realized this has nothing to do with the issue. The screen goes blank as soon as the i915 driver is loaded, even without the X server.
Sprinkling a few printks in the kernel I've discovered that in the file `intel_bios.c` inside the function `parse_mipi_sequence()` a call to `find_panel_sequence_block()` here: https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/i915/intel_bios.c#n984 returns 2-byte long sequence block with the the first seq_id set to 0 (MIPI_SEQ_END). This causes `intel_dsi_vbt_exec_sequence()` in `intel_dsi_vbt.c` to simply return here: https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/i915/intel_dsi_vbt.c#n429 I am really just shooting in the dark here, as I've no clue what all of this means. My guess is these are some sort of initialization sequences for the MIPI panel. On the other hand, on the working unit the size of the sequence block is 1350 and it contains seq_ids: 1, 5, 2, 3 and 4, which would be MIPI_SEQ_{DEASSERT_RESET,ASSERT_RESET,INIT_OTP,DISPLAY_ON,DISPLAY_OFF}. If somebody could point me in the right direction, I would very much appreciate that.
Tried dumping the bios with: echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom cat /sys/devices/pci0000:00/0000:00:02.0/rom and with: intel_bios_dumper but all's I get is "Input/output error" and the following in the syslog: ... i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xf581
Sprinkled a few more printks here and there. Discovered an interesting thing in the function `find_section()` here: http://elixir.free-electrons.com/linux/v4.6/source/drivers/gpu/drm/i915/intel_bios.c#L78 The faulty unit (X8S) reports section 53 (BDB_MIPI_SEQUENCE) at offset 4650 with length of 7! Whereas the good unit (X8) reports the same offset, but the length of 1355. All other sections are identical. Sounds like a firmware bug?...
(In reply to Innocent Bystander from comment #7) > Sprinkled a few more printks here and there. Discovered an interesting thing > in the function `find_section()` here: > > http://elixir.free-electrons.com/linux/v4.6/source/drivers/gpu/drm/i915/ > intel_bios.c#L78 > > The faulty unit (X8S) reports section 53 (BDB_MIPI_SEQUENCE) at offset 4650 > with length of 7! Whereas the good unit (X8) reports the same offset, but > the length of 1355. All other sections are identical. > > Sounds like a firmware bug?... Actually not necessarily. It seems it's simply missing from the VBT. How does Windows figure out how to deal with the panel then? Is there a fallback sequences that can be used?
So, I've extracted contents of the sequence block returned by `find_panel_sequence_block()` which contains all MIPI sequences on the good unit. Added it to the kernel as a static u8[] and made the various `dev_priv->vbt.dsi.sequence[...]` point to it. I was now able to see the missing mipi_exec_... commands in the log. Sadly, this did not make any difference. It looks like I am on a completely wrong path. Can't really think of what to do next... If anybody is reading this, please chime in. I could really use some pointers here
The VBT with the sequences is available at /sys/kernel/debug/dri/0/i915_vbt. Please attach it for both working and non-working machines. You can use intel_vbt_decode tool from IGT to decode them. Not sure if the decoder supports all the little details of the DSI sequences though.
Btw there are no guarantees the displays are the same.
(In reply to Jani Nikula from comment #11) > Btw there are no guarantees the displays are the same. Based on the logs looks like they have way different timings.
Created attachment 131614 [details] VBT of the good Pipo X8
Created attachment 131615 [details] VBT of the faulty Pipo X8S
Jani, I've attached VBTs for both devices. Here is also diff of outputs for the intel_bios_reader: https://www.diffchecker.com/VBiyL6tM The panels do seem to have different timings... But where does it take us?
Perhaps an irrelevant comment, by these boxen came with Android 4.4, which (obviously) works
(In reply to Jani Nikula from comment #11) > Btw there are no guarantees the displays are the same. I took both units apart and they do indeed have completely different panels. The working unit has Innolux N070ICN-GB1 panel: http://www.panelook.com/N070ICN-GB1_Innolux_7.0_LCM_overview_20644.html The faulty unit has Chunghwa CLAA070WP0B panel: http://www.cptt.com.tw/index.php?option=com_wrapper&Itemid=201 http://bit.ly/2rcY247
The VBT for the non-working Pipo X8S does not seem to have any real contents in the MIPI DSI sequence block, which is surprising. I can think of two scenarios here: 1) You've changed the boot mode when installing. It's surprisingly common that the VBT is different for UEFI vs. legacy boot. Though this is usually more of an issue on Windows based machines, not sure about Android. (But I guess this is originally dual boot?) 2) The vendor failed to make the panel work using the VBT sequences, and opted to hack it all in the driver. It's usual that the vendor kernels have quite a bit of delta from upstream. You could try to find the sources for the kernels used in both devices, and compare. In any case effectively reverse engineering this kind of non-standard, typically one-off products is not a priority in the upstream driver. If it works, great. If you figure out how to make it work, and contribute upstream, great. But we won't go out of our way to fix this.
(In reply to Jani Nikula from comment #18) > The VBT for the non-working Pipo X8S does not seem to have any real contents > in the MIPI DSI sequence block, which is surprising. I can think of two > scenarios here: > > 1) You've changed the boot mode when installing. It's surprisingly common > that the VBT is different for UEFI vs. legacy boot. Though this is usually > more of an issue on Windows based machines, not sure about Android. (But I > guess this is originally dual boot?) The unit only has UEFI mode -- no legacy boot. I kept it as-is and I am booting in UEFI using GRUB. It originally came with Windows and Android dual boot option. > 2) The vendor failed to make the panel work using the VBT sequences, and > opted to hack it all in the driver. It's usual that the vendor kernels have > quite a bit of delta from upstream. You could try to find the sources for > the kernels used in both devices, and compare. I don't think that's the case. On Windows they are running Intel HD Graphics driver. On Android side itsa anzhen4_mrd8_w base, which I believe is a base for Intel BayTrail-T devices. I installed a terminal app and discovered that they are running kernel 3.10.20 and using i915 driver. Sadly I have failed horribly trying to compile an Android kernel. > In any case effectively reverse engineering this kind of non-standard, > typically one-off products is not a priority in the upstream driver. If it > works, great. If you figure out how to make it work, and contribute > upstream, great. But we won't go out of our way to fix this. BTW, I've had exact same phenomena with some of the Dell Venue 8 Pro tablets. They would just go blank as soon as the i915 driver loaded. Similarly, they've worked totally fine in Windows with Intel HD Graphics driver. I've abandoned them in favor of these units... And now I am back to square zero.
Whatever the Windows driver does is not applicable to the Linux driver. Among other things, IIUC they can provide the VBT in .INF files or something like that too. Seeing an "i915" driver does not mean that it's the upstream i915 driver. It may have been backported, forward ported, and in general modified in various ways.
One thing I noticed is that Windows does not seem to reset the screen. It simply takes over the screen from EFI and starts drawing on top of it. On the other hand, the Linux driver seems to reset the panel, after which point the screen remains blank. Is it possible to tell the driver not to reset the panel?
If you still have access to yours Dell Venue 8 Pro I advice you try Linux 4.12 on it: https://bugs.freedesktop.org/show_bug.cgi?id=82880#c38
(In reply to russianneuromancer from comment #22) > If you still have access to yours Dell Venue 8 Pro I advice you try Linux > 4.12 on it: https://bugs.freedesktop.org/show_bug.cgi?id=82880#c38 Doesn't work for me. At the time when I was planning to use DV8P I was able to get around 20 units working and had 4 duds (screen turned blank as soon as i915 loaded). This was with kernel 4.2.8. By "working" I mean I had a picture, but no backlight control with the backlight being stuck at 100% (which suited me). When I switched to the Pipo units, I started using drm-tip at commit 62b63dcce03c09d31c1f297af4b6245a5159d923 of 2017-05-16, which also includes the patch you've mentioned. So, I just grabbed a working (good) and non-working (fail) DV8P units and loaded the above kernel onto them and both units go blank as soon as i915 loads. I do have control of the backlight now. But no picture. I will upload logs and VBTs for both. The funny thing is that the unit that used work with 4.2.8 is also missing MIPI sequences in VBT.
Created attachment 132145 [details] Syslog for the "good" DV8P unit By "good" I mean it used to work with 4.2.8 but still goes blank with 4.12 (drm-tip)
Created attachment 132146 [details] VBT of the "good" DV8P unit
Created attachment 132147 [details] Syslog for the "fail" DV8P unit By "fail" I mean it used to go blank with 4.2.8 and still goes blank with 4.12 (drm-tip)
Created attachment 132148 [details] VBT of the "fail" DV8P unit
I also found this interesting bit: https://lists.freedesktop.org/archives/intel-gfx/2011-October/012811.html. An effort by Keith Packard to create flicker-free boot. But it doesn't look like anything materialized from that.
Adding another failed DV8P unit. Used Hans de Goede's config along with Linux GIT. Where do I pull the VBT info from?
Created attachment 132264 [details] Boot log from my DV8P With debug and drm.debug enabled
(In reply to Parker Reed from comment #29) > Adding another failed DV8P unit. Used Hans de Goede's config along with > Linux GIT. > > Where do I pull the VBT info from? You can access VBT through: /sys/kernel/debug/dri/0/i915_vbt Use intel_read_bios from intel-gpu-tools to decode it.
Created attachment 132267 [details] Another failing DV8P VBT Here's mine. Did a diff with the previously posted VBT and there are quite a few differences. Pulled this while booted into the "failed" state (SSH)
Parker, the differences could be because I am using an older version of intel-gpu-tools. The MIPI sequences (block 53) seems to be identical on both units: https://www.diffchecker.com/98E7NTrG
Created attachment 132269 [details] Screenshot on "working" DV8P So after doing some digging I ran across this issue https://bugs.freedesktop.org/show_bug.cgi?id=100356 Having all else fail, I figured I'd try the "hacky" method. Already had drm-tip cloned and compiled, so I just made that one change and recompiled. Installed and added the fastboot to my kernel args. It actually comes up and KMS works. As noted in the issue, an xrandr rotate does kill the output, but mine does show DSI info instead of "UNKNOWN"
Created attachment 132271 [details] Kernel log with "hack" So I decided to try my normal workflow of GDM plus Gnome. The kernel starts to complain a lot... (40MB log) Bunch of drm.debug output/ACPI errors. Figured I'd post this in case it helps lead to something.
(In reply to Parker Reed from comment #32) > Created attachment 132267 [details] > Another failing DV8P VBT > > Here's mine. Did a diff with the previously posted VBT and there are quite a > few differences. Pulled this while booted into the "failed" state (SSH) Please always attach these kinds of dumps as raw binary. That way we won't have any risk of having invalid data due to potential bugs in the decoder.
(In reply to Innocent Bystander from comment #21) > One thing I noticed is that Windows does not seem to reset the screen. It > simply takes over the screen from EFI and starts drawing on top of it. > > On the other hand, the Linux driver seems to reset the panel, after which > point the screen remains blank. > > Is it possible to tell the driver not to reset the panel? In the long run, that's the plan across all panels. I think you can currently try it with i915.fastboot. Might work, might not. However, that will only help the takeover at boot. If the driver does not know how to properly enable the display, it'll fail the next time you do a modeset anyway.
FWIW, tried 4.12.8 and the "failed" units still don't work (blank) Jani, I've tried i915.fastboot but it didn't seem to make any difference. Do I need to apply the "dirty" hack mentioned above?
(In reply to Jani Nikula from comment #37) > ... In the long run, that's the plan across all panels. I think you can > currently try it with i915.fastboot. Might work, might not... (In reply to Innocent Bystander from comment #38) > Do > I need to apply the "dirty" hack mentioned above? As Jani mentioned before that could or couldn't work. No new advances have been reported in this case. Still a valid bug, please keep open. Thank you.
Hi, So there seem to be 2 issues here really: 1) The original issue of the LCD not working on the Pipo with no MIPI sequences defined in its VBT 2) Later on some comments got added about a different problem: Black screen on modesetting with Dell Venue 8 Pro (version with screen with MIPI panel index = 3) For 2. we already have bug 82880 open so lets use that bug for further discussion of the Dell issue. Note Jan Brummer has send me a Dell Venue 8 5130 with the trouble-some screen so that I could take a shot at fixing this and I've managed to come up with a patch, for details on this see bug 82880. Regards, Hans
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
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.