Surface Book shuts down after disconnecting screen

[13scoobie]

Using Ubuntu 18.04 with latest 4.17.3 surface linux kernel (updated today) on a Surface Book 1.

Repro: Press the screen disconnect button, lift screen off keyboard the shutdown pop up appears after No matter if you hit cancel, restart, or shutdown, surface book shuts down.

Expected: pressing cancel will cancel shutdown or menu would not pop up initially

I have also tried reconnecting the screen immediately, and using the mouse to click cancel, but surface still shuts down

[Bercio]

same environment here, except kubuntu 18.04. surface books shuts down on undocking. I'm dual booting with windows but I have made sure to shut it down before trying again, and the issue persists. no shutdown dialog for me though, just directly reboots. should I make a new issue?

[13scoobie]

could be related, although ive received the dialog every time.

[jakeday]

I can't reproduce this, and I used it all the time on my Surface Book 1 and 2. Can you get me a log dump?

[13scoobie]

@jakeday - what would be your recommendation for how to dump logs for the event?

I'll review your other comments for which logs you need in parallel.

[ryanmcdonnell]

I'm experiencing a very similar issue.

Surface Book 1 Ubuntu 18.04.1 (not dual-boot) linux-surface 4.17.3 kernel Secure Boot enabled, encrypted disk

Immediately after I undock, I hear the "device disconnected" sound from Ubuntu, and the screen instantly goes black -- the Surface is completely off. When I press the power button, the BIOS (Surface logo) is shown and the system boots normally.

Happy to supply any more information.

[jakeday]

Try this with my latest 4.18.7 kernel.

[ryanmcdonnell]

I can confirm this issue was solved for me by updating to 4.18.7. Thanks, Jake!

[jakeday]

Good deal!

[phormix]

I'm having the same issue.

• Device: Surface Book 1
• Kernel: 4.18.11-surface-linux-surface
• Distribution: Mint 19

After unplugging and re-plugging a few times, I think I've tied it down to this.

Undocking/re-docking the tablet from the keyboard fires off a bunch of uDev events under systemd-udevd. I managed to find the following in the logs (journalctl -xe):

Oct 09 10:31:00 surfacebook kernel: usb 1-1: USB disconnect, device number 7 Oct 09 10:31:00 surfacebook kernel: usb 1-1.4: USB disconnect, device number 8 Oct 09 10:31:00 surfacebook acpid[870]: input device has been disconnected, fd 6 Oct 09 10:31:00 surfacebook systemd-logind[857]: Power key pressed. Oct 09 10:31:01 surfacebook kernel: usb 2-1: USB disconnect, device number 4 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 Oct 09 10:31:01 surfacebook acpid[870]: input device has been disconnected, fd 16 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb2/2-1 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:045E:07CD.0005 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4 Oct 09 10:31:01 surfacebook upowerd[1051]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1 Oct 09 10:31:13 surfacebook kernel: usb 1-1: new high-speed USB device number 9 using xhci_hcd Oct 09 10:31:13 surfacebook upowerd[1051]: treating change event as add on /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:01/power_supply/BAT2 Oct 09 10:31:13 surfacebook upowerd[1051]: energy_full (52.710000) is greater than energy_full_design (51.000000)

The behavior in this case varies depending on the actions you've mapped to the power button event and/or your desktop environment. If you've got a power-button keypress mapped to shutdown it will initiate either a shutdown even or at least popup the dialog to do so. Oddly, in KDE the dialog pops up (with a countdown) on detach, and in Cinnamon it tends to fire off when I reattach the Book to the keyboard.

A workaround might be to set your power button even handler to "lock" rather than power off, however that may give you issues with the current lock screen not having onscreen-keyboard integration. In theory that might be worked around by choosing to login with a new session - which takes you to the DM login screen which can have the "onboard" keyboard - and then logging into the same account again (which will actually return you to your current session, at least in my lightdm+kde combination).

It'll rob you of the ability to power down via the power button, but it's better than the device trying to shut off whenever it's removed from the keyboard.

[phormix]

Update. On the device I'm working with (admittedly not mine, I've been seeing if I can help make my buddy's book play nice with 'nix) I notice that the actual power button doesn't seem to register at all. I wonder if something is confusing the "power button" and "detach" event somehow.

[phormix]

A bit more research on this turned up some useful info. If you are seeing a shutdown, there are several events that could be triggering it. You can disable the trigger by removing the "power button" actions on whichever of the below apply:

a) Your desktop manager, kde, gnome, whatever (usually configurable via the "power button" settings in power management). Set the "power button" action to do nothing b) ACPI: If you have something responding to the power button event from acpi/acpid. c) SystemD-loginD: Set HandlePowerKey=ignore in /etc/systemd/logind.conf

But that just deals with the symptom. The cause appears to be that it's misidentifying the dock/undock event as a power button event. In my case, this handler showed up as /dev/input/event25 gpio-keys event. I will attach, but the gist is:

$ evtest /dev/input/event25 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "gpio-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 116 (KEY_POWER) Properties: Testing ... (interrupt to exit) Event: time 1539291231.895250, type 1 (EV_KEY), code 116 (KEY_POWER), value 1 Event: time 1539291231.895250, -------------- SYN_REPORT ------------ Event: time 1539291237.863242, type 1 (EV_KEY), code 116 (KEY_POWER), value 0 Event: time 1539291237.863242, -------------- SYN_REPORT ------------

Per the above, it sees that handler as "power key" gpio handler, and fires off an event both when the tablet is undocked (KEY_POWER =1) and docked (KEY_POWER=0) event.log

[phormix]

Looks like the gpio_keys module is at fault in this case. A mid-term fix that gets rid of the nasty event (and means you don't need to mess with your power-button settings) would be to disable that module rmmod gpio_keys And blacklist it across reboots echo "blacklist gpio_keys" >> /etc/modprobe.d/blacklist-gpio_keys.conf

Long-term fix would likely be to update the driver so that it correctly identifies this event as a dock/undock rather than a power button. I'll try to track down the owner (not sure if this is one modified by Jake or not yet)

[itsyoshio]

@phormix this also fixes it for me on 4.18.16 Thanks.

[qzed]

Can you check if unloading soc_button_array (instead of gpio_keys) also fixes this? If that's the case can you also provide me with a DSDT?

[phormix]

The surfacebook is with my wife right now but I'll try to borrow it back and take a poke at it.

On Thu, Nov 22, 2018 at 2:31 PM Maximilian Luz notifications@github.com wrote:

Can you check if unloading soc_button_array (instead of gpio_keys) also fixes this? If that's the case can you also provide me with a DSDT?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jakeday/linux-surface/issues/224#issuecomment-441129003, or mute the thread https://github.com/notifications/unsubscribe-auth/AbHJ1zCu0OHFz63LMWPpus_VTm5bXI1sks5uxyXcgaJpZM4VEzNY .

-- "You can't herd cats, but you can move their food"

[qzed]

Can anyone provide me a DSDT/acpidump of the SB1 so I can have a look at this?

Edit: You can get that via sudo acpidump > acpidata.dat.

[qzed]

Same root cause as #243, will be continued there.