Bug 74657

Created attachment 93593 [details]
the V8P's EDID

Created attachment 93594 [details]
journalctl from a KMS boot *without* forcing the mode (you can see 1024x768 is picked)

The other thing to note is that if I run 'monitor-edid' directly on the tablet, I get "ERROR: timeout during EDID probe" three times (slowly, not instantly), and nothing else. I captured the EDID with a Windows tool.

From ajax today:

---

If I'm reading the dmesg there correctly, it looks like that EDID shows up on the VGA port?  Which could cause problems, since the EDID claims to be for a digital output, so we might refuse to believe it's attached to an analog port.  But also:

eb 06 20:04:30 localhost kernel: [drm:valleyview_crt_detect_hotplug], valleyview hotplug adpa=0xf40000, result 0
Feb 06 20:04:30 localhost kernel: [drm:intel_crt_detect], CRT detected via hotplug
Feb 06 20:04:30 localhost kernel: [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2
Feb 06 20:04:30 localhost kernel: [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
Feb 06 20:04:30 localhost kernel: [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] probed modes :
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 21:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 19:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 20:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 17:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa

It looks like Linux is failing to read DDC off the VGA port (possibly not surprising, the EDID might be in the VBT instead of on the other end of I2C).  But we're only going to look in the VBT for EDID for LVDS or eDP, and since this appears to be VGA not LVDS...

Anyway that could be the bug, it could also not.  If it's not that then I'd want to manually step through i915 init to figure it out.

---

Created attachment 93629 [details]
VBT from the Venue 8 Pro (/sys/kernel/debug/dri/0/i915_opregion )

Attaching the VBT from my v8p, as requested by ajax. full vbios doesn't appear to be available to userspace.

<ajax> i think the trick here really is figure out how to tell that VGA is actually LVDS

If this thing is like the Asus T100TA, then it's a DSI display (or at least DSI is how it's hooked up to the soc, might be a DSI->LVDS bridge or something actually).

See here for the Asus case:
https://bugzilla.kernel.org/show_bug.cgi?id=68451

Would be great if you can repeat the quick_dump check to make sure if it's really DSI.

Ah, neat. I strongly suspect they'll be the same, but I'll check. Just need to bump Fedora's intel-gpu-tools first :/

Having all kinds of trouble getting quick_dump built, I'm afraid - my latest attempt at building our xorg-x11-drv-intel package (where we also build intel-gpu-tools) with the latest i-g-t git snapshot failed like this:

http://kojipkgs.fedoraproject.org//work/tasks/5651/6505651/build.log

make[3]: Entering directory `/builddir/build/BUILD/intel-gpu-tools-20140207/debugger/system_routine'
  CC       eviction_macro.o
  CCLD     eviction_macro
./pre_cpp.py ./sr.g4a > sr.cpp.tmp && mv sr.cpp.tmp sr.cpp
Traceback (most recent call last):
  File "./pre_cpp.py", line 38, in <module>
    lines = file.readlines()
  File "/usr/lib/python3.3/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 16: ordinal not in range(128)
make[3]: *** [sr.cpp] Error 1

It builds fine with Python 2, but I have to pull in Python 3 to build quick_dump , and when I do that, it builds everything else with Python 3 too.

(In reply to comment #8)
> Having all kinds of trouble getting quick_dump built, I'm afraid - my latest
> attempt at building our xorg-x11-drv-intel package (where we also build
> intel-gpu-tools) with the latest i-g-t git snapshot failed like this:
> 
> http://kojipkgs.fedoraproject.org//work/tasks/5651/6505651/build.log
> 
> make[3]: Entering directory
> `/builddir/build/BUILD/intel-gpu-tools-20140207/debugger/system_routine'
>   CC       eviction_macro.o
>   CCLD     eviction_macro
> ./pre_cpp.py ./sr.g4a > sr.cpp.tmp && mv sr.cpp.tmp sr.cpp
> Traceback (most recent call last):
>   File "./pre_cpp.py", line 38, in <module>
>     lines = file.readlines()
>   File "/usr/lib/python3.3/encodings/ascii.py", line 26, in decode
>     return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 16:
> ordinal not in range(128)
> make[3]: *** [sr.cpp] Error 1
> 
> It builds fine with Python 2, but I have to pull in Python 3 to build
> quick_dump , and when I do that, it builds everything else with Python 3 too.

Some kind of locale problem. Looks like it fails the same way for me if I set LC_ALL=C. With LC_ALL=en_US.UTF-8 it builds fine.

OK, building with LC_ALL=en_US.UTF-8 does the trick, but then running the installed binary on the tablet can't import the _chipset module. I've no idea where it's supposed to be finding that, but it isn't.

oh, looks like it's built into /usr/lib/I915ChipsetPython.so , but it's not finding that...

Created attachment 93876 [details]
quick_dump.py -a output on v8p

OK, here's the 'quick_dump.py -a' output from a Venue 8 Pro.

(In reply to comment #12)
> Created attachment 93876 [details]
> quick_dump.py -a output on v8p
> 
> OK, here's the 'quick_dump.py -a' output from a Venue 8 Pro.

0x001f0008 | PIPEACONF                    | 0xe0000000
0x001e1190 | MIPIA_PORT_CTRL              | 0x80010000
0x0018b020 | MIPIA_DPI_RESOLUTION         | 0x05000320

Yeah, looks like DSI @ 1280x800 resolution.

So, I guess this doesn't need to be NEEDINFO any more - let me know if you needed something else. Would it be safe to mark this as a dupe of Alan's?

btw, it's 800x1280 resolution - the screen is native portrait.

Jani admitted to now possessing a dsi byt platform.

Please try Linus' master; this should be fixed with

commit 682b7c1c8ea8885aa681ddf530d6cf2ad4f2dc15
Merge: 16b9057804c0 bc1dfff04a5d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 12 11:32:30 2014 -0700

    Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

My V8P still has trouble with 3.16, but I filed a new bug for it - https://bugs.freedesktop.org/show_bug.cgi?id=82880 - so we could possibly close this one. The DSI support was definitely added in 3.16 and seems to be working for some folks, but not for me yet :/

(In reply to comment #18)
> My V8P still has trouble with 3.16, but I filed a new bug for it -
> https://bugs.freedesktop.org/show_bug.cgi?id=82880 - so we could possibly
> close this one. The DSI support was definitely added in 3.16 and seems to be
> working for some folks, but not for me yet :/

Closing this one as the feature has been merged; let's track remaining issues with your model at bug 82880. Thanks for the report.