Following on from https://bugs.freedesktop.org/show_bug.cgi?id=71977 . With kernel 3.14-rc1 plus patches to fix various boot failures plus the reversion of "drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT" (that's 71977), multiple testers have confirmed you can get KMS to work on Bay Trail tablets. On the Venue 8 Pro, the modesetting does not correctly discover the device's preferred mode, though, which is 800x1280 (the screen's 'native' orientation is portrait). It decides on 1024x768. I've captured the EDID of the screen - I'll attach it. The thing that leaps out to me as being incorrect is that the minimum hsync and vsync are both set to 0, which is I believe outside the spec (Wikipedia sez it should be in the range of 1–255 kHz). If I run monitor-parse-edid on the unmodified EDID, it barfs: [adamw@adam data]$ monitor-parse-edid AUO00C4.bin bad HorizSync with a version hex edited to bump the min hsync and vsync to 10 (hex, so 16kHz), it works: [adamw@adam data]$ monitor-parse-edid AUO00C4_mod.bin EISA ID: AUO00c4 EDID version: 1.3 EDID extension blocks: 0 Screen size: 10.8 cm x 17.2 cm (8.00 inches, aspect ratio 0.63) Gamma: 3.55 Digital signal Max video bandwidth: 80 MHz HorizSync 16-173 VertRefresh 16-60 # Monitor preferred modeline (60.0 Hz vsync, 78.0 kHz hsync, ratio 0.62, 188 dpi) ModeLine "800x1280" 76.75 800 824 828 984 1280 1288 1292 1300 -hsync -vsync I know the kernel code isn't the same as monitor-parse-edid, but it still seems indicative.
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.
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.