[Bug 105834] New: display corruption on GPD Pocket (Cherry Trail Atom x7-Z8750)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=105834

            Bug ID: 105834
           Summary: display corruption on GPD Pocket (Cherry Trail Atom
                    x7-Z8750)
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: sobukus at sourcemage.org
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 138464
  --> https://bugs.freedesktop.org/attachment.cgi?id=138464&action=edit
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
https://github.com/jwrdegoede/linux-sunxi.git . 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
https://github.com/jwrdegoede/linux-sunxi.git, 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
https://github.com/nexus511/gpd-ubuntu-packages/issues/30 at some length. There
are notes, reproduction helpers, and screenshots on
https://sobukus.de/gpd/displayglitch/ .

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
https://sobukus.de/gpd/displayglitch/README.txt, 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180331/dcf39a1e/attachment.html>