I recently bought a WinBook TW-700 tablet for its low price and Intel/amd64 compatibility. I got Debian installed on a USB drive. The tablet uses 32-bit EFI only, no BIOS compatibility mode. If I boot with nomodeset, the tablet is usable with no acceleration. If I boot without nomodeset, the tablet shows the boot messages up until drm is initialized, and then the screen goes black. I can ssh into the tablet (via USB Ethernet) and it seems to think the display is operational. I have tried the latest 4.0-rc4 and intel-drm nightly kernels from Ubuntu's kernel PPA, but both exhibit the same problems. I will attach dmesg with drm.debug=0xe and the Xorg.0.log after I tried running xinit from the SSH session.
Created attachment 114506 [details] Xorg log from Winbook tablet
Created attachment 114507 [details] dmesg from Debian unstable default 3.16 kernel
Created attachment 114508 [details] dmesg from Ubuntu kernel PPA 4.0-rc4 kernel
Yes, it looks mostly intact. So either our DSI programming slipped up, or perhaps the backlight.
The backlight does remain on after the display blanks, so it's not a case of just not being able to see the screen.
Hmm, can you try v3.19?
I will try 3.19 when I get home tonight and post dmesg.
Created attachment 114563 [details] dmesg from Ubuntu kernel PPA 3.19 kernel
(In reply to Adam Honse from comment #8) > Created attachment 114563 [details] > dmesg from Ubuntu kernel PPA 3.19 kernel Was there an image on screen with that or not...?
No, same problem as with the other kernels.
I've been reading through this older bug report that documents a similar issue: https://bugzilla.kernel.org/show_bug.cgi?id=68451 I installed the Ubuntu PPA 3.13 kernel and started with video=VGA-1:800x1280e. With this, the Intel framebuffer does display and I can launch an X server with xinit. Once the X server starts however, the display becomes mangled. I can see that it is rendering (if I run glxgears) but only because random pixels are changing. If I switch VT back to another terminal the screen is readable again. It appears that xinit is setting the mode to 1024x768 for some reason. I then did the following to set an 800x1280 mode manually: adam@Adam-WinBook:~$ xrandr --display :0 Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.00* 800x600 60.32 56.25 848x480 60.00 640x480 59.94 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) adam@Adam-WinBook:~$ xrandr --display :0 --newmode "800x1280" 100.56 800 832 1208 1240 1280 1306 1319 1345 adam@Adam-WinBook:~$ xrandr --display :0 --addmode VGA1 800x1280 adam@Adam-WinBook:~$ xrandr --display :0 --output VGA1 --mode 800x1280 Now the display is correct and I can run "glxinfo | grep renderer" and see Bay Trail and run glxgears. Is there any information I can gather about the panel from this setup that would help in determining the issues it has on the newer kernels? I'll post a dmesg and Xorg.0.log for this as well.
Created attachment 114600 [details] Xorg log from 3.13 Ubuntu PPA kernel with video=VGA-1:800x1280e
Created attachment 114601 [details] dmesg from Ubuntu kernel PPA 3.13 kernel
Created attachment 114627 [details] intel_reg_dumper from working 3.13
Created attachment 114628 [details] intel_reg_dumper from non-working 4.0-rc5
Unfortunately for BYT you need to use the tools/quick_dump/quick_dump.py in IGT source. intel_reg_dumper doesn't support BYT :( http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
I compiled it but when I run quick_dump.py I get: root@Adam-WinBook:/home/adam/intel-gpu-tools/tools/quick_dump# ./quick_dump.py Traceback (most recent call last): File "./quick_dump.py", line 17, in <module> import chipset File "/home/adam/intel-gpu-tools/tools/quick_dump/chipset.py", line 28, in <module> _chipset = swig_import_helper() File "/home/adam/intel-gpu-tools/tools/quick_dump/chipset.py", line 24, in swig_import_helper _mod = imp.load_module('_chipset', fp, pathname, description) File "/usr/lib/python3.4/imp.py", line 243, in load_module return load_dynamic(name, filename, file) ImportError: /home/adam/intel-gpu-tools/tools/quick_dump/_chipset.so: undefined symbol: _Ux86_64_getcontext
Created attachment 114678 [details] quick_dump from 3.13
Created attachment 114679 [details] quick_dump from 4.0-rc5
Compiled with --without-libunwind and it works now.
Created attachment 115038 [details] opregion from /sys/kernel/debug/dri/0/i915_opregion
Created attachment 115039 [details] opregion run through intel_bios_reader
(In reply to Adam Honse from comment #17) > I compiled it but when I run quick_dump.py I get... For reference, I'll split this out into https://bugs.freedesktop.org/show_bug.cgi?id=90814
Presumed fixed, please reopen if the problem persists with latest kernels.
Problem still exists with 4.5.1. From the kernel log, I see a line: Feb 19 02:52:00 winbook7 kernel: [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip which is mentioned in bug report https://bugs.freedesktop.org/show_bug.cgi?id=85977 I also tried to blacklist i915 when the system boots up and then to manually load the module to avoid the timing issue that PWM might come after i915 is loaded, but to no vail.
Created attachment 123158 [details] dmesg from arch 4.5.1
(In reply to zeng.shixin from comment #25) > Problem still exists with 4.5.1. I'll rephrase, presumed fixed upstream, in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. Please check with that. (In reply to zeng.shixin from comment #26) > dmesg from arch 4.5.1 When running drm-intel-nightly, please attach dmesg all the way from boot, with drm.debug=14 module parameter set, and definitely without modprobe.blacklist=i915 (although i915 seems to get probed anyway).
Created attachment 123273 [details] dmesg from intel-drm-nightly fetch on 04/25/2016
i915 is still complaining about PWM. I added some prints, and found that ACPI seemed to be reporting "80860F09" not present, which I think is the pwm chip for this platform. But I might be wrong, since I am not familiar with driver development.
Even when I can't see the screen, I can _blindly_ log in and start Xserver, and even run xrandr: [zsx@winbook7 ~]$ xrandr --display :0 Screen 0: minimum 8 x 8, current 800 x 1280, maximum 32767 x 32767 DSI1 connected 800x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 800x1280 60.00*+ 800x600 60.32 56.25 640x480 59.94 400x640 60.00 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) However, screen is still blank (not completely black, but glooming).
Seems like there is some progress. On Irbis NB41 with Z3735F I observe similar issue with Linux 4.4, 4.8 and 4.10, but it's no longer reproducible since Linux 4.11 (rc3 was tested). One week ago I also seen reports that some people still have blank screen with 4.11, but with drm-tip it's working now. Please test again with 4.11 and drm-tip.
I can confirm drm-intel-nightly as of today works. Haven't tested upstream kernel yet. Finally I have Xorg running on my winbook 7. Thanks!
Thanks for the follow-ups, closing. Please don't hesitate to file new bugs for any pending issues. (Please refrain from reopening this one as it has so much old history that has lost its relevance.) Thanks.
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.