<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - display corruption on GPD Pocket (Cherry Trail Atom x7-Z8750)"
href="https://bugs.freedesktop.org/show_bug.cgi?id=105834">105834</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>display corruption on GPD Pocket (Cherry Trail Atom x7-Z8750)
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>critical
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>sobukus@sourcemage.org
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=138464" name="attach_138464" title="Kernel messages with drm.debug=0xe glitch after 24s, before 400s">attachment 138464</a> <a href="attachment.cgi?id=138464&action=edit" title="Kernel messages with drm.debug=0xe glitch after 24s, before 400s">[details]</a></span>
Kernel messages with drm.debug=0xe glitch after 24s, before 400s
I was trying to use drm-tip, but that did not boot at all for me. The device is
a GPD Pocket using the Atom x7-Z8750. Linux support for this is a community
effort, with lots of work by Hans de Goede in his tree at
<a href="https://github.com/jwrdegoede/linux-sunxi.git">https://github.com/jwrdegoede/linux-sunxi.git</a> . It is a messed up little
device, including the tablet screen that needs rotation for a normal desktop
experience and an audio circuity that we might get working properly at some
time in the future …
I hope the display hardware apart from the rotation is standard enough.
The newest kernel I was able to try is commit ae718bc of
<a href="https://github.com/jwrdegoede/linux-sunxi.git">https://github.com/jwrdegoede/linux-sunxi.git</a>, which corresponds to 4.16.0-rc5
of sorts. I tried the same config with drm-tip, but the kernel failed to boot
(cannot find root, or hangs). The base system is Xubuntu 17.10, installed from
a 17.04 image with adaptions to the GPD pocket.
The issue I have is also discussed at
<a href="https://github.com/nexus511/gpd-ubuntu-packages/issues/30">https://github.com/nexus511/gpd-ubuntu-packages/issues/30</a> at some length. There
are notes, reproduction helpers, and screenshots on
<a href="https://sobukus.de/gpd/displayglitch/">https://sobukus.de/gpd/displayglitch/</a> .
I can run the device either with xf86-video-intel (which I prefer because of a
working TearFree option) or xf86-video-modesetting. With the latter, I observe
abnormal tearing abount the end of the first third from the left (top before
rotation) of the screen. Maybe that is related. The main issue I have manifests
with the xf86-video-intel driver: After some time of use, the screen shifts
vertically (horizontally for the non-rotated view) and possibly the colors
change (swapping of color channels). This state is reversible, if I continue
using the device, more shift can be triggered, but also sometimes it reverts to
the normal good state.
The corruption stays there, down to the splash screen when powering down the
device. It is only changed if the random trigger is successful again or if I
force a change like a different resolution or a rotation by 90 degrees
(switching to left and then back to right rotation, a simple flip, does not fix
hings). This software reversibleness is what makes me doubt that simply faulty
hardware is to blame.
I devised a complicated scheme of triggering the corruption by
remote-controlling evince with a PDF file, but all that is needed is actually
the usual simple 60 fps color flip video for demonstrating tearing, more likely
_anything_ causing a certain number of screen updates to increase chances.
Anyhow, you can see some history in
<a href="https://sobukus.de/gpd/displayglitch/README.txt">https://sobukus.de/gpd/displayglitch/README.txt</a>, along with some statistics
that give a hint on how reliably I can reproduce this in a certain time.
It was suggested to me in the intel-gfx IRC channel that this should be a bug
in the DRM component. An alternative explanation might be defective hardware,
as I seem to be in a small minority of people using the device with this
intensity of corruption. But I am not the _only_ one. Maybe there is something
in hardware behaviour that varies sufficiently between devices to only trigger
this for very few.
The kernel shows no messages during the glitch occurence with drm.debug=0xe .
Anything more I can do? Some state dump before/after glitch?
In the dmesg I am going to attach, the glitch happens between these two lines:
[ 24.506143] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready
[ 459.656003] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]]
[CONNECTOR:79:DSI-1]
The drm message here just relates to me switching modes to fix the corruption.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>