Created attachment 143448 [details]
Dmesg on a boot demonstrating the issue
I've got an Acer Switch 10e SW3-016 tablet (Intel Atom x5-Z8300) and have been fighting in getting a working Linux environment on it for the last couple of months.
Most notably, booting any distro displays the kernel log until KMS loads Intel drivers, after which the screen briefly flashes white and stops displaying an image. I can ssh, successfully start and interact with X, change brightness levels (and since it's an LCD display I can see brightness changes), just that all I see is black pixels.
Kernel parameter i915.fastboot=1 temporarily fixes this issue - the display works, until the screen is shut off (to either sleep or manually "xset dpms force off"). After the screen wakes up, there is again no screen image (brightness and everything else works as normal).
I tried manually compiling and installing the recommended drm-tip, but the issue stays the same.
I've attached the full dmesg (with drm.debug=0x1e log_buf_len=1M kernel params), and an intel_reg dump.
I couldn't dump the VBIOS:
cat: /sys/devices/pci0000:00/0000:00:02.0/rom: Input/output error
-- system architecture: 64-bit
-- xf86-video-intel: N/A
-- xserver: N/A
-- mesa: N/A
-- libdrm: 2.4.97
-- kernel: 4.20.11-arch2-1-ARCH
-- Linux distribution: Arch
-- Machine or mobo model: Acer Switch SW3-016
-- Display connector: DSI
Created attachment 143449 [details]
Intel reg dump on a boot with the issue
> Kernel parameter i915.fastboot=1 temporarily fixes this issue - the display
> works, until the screen is shut off (to either sleep or manually "xset dpms
> force off"). After the screen wakes up, there is again no screen image
> (brightness and everything else works as normal).
Can you add dmesg log in this case (i915.fastboot=1)?
Created attachment 143455 [details]
dmesg with i915.fastboot=1 boot
Having i915.fastboot=1 successfully boots with a working display. Then, running systemd suspend shuts off the screen for half a second and then the system automatically wakes up again (with the screen displaying black). I've attached the dmesg during this process.
Created attachment 143456 [details]
dmesg with i915.fastboot=1 suspend
Here is the dmesg segment when running systemd suspend
Reporter, do you still have the issue?
@Maarten, any suggestions here?
Upgrading my Arch system to latest current state, including Kernel 5.1.6-arch1-1-ARCH and libdrm 2.4.98-1 yields interesting results.
Now, without needing any extra kernel flags, I am able to boot into a graphical interface, control the brightness, and gpu acceleration is working. However, if the screen is shut off (for example, via xset dpms force off), when the screen wakes up again, it no longer displays a picture (everything else with the system works, including brightness levels, just no picture). This is a problem regardless if X is running or not.
I am attaching a dmesg on a successful boot with a working graphical environment. And then a dmesg on what happens after I run "xset dpms force off" and wake the screen up (so that it stops displaying a picture). Both of these dmesg logs are from the same boot. I'm also attaching an intel reg dump after the screen stops displaying a picture. Hope that helps!
Created attachment 144445 [details]
Boot with new kernel into a working graphical environment
Created attachment 144446 [details]
Turning the screen off and on to reproduce the issue with the new kernel
Created attachment 144447 [details]
intel_reg dump while the screen no longer displays an image
(In reply to zvezdin from comment #8)
> Created attachment 144446 [details]
> Turning the screen off and on to reproduce the issue with the new kernel
In this case, can you attach the dmesg from boot.
(In reply to Lakshmi from comment #10)
> (In reply to zvezdin from comment #8)
> > Created attachment 144446 [details]
> > Turning the screen off and on to reproduce the issue with the new kernel
> In this case, can you attach the dmesg from boot.
Booting into a graphical environment (the first file I uploaded yesterday) and turning the screen off and on (the second file I uploaded yesterday) are the same dmesg, split on two parts - booting and issue recreation.
Jani, any thoughts on what might be going wrong here?
We simply fail to enable the DSI display. DSI being DSI, we don't get errors, so hard to say why without the hardware.
Obviously the UEFI GOP is able to enable the display, and with i915.fastboot=1 we just don't touch the hardware until the next modeset, which we then fail.
i915.fastboot=1 became the default for VLV and CHV in v5.1 so that explains the change in behaviour.
Please attach /sys/kernel/debug/dri/0/i915_vbt.
Please redo the register dumps. Boot v5.1 (assuming the default i915.fastboot=1) and take register dump #1. Then run 'xrandr --output DSI-1 --off --auto' (i.e. display off/on cycle, I hope I got the command line right from memory) and take register dump #2. Attach both.
Reporter, can you please give your feedback based on comment 13?