Motivation ========== My GPD pocket shows screen glitches in form of a vertically shifted picture and often a color shift accompanying it, see screen photo accompanying this file, in contrast to a software screenshot where everything looks fine. The glitch can be triggered by various actions. I settled on scrolling around in a PDF presentation using an automated instance of evince. After some time, the display state will get into the glitchy situation. So far, any configuration using the intel DDX for Xorg suffers from this, including a stockmind respin Ubuntu ISO live system. I cannot reproduce the glitch using the modeset driver. But what I do see with that one, is a region of massive tearing (not just the usual vertical bars for this rotated display, but triangular patterns … staircase structures, best visible with the 60 fps video). This tearing region is present even if a compositor manages to avoid the usual tearing. Various signs suggest that the intel DDX is being abandoned in favour of the generic modesetting DDX. Too bad that so far only the tearfree option of the intel driver provides a tear-less desktop. Everything else makes my eyes hurt. I was playing around with compton instead of the Xfce compositor and nothing so far tamed the horrible screen tearing. While the tearing nastiness depends on the screen rotation, the glitch triggering apparently does not. Anyhow, this is the testing I did to investigate the glitches (again: consider simply playing the color flipping video instead): - rebooting the system after each glitch - have xdotool installed - evince maximized (not presentation mode) with the chosen PDF open - left side with preview images (not structure) - triggering repeated page up/down via scrolltest script: while true do xdotool key --repeat 50 --repeat-delay 20 Page_Up sleep 1 xdotool key --repeat 50 --repeat-delay 20 Page_Down sleep 1 done In short: shell$ evince slides.pdf & # set up view, maximise shell$ time sh scrolltest # switch to evince window, wait for glitch # abort scrolltest, remember the time, perhaps # cutting some seconds for reaction time 'vars' refers to these in /etc/environment: COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer LIBGL_DRI3_DISABLE=1 Choosing of intel driver happens via /etc/X11/xorg.conf.d/20-intel.conf being present or not, with tearfree and dri settings inside. A more sensible and possibly quicker way to trigger is to simply loop the 60 fps flicker video: mplayer -loop 0 kenjo_vidtest_60fps.mp4 The issue here is that often, the glitch will be quickly triggered and subsequently corrected again by another trigger event. Tests ===== 1. modeset driver, vars unset 1800 s no glitch 2. intel driver, dri2, tearfree=false, cogl=frame, libgl_dri3_dis=1 seconds to glitch 190 200 60 27 590 3. intel driver, dri3, tearfree=true, vars unset seconds to glitch 170 #gave up after 480 ... more next time 900 460 235 110 4. intel driver, default dri (DRI2), tearfree=true, both vars This is the first with the slides.pdf you find with this file. seconds to glitch 7 205 75 95 25 Either this PDF is so much better for triggering or this config is indeed more vulnerable. I suspect the former, as there is more actual rendering taking place compared to the first PDF (slides too simple and jumped over). Next is two things: veryfying that modeset is immune and booting a stockmind ISO. Regarding modeset: It won't be immune as such, as the KMS part of the driver is actually confused. After a glitch, the boot logo/console has the same shift. It is not contained in the X11 session. 5. Testing stockmind image live system gpdpocket-20180306-4.16.0-rc3-ubuntu-17.10.1-unity-desktop-amd64.iso I am struggling to find glitch times for the stockmind image with Unity. Simple reason: I get the glitch right after opening the PDF in evince (from terminal window)! There isn't even time to start the command. I had this happening two times now. Trying a third time. I'll count this as 0 seconds to glitch. seconds to glitch 0 0 210 145 glitched briefly and then glitched back This seems really easy to trigger in Unity (or with the 4.16-rc3 kernel … or with DRI3 enabled for intel driver while it is disabled for libgl in /etc/environment). Testing the new PDF file again with the same setup in my Xubuntu install (only fresher kernel). 6. intel driver, tearfree and dri3 with the vars seconds to glitch 10 1 600 glitch there for a brief moment while moving cursor, glitched back 70 2280 went out of the room, came back and it was (still/again) glitched 95 55 7. Now then, the final one: modesetting driver. With the vars. Over 6310 seconds without a glitch. It really looks like it will be very hard to trigger this with the modesetting driver, if at all. The root cause should be in the KMS part … or how else would it still fit that X11 still has the normal picture in memory (screenshot looking fine) and things are distorted also on the console and boot splash after triggering? 8. current git of intel driver with tearfree, dri3, vars This is commit 6c1e70c, dated 2018-03-26. I checked out the git repo, autoreconf, ./configure --enable-dri3, replaced the intel_drv.so from ubuntu. seconds to glitch 95 I guess I don't need many trials to conclude that the issue did not change. Conclusion ========== My GPD Pocket is easily moved into a messed up display state via evince rendering PDF pages, regardless of configuration as long as the intel DDX for X11 is used. The same hardware works without glitches using the modesetting DDX. Is my device more susceptible than others? A this happens quickly for me and other folks are happily using the stockmind respins or Arch on their machines, I have to wonder. Both setups use the intel DDX with tearfree on. They should glitch like mad?! Maybe more people can reproduce the issue with my test. Maybe there are GPD Pockets that have different likeliness of hitting this. Bootnote: It's funny how the display stays in the shifted state even after re-starting X11 with the modesetting driver. As long as the screen mode is not changed, this state stays. Not really surprising, but it drives the point home that this is the underlying KMS that's carrying on once triggered. Bootnote 2 (warning): The usual fix for the glitch (xrandr to 1024x768 and back to 1200x1920) causes a black screen/freeze with the modesetting driver. Too bad.