What would *you* do? No power button on SP3.

altercation · 2014-09-04 00:35:09

Help! POWER Button not detected

Why? How would you try to fix this?
My fallback is wakeup from suspend with fn/super keypress on usb keyboard.
This works... but if I unplug/plug keyboard back in it (keyboard) while suspended it doesn't work any longer. Using this fallback, any ideas on how I could ensure the keyboard wakes up the system?

---

I've installed Arch on a Surface Pro 3 and overall experience is good. There are a couple outstanding issues among which is the lack of hardware buttons. I've posted this here as I believe it is more appropriate for hardware/kernel given my suspicion that it's acpi related. Let me know if this was the right/wrong section.

The Surface Pro 3 has three hardware buttons (power, vol-up, vol-down) and one capacitive button (the windows home button). None of them generate any button events, key presses, or dmesg output. All buttons work when dual booting into Windows.

Why

I would like to get the power button working so that I can resume from suspend (wakeup functionality). Right now I can only wakeup with a keyboard key press (fn seems to work on most of the keyboards I've tested). However unplugging the keyboard and then plugging it back in while the system is suspended breaks this. I assume it's because hotplugging the usb keyboard gives it a different device identifier that hasn't received wakeup capability, but I'm not sure.

Steps taken during button testing:

(some of the relevant output data is listed in the Gists section below)

* reviewed arch wiki again to confirm testing methods
* dmesg output monitored
* journalctl output monitored
* xev output monitored
* xinput dumped, reviewed
* acpid started, acpi_listen monitored
* /proc/acpi/wakeup examined, all items set to enabled and buttons tested for wakeup capability
* switched to console, monitored showkey

Essentially, I've done the basic triage on this and there are no events generated from button presses. **Anything I've missed?**

ACPI

Taking a look at /proc/acpi/wakeup, I find no power buttons listed.

Device	S-state	  Status   Sysfs node
WIFI	  S4	*disabled  pci:0000:01:00.0
LID0	  S3	*enabled   platform:PNP0C0D:00
EC0	  S3	*disabled  platform:PNP0C09:00
XHC	  S4	*enabled   pci:0000:00:14.0
HDEF	  S4	*disabled  pci:0000:00:1b.0
TPD4	  S4	*disabled
TPD7	  S0	*disabled
TPD8	  S0	*disabled
PEG0	  S4	*disabled
PEGP	  S4	*disabled
PEG1	  S4	*disabled
PEG2	  S4	*disabled

There is a curious "lid switch" but I monitored its state while actuating the buttons as well and it showed no state change. I suspect it is a sensor that detects the Surface keyboards when closed (I don't have one to hand, as I use a usb keyboard), so unless I can actuate it like a button (e.g. magnetically, which I tried but was unsuccessful doing) then this is a non-starter as well.

/proc/acpi
├── button
│   └── lid
│       └── LID0
│           └── state
└── wakeup

Next steps

First, posting here I'm hoping that someone might have a suggestion for other areas of the system to look into or test.

However, if there are no other suggestions, I will explore why there doesn't seem to be a power button device by looking into ACPI DSDT editing.

Gists

I've dumped relevant system data to the following gists:

* dmesg (filtered for acpi)
* dmesg (all)
* journalctl (filtered for ACPI entries)
* journalctl (all)
* xinput output
* /proc/acpi/wakeup dump
* ACPI DSDT decompiled

Install Notes

Rough notes of my installation of Arch on the Surface Pro 3 are available here.

Last edited by altercation (2014-09-04 22:39:01)

altercation · 2014-09-04 22:40:57

bump. I'm open to ANY suggestions, folks. I've added two questions at top of post (how would you get this power button detected, given fallback, how can I make sure a hotplugged usb keyboard wakes up the system even if keyboard is plugged in while suspended?).

I really appreciate any ideas. I've done a lot of diagnosing on Arch systems over the years and I've done a lot of legwork on this already and have really come up dry. Thanks.

lucke · 2014-09-04 23:50:26

For the wakeup to work both the device (e.g. 1-1) and the hub (e.g. usb1) it is using must have "wakeup" set to "enabled" in /sys/bus/usb/devices/*/power/. See e.g. if they turn to "disabled" when you unplug and plug back the keyboard while Surface is on, if you are able to resume it then maybe you can see what changes when you unplug the keyboard while Surface is off.

altercation · 2014-09-05 04:02:53

lucke wrote:

For the wakeup to work both the device (e.g. 1-1) and the hub (e.g. usb1) it is using must have "wakeup" set to "enabled" in /sys/bus/usb/devices/*/power/. See e.g. if they turn to "disabled" when you unplug and plug back the keyboard while Surface is on, if you are able to resume it then maybe you can see what changes when you unplug the keyboard while Surface is off.

Thanks very much for the reply and idea. Interestingly, there is no change when hotplugging while the system is on (i.e. if I run a script to set all /sys/device/**/wakeup to enabled and confirm that they have been, and dump /proc/acpi/wakeup confirming that all possible entries are enabled, hot unplugging/plugging the keyboard makes no difference to what is enabled.

I tested with my HHKB which has a built in USB hub. In that case the built in hub resets to disabled status.

I'm wondering whether I should have udev assign a persistent device name to a keyboard and test to see if that persistence addresses this issue (not the power button issue, obviously, but at least the ability to hotunplug and plug the keyboard in during suspend).

Again, thanks. I'm really looking for any and all suggestions and brainstorming at this point.

Pse · 2014-09-05 04:10:22

Are there any firmware/UEFI updates available for your hardware? What happens if you tell it you are on Linux by setting acpi_osi=Linux through the kernel command line?

Edit: perhaps acpi_osi="!Windows 2012" could be useful too.

Last edited by Pse (2014-09-05 04:12:26)

altercation · 2014-09-05 05:41:19

Pse - I've been keeping the firmware up to date via dual booting into windows regularly. I played around with a *bunch* of the acpi_osi settings including acpi_osi=Linux (though I understood that to be verboten now). I tried acpi_osi="Windows 2013" (the win 8.1 string) but not sure I stuck the bang in there. I'll give it another try.

Thanks for the suggestions!

-es

altercation · 2014-09-05 07:25:42

Ok, to be thorough, I tried the following acpi_* variants on the kernel command line:
(double quotes are due to formatting required by rEFInd)

acpi_os_name=""Windows 2013"" acpi_osi=""Windows 2013""
acpi_os_name=""Windows 2013"" acpi_osi=!* acpi_osi=! acpi_osi=""Windows 2013""
acpi_os_name=Linux acpi_osi=Linux
acpi_osi=""!Windows 2013"" acpi_osi=""!Windows 2012""
acpi_osi=
acpi_os_name=Linux acpi_osi= 
acpi_os_name=""Windows 2012"" acpi_osi=""Windows 2012""

staring and running acpid upon boot and monitoring acpi events with acpi_listen returned no button press events, and dmesg -t showed no PWRB or power button in any of these cases.

Question: is this something I should submit to the kernel.org bugtracker?

https://bugzilla.kernel.org/describecom … oduct=ACPI

----

My fall back plan is shaping up: I can successfully use the only usb port to wake the device:

sleep 5;
# (during which I removed the plugged in keyboard)
sudo systemctl suspend

Plugging the keyboard back in wakes the device (not because it's the keyboard specifically, just any device being plugged in). This is due to a brute force setting of "enabled" on ALL wakeup files in /sys. I'm going to now identify the hub device and just assign that wakeup via a udev rule.

(edit: figured it out) I'm going to make a udev rule triggered on removal of the immediate child of the internal usb hub that suspends the device. This way the plug will act as a poor-man's power button. Added benefit is that I use only a usb keyboard anyhow and don't currently use the SP3 as a tablet, so this fits my use case for the time being.

Last edited by altercation (2014-09-05 16:56:30)

altercation · 2014-09-05 10:30:10

Ok, I've got my usb-port-as-power-switch working. Here's my helper script (in my $HOME/bin, installs the udev rule when called with the 'install' option).

I still would like to get the power button working, but this is a decent solution for now.

#!/usr/bin/env zsh

# plug/unplug usb to internal usb hub will suspend/resume machine

setopt EXTENDED_GLOB NO_UNSET ERR_EXIT

# udevadm info -a -p /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1
# udevadm test --action remove /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1
# sudo udevadm monitor --environment --udev 

# ---------------------------------------------------------------------
# script values
# ---------------------------------------------------------------------

typeset -g SCRIPTNAME="${${SCRIPTPATH:=$(readlink -f $0)}:t}"
typeset -g SCRIPTROOT="${SCRIPTPATH:h}"
typeset -g SCRIPTCONF="$HOME/${XDG_CONFIG_HOME:-.config}/$SCRIPTNAME"
[[ -d $SCRIPTCONF ]] || mkdir $SCRIPTCONF &>/dev/null

# ---------------------------------------------------------------------
# initializers
# ---------------------------------------------------------------------

envinit () {
    ${(P)${(U)0}:-false} && return 0 || eval typeset -g ${(U)0}=true # run once only per script execution
    typeset -gx DISPLAY="$(print /tmp/.X11-unix/*(:t:s/X/:))"
    [[ $(loginctl list-sessions) =~ "seat0" ]] || { print "No X Session identified"; exit 1 }
    export XAUTHORITY=/home/${${(s:/:)SCRIPTPATH}[2]}/.Xauthority
}

install () {
    [[ $USER == root ]] || { print "run with sudo or as root when calling $SCRIPTNAME $0"; exit 1 }

    # works but also too broad, but we'll use the test function below to determine if we sleep
    rulepath=/etc/udev/rules.d/99-usb-removal.rules
    rule='ACTION=="remove", ENV{ID_USB_INTERFACE_NUM}=="01", RUN+="'$SCRIPTPATH' conditionalSuspend $parent"'
    [[ -f $rulepath ]] && rm -f $rulepath
    print $rule > $rulepath || { print "Failed to initialize udev rule '$rulepath'"; exit 1 }
    print "Successfully initialized udev rules $rulepath"
}

conditionalSuspend () {
    # there are four builtin usb hub devices, so thats the count if we've unplugged everything
    if (( ${#${(f)"$(lsusb -s 001:)"}} == 4 )) && [[ -z ${*:-} ]]
    then
        envinit
        # make sure that usb hub is set to resume and then suspend
        if [[ "$(</sys/devices/pci0000:00/0000:00:14.0/usb1/power/wakeup)" != enabled ]]
        then
            notify-send "Setting usb hub to wakeup mode, then suspending."
            print "enabled" > /sys/devices/pci0000:00/0000:00:14.0/usb1/power/wakeup || {
                notify-send "Failed!"; exit }
            sleep 2 # to see the notification
        fi
        systemctl suspend
    fi
}

$*

R00KIE · 2014-09-05 12:11:45

The power button must be detected somewhere, have you checked with xev is any event is returned when you press the power button?

Just a guess but it might be that the power button is tied to some hardware interrupt pin, check if anything in /proc/interrupts seems to be correlated with the power button presses.

altercation · 2014-09-05 16:54:56

R00KIE wrote:

The power button must be detected somewhere, have you checked with xev is any event is returned when you press the power button?
Just a guess but it might be that the power button is tied to some hardware interrupt pin, check if anything in /proc/interrupts seems to be correlated with the power button presses.

Yep. I list all the steps in the "Steps taken during button testing" section in the top post. xev, showkey, acpi_listen. Nothing.

Good idea on the /proc/interrupts. Checking /proc/interrupts (watch -n0.5 cat /proc/interrupts) shows interrupts received on IRQ 9 (IR-IO-APIC-fasteoi).

I'll read up on this, but if you have a suggestion on where to take this next, I'm all ears.

Last edited by altercation (2014-09-05 16:55:19)

R00KIE · 2014-09-06 09:46:38

No real suggestions here, I was curious to see how to set one interrupt to wake up the machine from sleep and I found almost nothing. The closest I could get was this [1].

From what I've seen, I'm not sure if you have to write a simple program to enable a certain interrupt to wake the machine or if you have to write a simple driver to register with a certain interrupt to wake the machine. I guess the best place to ask will be in some kernel mailing list.

[1] https://www.kernel.org/doc/htmldocs/gen … r_API.html

altercation · 2014-09-06 22:04:56

I appreciate the brainstorming @R00KIE ... I hadn't considered interrupts at all before. I'm thinking I should submit this to the kernel.org acpi bugzilla.

R00KIE · 2014-09-07 09:47:14

In your case this might be a bug or not, but you don't lose anything to ask in a kernel mailing list.

What you want to do is something along the lines of wake on lan or wake on RTC, in both cases the bios/firmware needs to be configured to wake the machine when receiving interrupt signals from either the lan chip or rtc. Of course the lan chip and the rtc also need to be configured appropriately.

From what I could quickly find [1] the firmware on the SP3 does not allow you to configure much so you are out of luck trying to configure wake up sources there.

[1] http://winsupersite.com/mobile-devices/ … s-firmware

altercation · 2014-09-14 04:22:28

According to reports on http://reddit.com/r/surfacelinux the power button functions under Ubuntu.

I've also noted that power consumption during system suspend is high, leading me to suspect a clock/acpi related issue.

Will continue to explore this.

altercation · 2014-09-22 15:54:27

Update: I submitted an issue to the kernel bugtracker and it's now actively being looked at.

https://bugzilla.kernel.org/show_bug.cgi?id=84651

Last edited by altercation (2014-09-22 15:54:39)

noctlos · 2014-11-10 14:17:30

Ethan,

Has there been any progress on this bug? From the kernel bug tracker, it seems that none of the patches have brought forth fruits.

altercation · 2014-11-10 23:54:25

noctlos - there hasn't been. I've considered a) digging into it myself b) sending the developer an SP3 to test on. I doubt that I have the skills to really solve anything on this myself, but that's never stopped me from failing before!

I think it would be great to see some other SP3 users comment on that thread if they are seeing the same problem. Are you using or just monitoring for progress?

noctlos · 2014-11-14 16:22:02

I'm using it. Perhaps I will dig into this bug a little if I can find the spare time.

colorprint · 2014-11-23 09:08:18

R00KIE wrote:

The power button must be detected somewhere, have you checked with xev is any event is returned when you press the power button?
Just a guess but it might be that the power button is tied to some hardware interrupt pin, check if anything in /proc/interrupts seems to be correlated with the power button presses.

BTW, the volume buttons not work too and not detected with xev too

Arch Linux

#1 2014-09-04 00:35:09