ts_calibrate screen freezes on kernels >5.6/8 and intel graphic hardware

[pfink-christ]

Hi @merge we discovered that ts_calibrate is not working reliably on newer kernels on some devices.

Specifically this means that the calibration cross hangs in the left top corner while the calibration beneath is working as expected.
Initially we saw the problem with a debian kernel/image update from 4.19 to 5.10.

After ruling out other factors and a long (or actually two) kernel bisect rounds i narrowed the problem down to two commits where the behavior changes:

After commit 64914da24ea9 it was not possible to start ts_calibrate on a fresh ubuntu with mainline kernel multiple times. With this change ts_calibrate sometimes vanishes into the background or you could only start it one, twice, four times...but after enough starts you would finally end up with it starting, but still seeing the ubuntu desktop and only seeing it briefly after 5 touches.
I tested a possible solution to counter what I understood from the change and some other sources. It seems to improve the start behavior....but one single time out of a lot of tries I was able to get the old behavior with the next try being ok again. So maybe there was some other issue or it doesn't really solve the problem. I don't know. Here is the possible solution that I came up with...has to to with how the drm master acquires access (or something like that) and because it's not forced unconditionally anymore you have to switch to KD_TEXT first before KD_GRAPHICS. I tried to find my source where I read this, but could not find it anymore...thinking about it makes me wonder if I really understood it correctly. Nevertheless it improves the behavior for me:

--- a/tests/fbutils-linux.c
+++ b/tests/fbutils-linux.c
@@ -112,6 +112,10 @@ int open_framebuffer(void)
                }
 #endif

+               /* set to console mode first because of kernel change */
+               if (ioctl(con_fd, KDSETMODE, KD_TEXT) < 0)
+                       perror("KDSETMODE");
+
                if (ioctl(con_fd, KDSETMODE, KD_GRAPHICS) < 0) {
                        perror("KDSETMODE");
                        close(con_fd);

This fixes ts_calibrate until 691f7ba58d52 where FBC is activated. This might be only relevant for some hardware, as I'm on intel i3-7100U and celeron N3350.

Here currently my workaround is just deactivating framebuffer compression:

echo 0 > /sys/kernel/debug/dri/0/i915_params/enable_fbc or adding i915.enable_fbc=0 to the kernel cmdline.

This also makes the first workaround abundant. I just added it for full disclosure.

If more people encounter this problem I would suggest integrating other countermeasures directly into fbutils-linux.c where we force fbc to invalidate and recompress the buffer. Maybe the idea from the comment to call intel_fbc_invalidate/flush() would be the way to go, but currently I didn't research this any further. Just wanted to publish my workaround for other people having such problems.

@merge if you have specific ideas how and if you want to tackle this issue I'm willing to create a proposal and a PR. But currently I'm a bit out of my waters as far as framebuffer and drm are concerned.

Regards,
Peter

[AndreiLacatos]

I had the exact same issue on kernel 6.8. Huge thanks to @pfink-christ for the detailed explanation and the workarounds! Adding the i915.enable_fbc=0 kernel parameter solved it for me, life saver 🛟