Created attachment 150471 [details]
output of: cat /proc/acpi/wakeup

Created attachment 150481 [details]
output of: grep . /sys/bus/acpi/devices/*/hid

Created attachment 150491 [details]
output of ls /sys/bus/acpi/drivers/*/

Created attachment 150501 [details]
output of: grep . /sys/firmware/acpi/interrupts - pre power button press

Created attachment 150511 [details]
output of: grep . /sys/firmware/acpi/interrupts - post power button press

Created attachment 150521 [details]
full dmesg output

This may be unnecessary, but I'm attaching the disassembled DSDT as well.

Created attachment 150541 [details]
decompiled DSDT

I've also test booted with the following acpi related strings on the kernel command line (double quotes as this was done in 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""

None of these made any apparent difference, but I am happy to continue to test these and or other variations.

I've been working on a Surface Pro 3 with the type cover, and I've run across this bug.

Firstly, I can confirm that the LID0 button exposed in /proc/acpi/button/lid/LID0 is actually a lid-close sensor for the type cover.  I believe that the behavior documented in bug#79381 is still the case in the Surface Pro 3 hardware.

I also enabled ACPI debug and looked at the ACPI events listed when I pushed the power button.  It looks like Microsoft is using a non-standard interface to deal with all of the hardware buttons on the Surface Pro 3, so the button is not detected.  I've attached a patch that seems to make the button be detected as a power button; when the button is pressed, the system seems to suspend.  However, the system doesn't seem to resume when the button is pressed again; I'm not sure why yet, but I'll continue looking into it.

Created attachment 150971 [details]
Patch that seems to allow the power button to be detected by ACPI

I'm not sure if this is the right way to do this, and resuming doesn't seem to work yet, but it shows that the power button can be detected.  When the power button is first pressed down, a notify event from hardware with an HID of "MSHW0028" and value 0xC6 is sent, and on release a similar event with value 0xC7 is sent.  This just sends a power button press event on the 0xC7.

(In reply to Peter Amidon from comment #10)
> I've been working on a Surface Pro 3 with the type cover, and I've run
> across this bug.

Peter, thanks for replying on this. I was really running out of ideas on how to proceed.

> Firstly, I can confirm that the LID0 button exposed in
> /proc/acpi/button/lid/LID0 is actually a lid-close sensor for the type
> cover.  I believe that the behavior documented in bug#79381 is still the
> case in the Surface Pro 3 hardware.

Does the system resume on lid open using acpi or systemd? Also, I thought it might be a hall effect sensor and looked into triggering it magnetically but had no luck and could find no good data on this via teardowns, etc. Any insight? I'd use that in a pinch if I can get it working.

> I also enabled ACPI debug and looked at the ACPI events listed when I pushed
> the power button.  It looks like Microsoft is using a non-standard interface
> to deal with all of the hardware buttons on the Surface Pro 3, so the button
> is not detected.  I've attached a patch that seems to make the button be
> detected as a power button; when the button is pressed, the system seems to
> suspend.  However, the system doesn't seem to resume when the button is
> pressed again; I'm not sure why yet, but I'll continue looking into it.

Outstanding! This is great news.

Peter, I assume you've already looked into this since you are clearly beyond my level of acpi hacking, but did you set /proc/acpi/wakeups to enable wakeups for the hacked in power button? I don't know if that proc interface is still functional other than reading out state, or if it also needs to be done in sysfs.

(In reply to Ethan Schoonover from comment #13)
> Peter, I assume you've already looked into this since you are clearly beyond
> my level of acpi hacking, but did you set /proc/acpi/wakeups to enable
> wakeups for the hacked in power button? I don't know if that proc interface
> is still functional other than reading out state, or if it also needs to be
> done in sysfs.

That's a good idea; I hadn't actually though of that when I was trying this.  Looking at it now, the button doesn't seem to be showing up in /proc/acpi/wakeup (my output of cat /proc/acpi/wakeup is the same as yours), and I'm not sure why.

I just tried suspending the system with the power button and closing and then opening the lid; it didn't seem to unsuspend properly.

Based on your debugging, I believe these are the relevant Q methods from the DSDT. Don't know if they shed any light on this. I'm still reading up on acpi debugging.

    5022 Method (_Q60, 0, NotSerialized)  // _Qxx: EC Query
         {
             Notify (VGBI, 0xC6) // Hardware-Specific
             Store (0x60, DBG8) /* \DBG8 */
         }

         Method (_Q61, 0, NotSerialized)  // _Qxx: EC Query
         {
             Notify (VGBI, 0xC7) // Hardware-Specific
             Store (0x61, DBG8) /* \DBG8 */
         }

I've been looking into how to enable wakeups for the device, and I've come to the conclusion that this is more complicated than it looked.  It looks like the VGBI device handles a bunch of the buttons on the tablet.  These buttons currently send these signals:

  - Volume up: 0xc0 on press, 0xc1 on release
  - Volume down: 0xc2 on press, 0xc3 on release
  - Windows button (on chasis): 0xc4 on press, 0xc5 on release
  - Power button: 0xc6 on press, 0xc7 on release

It looks like only devices with _PRW or _PSW methods can be used to wake the device; the kernel lists devices with _PRW in /proc/acpi/wakeup.  Unfortunately, the VGBI device doesn't seem to have _PRW; looking at the decompiled DSDT, nothing has _PSW.

I tried to enable all of the devices that could cause wakeups in /proc/acpi/wakeup; interestingly, only WIFI, EC0, and HDEF could be enabled --- the other devices all stayed in the disabled state, even when I tried to enable them from userspace.  Even with all of these devices enabled, it didn't seem possible to wake up the tablet, even though there must be a way becuase it works for Windows.

FWIW, this is the script I'm using to turn my usb port into a power switch. I use an external USB keyboard, so I've set it up so that upon removal of all usb devices, the sp3 sleeps, and plugging one in wakes it up. (Peter, I'm sure you have your own solutions, but I thought it worth including this in this thread in case anyone else stumbles upon this thread).

https://gist.github.com/altercation/bd9d4b4bb7149b4825b2

I may try some DSDT changes later this weekend.

I've found some Microsoft documentation about button devices for Windows 8 Tablet and Convertible devices; it looks like they used the hardware-reduced profile from ACPI 5.0.  I think that the right way to implement these devices would be to implement a new driver module just for dealing with these buttons.

Here's a link to a page inthe Windows ACPI design guide for SoC platforms, which contains, among other things, a section on button arrays: 

http://msdn.microsoft.com/en-us/library/windows/hardware/dn495671%28v=vs.85%29.aspx#button

The previous page links to this one, but I think that it looks useful, so I'll post it here as well; it's a white paper on hardware buttons for Win8 tablet/convertible devices:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn613928%28v=vs.85%29.aspx

I haven't gotten a chance to look at these too thoroughly yet, but I'll take another look at them tomorrow.  From my quick look, it looks like the hardware buttons are all connected to separate interrupts on the main chip, so the kernel would need to figure out how te set those interrupt lines to be wake-enabled.

Wow, that's a great find, Peter. I don't know enough to comment on the module strategy, but it sounds like you have a good direction there. Let me know if there is some way I can contribute or test. One other curiosity is that there are reports of the power button working under Ubuntu, at least with a custom kernel. I really don't know what to make of them however as I've been unable to reproduce when booting into Ubuntu live medium to test.

Can you point me to where you saw something about it working in Ubuntu? I've taken a look at http://ubuntuforums.org/showthread.php?t=2231207 and http://www.reddit.com/r/Ubuntu/comments/26lvqc/ubuntu_on_the_surface_pro_3/, and I didn't see anything about that...

Also, I should mention that I've been working on Arch Linux with a mainline 3.17-rc5 kernel; however, I don't think that the ACPI stuff has made much of a difference between 3.16 and 3.17.

I'm on Arch 3.16.3 here. None of the 3.16 releases have made any difference here.

The report on Ubuntu power button working came from a query I made on the SurfaceLinux subreddit: http://www.reddit.com/r/SurfaceLinux/comments/2fnanu/ubuntu_1404_gnome_surface_pro_3_report/

However I really have failed to extract any details from the ubuntu crowd other than "it works". So I still wonder how accurate that reporting is (does it work to shutdown and resume? just shutdown? no details were ever forthcoming... that was just one of many queries I made in researching this).

However, here's an interesting commit that makes me wonder if Ubuntu may in fact be working simple due to compile options, related to that documentation you found: https://lkml.org/lkml/2014/3/27/252

I'm wondering if that commit relates specifically to our issue.

Looks like someone also gave a drive a first pass? https://github.com/jfwells/linux-asus-t100ta/blob/master/gpio_buttons_array_driver/gpio_button_array.c

Judging from the patches here:
http://comments.gmane.org/gmane.linux.kernel.input/35116
and then a day later here:
http://comments.gmane.org/gmane.linux.kernel.input/35131

The driver we are looking for is soc_button_array

Not on 3.16 Arch at least. I'll investigate more later.

cf: https://lkml.org/lkml/2014/7/2/291
"fix the issue that button device can't be enumerated since 3.16-rc1"

Ok, final comment for the night: it looks like the soc_button_array and other related drivers are indeed in the current linux git tree. I may build linux-git out of the Arch AUR to test.

The soc_button_array driver seems to have made it into 3.17-rc5, but the patch from https://lkml.org/lkml/2014/7/2/291 to make it enumerate properly hasn't.  I've tried building kernels both with and without the patch, and neither of them seems to detect the buttons properly.  I'll try to look into it some more on my end, but it would be great to see if you have the same behavior.  It looks to me like there haven't been any changes to the driver in https://github.com/torvalds/linux to that driver that aren't in 3.17-rc5, so I think that continuing to use that for now should work.

I'm not sure why the driver isn't working after the patch to "fix the issue that button device can't be enumerated since 3.16-rc1"; after applying that patch, I tried adding a debugging printk to soc_button_probe, but it looks like it's never getting called.

(In reply to Peter Amidon from comment #26)
> The soc_button_array driver seems to have made it into 3.17-rc5, but the
> patch from https://lkml.org/lkml/2014/7/2/291 to make it enumerate properly
> hasn't.  I've tried building kernels both with and without the patch, and
> neither of them seems to detect the buttons properly.  I'll try to look into
> it some more on my end, but it would be great to see if you have the same
> behavior.  It looks to me like there haven't been any changes to the driver
> in https://github.com/torvalds/linux to that driver that aren't in 3.17-rc5,
> so I think that continuing to use that for now should work.
> 
> I'm not sure why the driver isn't working after the patch to "fix the issue
> that button device can't be enumerated since 3.16-rc1"; after applying that
> patch, I tried adding a debugging printk to soc_button_probe, but it looks
> like it's never getting called.

well, https://lkml.org/lkml/2014/7/2/291 is not the final patch we used for upstream.
For 3.16, we use the patch at https://patchwork.kernel.org/patch/4511161/ as an urgent fix.
And this is the proper fix for 3.17,https://patchwork.kernel.org/patch/4646051/.

So please first check if https://patchwork.kernel.org/patch/4511161/ is applied in your kernel or not, if yes, please apply this one https://patchwork.kernel.org/patch/4646051/ on top and see if the button works or not.

Rui, I just built and am running 3.17 off of the git repo, patched with the 3.17 fix you linked above on my Surface Pro 3. The power buttons aren't showing up anywhere (i.e. none of the tests I listed initially... nothing new in /proc/acpi/wakeup, /proc/acpi/button, etc. I'm happy to debug more specifically if you can let me know what would be of use.

Thanks,
Ethan

please attach the output of "ls /sys/bus/platform/devices/" and " ls /sys/bus/platform/drivers/*/".
BTW, is there any error if you modprobe the soc-button-array driver manually?

Rui/Peter,

I realized that soc_button_array wasn't properly configured. I'd added the specific config for it, but it depends on KEYBOARD_GPIO as well.

So I'm recompiling now with:

CONFIG_KEYBOARD_GPIO=y
CONFIG_SOC_BUTTON_ARRAY=y

and will let you know how that goes after it's complete and I've tested. If no success, I'll upload the files requested.

Rui, I've just finished two tests. I first compiled the module into the kernel and there was no success. I then did a rebuild just to be thorough with the config lines set to =m and manually loaded the soc_button_array module. modprobe returns success when loading it, it shows up as loaded in lsmod.

Note that I built 3.17 from Linus' git repo and applied the following patch: https://patchwork.kernel.org/patch/4646051/

modinfo shows:

    # modinfo soc_button_array
    filename:       /lib/modules/3.17.0-rc6-g955837d/kernel/drivers/input/misc/soc_button_array.ko.gz
    license:        GPL
    alias:          acpi*:PNP0C40:*
    depends:        
    intree:         Y

ls output for /sys/bus/platform/devices/

    ACPI0003:00
    alarmtimer
    clk-lpt
    coretemp.0
    dock.0
    efi-framebuffer.0
    HID-SENSOR-200041.3.auto
    HID-SENSOR-200073.0.auto
    HID-SENSOR-200076.1.auto
    HID-SENSOR-200083.2.auto
    HID-SENSOR-200086.5.auto
    HID-SENSOR-20008a.4.auto
    INT0800:00
    INT33A1:00
    INT33C2:00
    INT33C3:00
    INT33C7:00
    INTL9C60:00
    iTCO_wdt
    microcode
    MSFT0101:00
    MSHW0005:00
    MSHW0006:00
    MSHW0009:00
    MSHW0027:00
    MSHW0029:00
    MSHW0036:00
    pcspkr
    PNP0103:00
    PNP0C09:00
    PNP0C0A:00
    PNP0C0D:00
    regulatory.0
    serial8250

I will attach the output of ls /sys/bus/platform/drivers/*/ after this.

Created attachment 151561 [details]
output of 'ls /sys/bus/platform/drivers/*/

please attach the output of "cat /sys/bus/platform/devices/MSHW0029\:00/modalias"

# cat /sys/bus/platform/devices/MSHW0029\:00/modalias

acpi:MSHW0029:PNP0C40:

I've built a 3.17rc6 kernel with https://patchwork.kernel.org/patch/4646051/ and CONFIG_INPUT_SOC_BUTTON_ARRAY=m.  On boot, the module seems to be autoloaded, but it does not seem to be registering the input devices correctly:  pushing the power button, the volume buttons, or the case windows button still results in the "No notify handler" messages with ACPI debugging enabled.  I also noticed that this message is printed in dmesg when the power button is pressed or released, but not with the other buttons:

[  341.163948]  exregion-0322 ex_system_io_space_han: System-IO (width 8) R/W 1 Address=0000000000000080

However, I believe that that was happening without the soc_button_array driver.

My outputs for "ls /sys/bus/platform/devices/", "ls /sys/bus/platform/drivers/*/" and "cat /sys/bus/platform/devices/MSHW0029\:00/modalias" are the same as Ethan's.

Created attachment 151661 [details]
debug patch

please apply this debug patch on top, and attach the dmesg output after modprobe soc_button_array device manually.

Created attachment 151671 [details]
debug patch

please use this updated one instead.

Created attachment 151691 [details]
dmseg output after applying debug patch

The attachment log that I added above was generated immediately after modprobing the soc_button_array module.  Since the module was being loaded automatically on boot, I booted the system with modprobe.blacklist=soc_button_arry to be able to capture the output immediately after manually modprobing the driver.

Created attachment 151701 [details]
debug patch 2

please try this debug patch instead of the previous one

Created attachment 151711 [details]
dmesg output after modprobe soc_button_array (with patch 151701)

Here's dmesg output after applying patch 151701

method: booted, soc_button_array was loaded automatically, rmmodded it, modprobed it again.

Rui, just checking in to see if there is anything else I can provide in terms of testing or debug information.

Confirming bug on 3.16.4. Happy to test patches for 3.17. Let me know if there is anything I could do to push this forward. I miss my ability to resume from sleep :)

For what it is worth, I've confirmed this issue is still present in 3.18-rc1.  I also would be happy to help with testing, etc.

Rui, I haven't tried the previous patches against 3.18 since that seemed unlikely to work. Good idea to do so? If not and you have a tweaked patch for 3.18 to test, I'd do it immediately.

please attach the full acpidump output.

Created attachment 158661 [details]
acpidump output

(In reply to Zhang Rui from comment #46)
> please attach the full acpidump output.

This is acpidump output from my current (non-patched) kernel (3.17.3-1-ARCH).

Looking into this some more, it looks like there is a problem looking up the GPIO pins connected to the individual buttons; gpiod_get_index (in drivers/gpio/gpiolib.c) is failing for all of the buttons that soc_button_array tries to look up GPIOs for.  I think this is because the SP3 actually does something differently from the Microsoft-recommended SoC button arrays:  looking into the documents linked to above, and looking at some examples, like http://msdn.microsoft.com/en-us/library/windows/hardware/dn457868(v=vs.85).aspx, it looks like the button array device should have a _CRS method that returns a ResourceTemplate that includes, along with any other necessary resources, GpioInt() objects that describe the GPIO interrupts connected to the various buttons.  The soc_button_array driver tries to find the GPIO interrupts for the buttons by searching among the GPIOs assigned to its device, and can't find any, due to the fact that they aren't mentioned.

I'm still not exactly sure how the SP3 buttons are supposed to work, except for the fact that various ACPI query methods are triggered; according to the spec, the _Qxx query methods are used for Embedded Controller and SMBus events.  Interestingly, the EC0 embedded controller does have a _PRW package that appear to be the same as the one on the LID0 device; however, the testing that I did before, with my kernel patch to send the power key event when the VGBI Notify event with EC0 and LID0 enabled didn't seem to work.

I've been doing this testing with 3.18rc6 and the most recent set of Microsoft firmware updates applied, but I haven't had a chance to redo the /proc/acpi/wakeup test yet because I don't have the above patch that works on the Notify events applied for 3.18rc6 yet.

Created attachment 158821 [details]
3.18rc6 acpidump output

Here's my acpidump output with 3.18rc6; if it's important, I do have a couple of patches for the type cover (one that adds its device id, and another that adds the NO_INIT_REPORTS quirk for it) applied to this kernel.

I can confirm Peter's hypothesis on it being due to the gpio_get_index method failing, enabling dynamic debug printing on gpiolib.c and loading the soc_button_array module gives the following output on 3.19.0-rc5 (repeated 5 times):

[16435.849095] soc_button_array MSHW0029:00: GPIO lookup for consumer soc_button_array
[16435.849104] soc_button_array MSHW0029:00: using ACPI for GPIO lookup
[16435.849115] soc_button_array MSHW0029:00: using lookup tables for GPIO lookup
[16435.849119] soc_button_array MSHW0029:00: lookup for GPIO soc_button_array failed


The status of this bug seems to have been NEED_INFO for a while - I'm willing to provide any information I can. Quite annoying not being able to use device buttons to resume from suspend.

good news is that we've just purchased a surface pro 3 so that we can start debugging the issue locally. we'll give some update soon.

I'm using a Surface Pro 3 running Ubuntu as my main computer; it is excellent for that and fills my needs very well. However the number of hardware features that Windows 8.1 manages to access and Linux does not is discouraging. I don't mean to get off topic, but does anybody know of a blog or forum that can be used to monitor and discuss the whole range of issues?

I am running Ubuntu 14.10 using kernel 3.19 (RC7, but expect to move to the released one).

Some new information: Shortly after I installed the official 3.19.0 kernel with two patches (see below), the lid switch started working--sort of. This is its limited set of capabilities:

1. Read the lid switch at startup.
2. Notice the first time the lid is closed.

If the system boots up with the lid open, it allows the use of the main display even when there is a second display attached. Once it is closed (either at the start or after being closed later), it refuses to use the main display unless there is no secondary display. Closing it also triggers the suspend state (despite the fact that the power setting says to do nothing). Of couse suspend bounces back at once anyway.

This is what DMESG says about the lid switch before it is closed:

[    0.711359] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:14/PNP0C0D:00/input/input0
[    0.711374] ACPI: Lid Switch [LID0]
[    4.253841] systemd-logind[863]: Watching system buttons on /dev/input/event0 (Lid Switch)

Closing the lid adds this line:

[ 1519.055086] systemd-logind[863]: Lid closed.

Note: the two patches that I am using are the camera patch from https://github.com/Vistaus/surface3-arch-antergoslinux/issues/8 and the battery patch from https://bugzilla.kernel.org/show_bug.cgi?id=90161 . Both of these work fine for me. (I have Surface Pro 3 (PS2-00001) 256 gb i5.)

Thanks for your valuable information guys,we've wrote a driver to hack the button on SP3.But since there might be some wakeup issues by button press,we are still working on it.
Best Regards,
Yu

Just wanted to check in on the status of this issue. I know that it may not be finished, but given that the power button doesn't work at all right now, I think many of us running linux on the sp3 would be happy to test even a work-in-progress driver. Any chance of that?

Thanks for the effort on this, regardless.

Best regards,
Ethan

Created attachment 171281 [details]
surface button support patch in test

Created attachment 171291 [details]
workaround to wake surface pro up patch in test

Sure, I've attached the patch we are testing.

Comment #56 is for surface button, and you might need to set CONFIG_SURFACE_BUTTON = m

Comment #57 is to wake system up from freeze mode.

Thanks.

Best Regards,
Yu

Yu,

Looks like it works! I haven't tested it much yet, but the power button does indeed power off the SP3 (3.19 custom arch build). Thanks for this. It makes a WORLD of difference if it proves to be stable.

Best regards,
Ethan

Greetings all,

I have build a kernel for Arch Linux with these patches; and it seems to work quite well. However, on wakeup, the touch panel does not work (the keyboard and touchpad continue to work fine).

Otherwise, looking good!

Thank you!

I should add that the touch screen can be enabled manually using xinput; and that if it had been manually enabled before suspending, then it seems to come back up fine.

Okay... sorry. Whether or not the touchscreen works after wakeup seems to have more to do with how quickly I ask it to return. Perhaps if it doesn't finish suspending before you recall it, things work fine.

It works for me too, thanks

But it can't suspend now (returns back on after a few seconds):

 2031.920543] PM: Entering freeze sleep
[ 2031.920545] Suspending console(s) (use no_console_suspend to debug)
[ 2031.920703] mwifiex_pcie 0000:01:00.0: None of the WOWLAN triggers enabled
[ 2035.431460] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2035.433410] sd 0:0:0:0: [sda] Stopping disk
[ 2035.602049] PM: suspend of devices complete after 3683.417 msecs
[ 2035.655437] PM: late suspend of devices complete after 53.411 msecs
[ 2035.655974] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 2035.669133] PM: noirq suspend of devices complete after 13.675 msecs
[ 2037.414879] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2037.414888] acpi device:16: Failed to change power state to D0
[ 2037.414935] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 2037.427795] PM: noirq resume of devices complete after 1759.642 msecs
[ 2037.481081] PM: early resume of devices complete after 53.282 msecs
[ 2037.489030] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 2037.494382] sd 0:0:0:0: [sda] Starting disk
[ 2037.814149] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2037.816253] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2037.816640] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2037.816674] ata1.00: configured for UDMA/133
[ 2041.728692] PM: resume of devices complete after 4249.983 msecs
[ 2041.728910] PM: Finishing wakeup.
[ 2041.728912] Restarting tasks ... done.
[ 2044.808976] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2044.809049] acpi device:16: Failed to change power state to D0
[ 2047.819590] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2047.819627] acpi device:16: Failed to change power state to D0
[ 2050.666214] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2050.666250] acpi device:16: Failed to change power state to D0
[ 2053.631367] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2053.631425] acpi device:16: Failed to change power state to D0
[ 2053.995092] usb 1-3: new full-speed USB device number 7 using xhci_hcd
[ 2054.169019] usb 1-3: No LPM exit latency info found, disabling LPM.
[ 2054.174242] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:045E:07DC.0006/input/input18
[ 2054.225406] microsoft 0003:045E:07DC.0006: input,hiddev0,hidraw1: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-3/input0
[ 2055.879164] usb 1-3: USB disconnect, device number 7
[ 2056.815503] cfg80211: Calling CRDA to update world regulatory domain
[ 2056.847129] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[ 2058.901559] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2058.901611] acpi device:16: Failed to change power state to D0
[ 2060.617531] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2060.617552] acpi device:16: Failed to change power state to D0
[ 2060.762810] PM: Syncing filesystems ... done.
[ 2061.905978] PM: Preparing system for freeze sleep
[ 2061.906293] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 2061.908362] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2061.909575] PM: Entering freeze sleep
[ 2061.909577] Suspending console(s) (use no_console_suspend to debug)
[ 2061.909732] mwifiex_pcie 0000:01:00.0: None of the WOWLAN triggers enabled
[ 2065.421352] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2065.423347] sd 0:0:0:0: [sda] Stopping disk
[ 2065.618581] PM: suspend of devices complete after 3710.934 msecs
[ 2065.671964] PM: late suspend of devices complete after 53.407 msecs
[ 2065.672532] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 2065.685669] PM: noirq suspend of devices complete after 13.683 msecs
[ 2067.432110] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2067.432119] acpi device:16: Failed to change power state to D0
[ 2067.432486] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 2067.444327] PM: noirq resume of devices complete after 1759.640 msecs
[ 2067.497561] PM: early resume of devices complete after 53.232 msecs
[ 2067.499517] sd 0:0:0:0: [sda] Starting disk
[ 2067.507130] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 2067.817337] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2067.819406] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2067.819713] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2067.819747] ata1.00: configured for UDMA/133
[ 2071.748485] PM: resume of devices complete after 4253.299 msecs
[ 2071.748726] PM: Finishing wakeup.
[ 2071.748728] Restarting tasks ... done.
[ 2072.031666] usb 1-3: new full-speed USB device number 8 using xhci_hcd
[ 2072.205146] usb 1-3: No LPM exit latency info found, disabling LPM.
[ 2072.209893] input: Microsoft Surface Type Cover as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.0/0003:045E:07DC.0007/input/input19
[ 2072.261843] microsoft 0003:045E:07DC.0007: input,hiddev0,hidraw1: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-3/input0
[ 2087.358340] cfg80211: Calling CRDA to update world regulatory domain
[ 2087.395992] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[ 2087.800094] PM: Syncing filesystems ... done.
[ 2091.926603] PM: Preparing system for freeze sleep
[ 2091.926928] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 2091.929097] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2091.930313] PM: Entering freeze sleep
[ 2091.930316] Suspending console(s) (use no_console_suspend to debug)
[ 2091.930516] mwifiex_pcie 0000:01:00.0: None of the WOWLAN triggers enabled
[ 2095.440716] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2095.442662] sd 0:0:0:0: [sda] Stopping disk
[ 2095.645192] PM: suspend of devices complete after 3716.795 msecs
[ 2095.698473] PM: late suspend of devices complete after 53.305 msecs
[ 2095.699003] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 2095.712181] PM: noirq suspend of devices complete after 13.686 msecs
[ 2097.459991] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2097.460001] acpi device:16: Failed to change power state to D0
[ 2097.460367] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 2097.470843] PM: noirq resume of devices complete after 1759.643 msecs
[ 2097.524053] PM: early resume of devices complete after 53.209 msecs
[ 2097.537203] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 2097.537404] sd 0:0:0:0: [sda] Starting disk
[ 2097.844047] usb 1-3: reset full-speed USB device number 8 using xhci_hcd
[ 2097.857182] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2097.859264] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2097.859694] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2097.859777] ata1.00: configured for UDMA/133
[ 2098.017489] usb 1-3: No LPM exit latency info found, disabling LPM.
[ 2098.239986] bluetooth hci0:128: parent hci0 should not be sleeping
[ 2101.778348] PM: resume of devices complete after 4256.673 msecs
[ 2101.778555] PM: Finishing wakeup.
[ 2101.778557] Restarting tasks ... done.
[ 2101.786780] NET: Registered protocol family 38
[ 2169.285917] cfg80211: Calling CRDA to update world regulatory domain
[ 2194.562268] cfg80211: Calling CRDA to update world regulatory domain
[ 2194.605445] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[ 2194.936435] PM: Syncing filesystems ... done.
[ 2196.821890] PM: Preparing system for freeze sleep
[ 2196.822211] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 2196.824329] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[ 2196.825179] PM: Entering freeze sleep
[ 2196.825182] Suspending console(s) (use no_console_suspend to debug)
[ 2196.825386] mwifiex_pcie 0000:01:00.0: None of the WOWLAN triggers enabled
[ 2200.339213] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2200.341180] sd 0:0:0:0: [sda] Stopping disk
[ 2200.573099] PM: suspend of devices complete after 3749.857 msecs
[ 2200.626408] PM: late suspend of devices complete after 53.333 msecs
[ 2200.626984] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 2202.386798] ACPI Error: Method parse/execution failed [\_SB_.PCI0.XHC_._PS0] (Node ffff8802470a5528), AE_AML_INFINITE_LOOP (20150204/psparse-536)
[ 2202.386806] acpi device:16: Failed to change power state to D0
[ 2202.386842] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 2202.398760] PM: noirq resume of devices complete after 1759.672 msecs
[ 2202.398782] PM: noirq suspend of devices failed
[ 2202.451999] PM: early resume of devices complete after 53.238 msecs
[ 2202.452427] sd 0:0:0:0: [sda] Starting disk
[ 2202.454331] rtc_cmos 00:01: System wakeup disabled by ACPI
[ 2202.771782] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2202.773813] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2202.774074] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 2202.774107] ata1.00: configured for UDMA/133
[ 2206.702999] PM: resume of devices complete after 4253.375 msecs
[ 2206.703217] PM: Finishing wakeup.
[ 2206.703219] Restarting tasks ... done.

Hm, after reboot it works fine now with suspend.

I'm running 4.0-RC4 in Ubuntu 14.10. Recognition of the volume, home, and power buttons is definitely now working. However, all that suspending does is to suspend, bounce back, and go to locked screen.

I'm going to try the "freeze" workaround listed in launchpad bug 1380076 (Ubuntu) which previously put you into a dead end with no way out.

Hi, Anton Anikin and  Keith McClelland,
Do you test freeze with the usb device plugged? If so, please remove the
usb device and see if it works, thanks!

Best Regards,
Yu

suspend-to-idle works fine, resumes fine too (in this state the full charged battery drains in about 2 days). 
hibernate - freezes on resume.

The combination of the freeze workaround and the power button fix does allow freezing, staying frozen, and resuming. However, the freeze doesn't last too long, a few minutes to an hour, and then it resumes again. When I did this I was not connected to the docking station and had networking turned off. However, the type cover, which is a USB device, was connected. I will turn off networking, disconnect the type cover, power it by its charger rather than the docking station, and see if that stays frozen.

With the freeze patch (launchpad bug 1380076) installed and the power button patch in the kernel it can still fail to stay suspended. However I think there are two causes in my system and without them it will stay frozen at least until there is a power glitch:
- Bluetooth on, even with nothing paired, is certain to cause return from freeze
- Some things on USB can cause return from freeze (I had a USB hub and a card reader dongle and removed them both so I don't know which did it). Note that my Microsoft wireless mouse & keyboard (which has a tiny USB transceiver) does not cause any trouble.

I have read that the Surface Pro 3's lid switch is another part of the set of switches that surface_button.c addresses. So I was surprised that it was not included in this patch. This switch has been partially handled in an unfortunate way: closing the lid throws the computer into an odd state in which it will no longer show the main display except when the secondary display is disconnected. Opening the lid does nothing, so there seems to be now way out of this odd state. In fact after the first closing there are no more dmesg messages relating to LID0. I have set the action for lid closing to "no action" (which is obviously being ignored).

Please help me to properly address this bug if it has not been already. Thanks.

I applied the patches (comment #56 and from https://patchwork.kernel.org/patch/4646051 ) to a 3.16 kernel from ubuntu. The surface_button module loads successfully, but I get neither a MSHW0029:00 entry nor do I get an other button than lid0 under /proc/acpi/button/. 

Is it possible to get the surface_button module working with a 3.16 kernel or are there other changes from 3.19 involved?

Keith McClelland,
lid on sp3 obeys the standard acpi spec so I did not rewrite it in surface_button.c.I did not quit understand what you described in Comment 71,
'secondary display is disconnected' do you mean an extra monitor connect with sp3?

Hironimus 
sp3 buttons are not exposed in proc, does power button work on your tablet?

(In reply to Chen Yu from comment #73)
> Keith McClelland,
> lid on sp3 obeys the standard acpi spec so I did not rewrite it in
> surface_button.c.I did not quit understand what you described in Comment 71,
> 'secondary display is disconnected' do you mean an extra monitor connect
> with sp3?

Yes. The VGA dongle detects the monitor, whether or not it is powered.

Unfortunately, as I've pointed out, the lid switch can't completely obey the spec since opening the lid after closing it is not detected.

One more point: even though dmesg only sees the lid close once, suspension is broken every time it is closed. [I would consider it a bug for closing the lid to EVER break suspension since what anyone would do would be to suspend with the lid open and then close it up for transport.]

(In reply to Chen Yu from comment #74)
> Hironimus 
> sp3 buttons are not exposed in proc, does power button work on your tablet?

Hi Chen Yu,
no, power button does not work.

Hi all,

I made the observation that using the surface button driver freezing and waking up the system works fine for kernel 3.17. But if I use kernel 3.19 only freezing works but not waking up. This is because in kernel 3.19 the acpi interrupt handler is not installed with flag IRQF_NO_SUSPEND. There was a change in drivers/acpi/osl.c (acpi_os_install_interrupt_handler). If I add the flag waking up the system works fine with kernel 3.19 too.

I talk about this change:

commit a8d46b9e4e487301affe84fa53de40b890898604
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Sep 30 02:29:01 2014 +0200

    ACPI / sleep: Rework the handling of ACPI GPE wakeup from suspend-to-idle
    
    The ACPI GPE wakeup from suspend-to-idle is currently based on using
    the IRQF_NO_SUSPEND flag for the ACPI SCI, but that is problematic
    for a couple of reasons.  First, in principle the ACPI SCI may be
    shared and IRQF_NO_SUSPEND does not really work well with shared
    interrupts.  Second, it may require the ACPI subsystem to special-case
    the handling of device notifications depending on whether or not
    they are received during suspend-to-idle in some places which would
    lead to fragile code.  Finally, it's better the handle ACPI wakeup
    interrupts consistently with wakeup interrupts from other sources.
    
    For this reason, remove the IRQF_NO_SUSPEND flag from the ACPI SCI
    and use enable_irq_wake()/disable_irq_wake() with it instead, which
    requires two additional platform hooks to be added to struct
    platform_freeze_ops.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Ok. My ACPI knowledge is not good so please correct me if I tell something wrong. Now it is only possible to wake up the system with special wakeup GPEs. But if a have a look at the DSDT I can not find a GPE for MSHW0028. Thats why there exists no GPE and no wakeup GPE. I assume that this is the reason why I can not wake up the system with original kernel 3.19.

Additionally I can not find the device at /proc/acpi/wakeup. That's why the patch at comment #57 doesn't work for me.

What can I do to add the device in /proc/acpi/wakeup and what can I do to wake up the system with original kernel 3.19?

Thank you & best regards,
Dennis

(In reply to Keith McClelland from comment #76)
> One more point: even though dmesg only sees the lid close once, suspension
> is broken every time it is closed. [I would consider it a bug for closing
> the lid to EVER break suspension since what anyone would do would be to
> suspend with the lid open and then close it up for transport.]

Hmm.. yes, it seems that LID does not abey the acpi spec,althoug it has a correct name"PNP0C0D", there's no Notify invoked to infor LID0 about lid open event.This is the reason why lid does not work properly. It seems that we have to use customized dsdt to workaround. I'll update the bios to see if MS fix this, or find a way to hack.

With 4.0-rc5 kernel on Arch Linux the patches above work fine, including the lid.

(In reply to Anton Anikin from comment #80)
> With 4.0-rc5 kernel on Arch Linux the patches above work fine, including the
> lid.

Hi Anton Anikin
If you close the lid for the second time, will it lock screen?
Can you provide your acpidump?

Created attachment 172551 [details]
ACPI dump

Yes, it suspends-to-idle, I am using it many times during the day now.

(In reply to Anton Anikin from comment #83)
> Yes, it suspends-to-idle, I am using it many times during the day now.
Thanks
I've checked your acpidump file, there is still no Notify callback for lid open, thus I'll check 4.0 rc-5 tomorrow to see if it fix the issue.

(In reply to Anton Anikin from comment #83)
> Yes, it suspends-to-idle, I am using it many times during the day now.

On rc-6, lid bug still exist.Do you only apply Comment #56 and Comment #57?
Actually I choose 'lock screnn' when close the lid, it's not freeze-to-idle.

On surface pro 3, for lid there's two bugs, one is described in Comment #79, another is https://bugzilla.kernel.org/show_bug.cgi?id=89211, both of they are dsdt issues, but linux might be responsible for dealing with these situation.

There are another patches apllied too, but not related to the lid and buttons...
Here is the full patchset I am using:
        "https://dl.dropboxusercontent.com/u/4080500/patch/gistfile1.diff"
        "https://dl.dropboxusercontent.com/u/4080500/patch/battery.patch"
        "https://dl.dropboxusercontent.com/u/4080500/patch/cam.patch"
        "https://dl.dropboxusercontent.com/u/4080500/patch/button1.patch"
        "https://dl.dropboxusercontent.com/u/4080500/patch/button2.patch"

(In reply to Dennis Wassenberg from comment #78)
> Hi all,
> 
> Thank you & best regards,
> Dennis

Hi Dennis,
It's not MSHW0028 wake up the system but the EC0(actually is LID0, since EC0 shares the same PRW with LID0, you can see LID0 is enabled in proc/acpi/wakeup), when button pressed, EC will get the event and dispatches it to MSHW0028. I'll test it on older version after LID issue solved first(Comment #86)

Maybe the battery patch makes the sense?
https://dl.dropboxusercontent.com/u/4080500/patch/battery.patch
It allows to battery level to be available (it stopped to be available since some 3.19x kernel builds or early).

(In reply to Chen Yu from comment #88)
> Hi Dennis,
> It's not MSHW0028 wake up the system but the EC0(actually is LID0, since EC0
> shares the same PRW with LID0, you can see LID0 is enabled in
> proc/acpi/wakeup), when button pressed, EC will get the event and dispatches
> it to MSHW0028. I'll test it on older version after LID issue solved
> first(Comment #86)

I think I didn't got it... If I want to wakeup the system with power button it should be device VGBI?! VGBI has no _PRW. I thought that's the reason why it worked with kernel < 3.19 but not with kernel >= 3.19 because of commit a8d46b9e4e487301affe84fa53de40b890898604.

Ok, Method _Q60 is registered for device EC0 and it will notify device VGBI. I found it at the DSDT. If the SP3 is in suspend state it will not handle ACPI SCI interrupts in suspend state because IRQF_NO_SUSPEND is not set for the interrupt handler any more. So we have to setup a wakeup GPE to wakeup the system. But do we have to setup a wakeup GPE for VGBI or EC0?

Because of the fact that EC0 has a _PRW method everything should be prepared to wakeup the system if a notify occurred?! If I have a look at /proc/acpi/wakeup, yes LID0 is active but not EC0 by default. But even if I activate EC0 (echo EC0 > /proc/acpi/wakeup), it is still not possible for me to wakeup the SP3 with power button press.

Regards, Dennis

Hi Anton,

Nice wrap up of the patches to apply.
I built a 4.0-rc5 on Fedora 22 alpha, and I ended up with type cover not working.
Is it you who wrote https://dl.dropboxusercontent.com/u/4080500/patch/gistfile1.diff ?
I would like to understand why it remove references to USB_DEVICE_ID_MS_TYPE_COVER_3, to keep only USB_DEVICE_ID_MS_TYPE_COVER_3_JP. On my Surface Pro 3, the type cover has the id 045e:07dc.

Regards -- Fabien

No, this patch is from this thread:
https://github.com/nuclearsandwich/surface3-archlinux/issues/4#issuecomment-87403511
It allows to use multitouch and scrolling with synaptics drivers with touchpad.

my cover is 045e:07dc too, works fine with these patches.

Well, I removed the part removing the non JP cover and it works fine.

And touchpad multitouch works after this?

Unfortunately no, but I think it is more a matter of Xorg configuration.
Could any of you share his/her Xorg configuration ?

BTW, my device shuts down when I push the power button. How can I make it hibernate instead ?

Surface cover keyboard should be removed from the microsoft HID section in the kernel drivers and added to the multitouch devices section with patch above, synaptic driver should be installed and ClickPad option should be activated to use right click:
Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
        Option "TapButton1" "1"
        Option "TapButton2" "2"
        Option "TapButton3" "3"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
        MatchDevicePath "/dev/input/event*"
EndSection

Section "InputClass"
        Identifier "Default clickpad buttons"
        MatchDriver "synaptics"
        Option "ClickPad" "true"
        Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
        Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%"
EndSection


About hibernate - have you tested it with console? My Surface can't resume back from hibernate properly... So I am using suspend-to-idle only.

I'm using ubuntu with a patched 3.19 kernel now. I also removed the parts removing the non JP cover lines from the multitouch patch, but the multitouch does not work. I tried several xorg configurations with no success. X can not detect any synaptics device.

Needed only to add hid_multitouch to my initramfs. Now multitouch and keyboard are working with the original patch.

The https://dl.dropboxusercontent.com/u/4080500/patch/gistfile1.diff patch makes a big difference, but the touchpad, despite having more capabilities, works very oddly. For example, left and right click require different kinds of motion and right click is sometimes impossible to perform. Comments 97 and 99 suggest improvements, but I'm not enough of a guru to figure out where to put those suggestions. Please help! Thanks.

We are getting way off topic here. Does anyone know a better place to discuss this?

I would also like help on unhandled keyboard keys, the half-functionality of the pen buttons, and so on. Has anyone found such discussions?

Keith, I agree that we should move these ongoing discussions to another channel. I just created a Google Group for this purpose. If people want to join it and continue the discussion there, that would work for me. If not, no problem.

http://groups.google.com/d/forum/linux-surface

I'm aware of the subreddit and github repo with issues queue regarding the Surface / SP3 but I find those to be less appropriate for catch all discussion. Up to everyone else if they want to give this group a shot.

-Ethan

Hi, I have a SP3 256GB i7 and I am running Kali Linux with the 4.0 official kernel with a few patches to enable functionality of both the front and rear cameras, and microphone. The kernel comes with native support for the type keyboard now, and all that's left are the buttons. So my question is: can anybody sum up which patches exactly to use, and compile a custom 4.0 kernel with these patches to see if they work?

Regards,
Matthew

I wonder where the patches mentioned in Matthew's post are. I am also interested in running 4.0.5 on a Surface Pro 3.

sorry for the delay guys, quite busy these days, we'll send out the formal patch once 4.2-rc1 came out. it's based on #Comment 56.

Yu

Thanks, Yu! Will you consider backporting to 4.1 since it takes 2 months for a kernel to become stable.

No, this is not a stable material, thus it won't be took by Linus even if Yu tries to push it for -stable.

BTW, patch will be sent out after 4.2-rc1 released as it is merge window currently.

In reply to comment #104;

All of the patches that I spoke about were listed in comment #87. Also, I tried using power button patch with the 4.0.2 kernel on Kali Linux Alpha 2, and I can't get the button to even show up, let alone function.

Regards,
Matthew

(In reply to Zhang Rui from comment #108)
> BTW, patch will be sent out after 4.2-rc1 released as it is merge window
> currently.

Rui,

Wanted to remind you that 4.2-rc1 has been released so you could send the patch out.

Just out of curiosity, has anybody attempted to make a patch for the Surface Pro 3's Volume rocker, or menu button? And if so, would it be possible to incorporate it into the power button patch, because they are part of same general topic.

(In reply to Matthew Barichello from comment #111)
> Just out of curiosity, has anybody attempted to make a patch for the Surface
> Pro 3's Volume rocker, or menu button? And if so, would it be possible to
> incorporate it into the power button patch, because they are part of same
> general topic.

It looks like that's already a part of the patch.

(In reply to comment #112)
Has anybody actually had any success with the volume rocker, or menu button? I cant seem to get them to respond to any interaction.

patch will be sent out today.
Thanks.

sent to 
http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/7472
Thanks.

(In reply to Matthew Barichello from comment #113)
> (In reply to comment #112)
> Has anybody actually had any success with the volume rocker, or menu button?
> I cant seem to get them to respond to any interaction.

I have no problem with them with custom 4.0.6 and 4.0.7 kernels with the submitted patch applied. But I'm also using https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c832b3e85b6ac35e5f113fa4204eb725c54794e. When I tried to turn Chen's patch into a module before applying the linked battery patch, it didn't work.

Hmm something odd is happening... I just finished compiling the 4.1.2 kernel with only the Buttons patch that was just posted by Chen Yu comment #115 (because the camera patch, and the type cover patch have been incorporated into the main build) and for whatever reason, my thermal sensor is now reporting that the CPU in my SP3 is running at -276°C, at idle and it varies depending on the temperature of the surface... Any ideas?

(In reply to Zvi "CtrlZvi" Effron from comment #116)
> (In reply to Matthew Barichello from comment #113)
> I have no problem with them with custom 4.0.6 and 4.0.7 kernels with the
> submitted patch applied. But I'm also using
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=1c832b3e85b6ac35e5f113fa4204eb725c54794e. When I tried to turn Chen's
> patch into a module before applying the linked battery patch, it didn't work.
Hello,
this patch should not be related to battery, do you mean, when you use 4.0.6 + patch at commend #115, power button does not work? plz also try latest kernel since I've generated the patch on 4.2-rc2...
Yu

(In reply to Matthew Barichello from comment #117)
> Hmm something odd is happening... I just finished compiling the 4.1.2 kernel
> with only the Buttons patch that was just posted by Chen Yu comment #115
> (because the camera patch, and the type cover patch have been incorporated
> into the main build) and for whatever reason, my thermal sensor is now
> reporting that the CPU in my SP3 is running at -276°C, at idle and it varies
> depending on the temperature of the surface... Any ideas?

Hello,
This might be another problem related to thermal,better file another bugzilla thread to track it.

which sysfs do you look at? can you please provide following information:
grep . /sys/class/thermal/thermal_zone*/type
grep . /sys/class/thermal/thermal_zone*/temp
grep . /sys/class/thermal/cooling_device*/type
grep . /sys/class/thermal/cooling_device*/cur_state

the x86_pkg_temp is caculated by hardware feedback, and the acpitz's temperature is return by BIOS's _TMP method.

Yu

Chen Yu,

I've applied your patch to 4.2-rc2, however the buttons no longer do anything. The power button will not put my SP3 to sleep, the volume buttons will not adjust volume, and the Windows key no longer brings up the GNOME Shell overlay. All of this worked with your previous testing patch.

I am certain they are being detected though since any of the hardware buttons will wake up my SP3. Do I need to manually map the keys or will they need something else?

For reference, I'm using Fedora 22 with your patch applied to the master branch of Fedora's kernel git tree (my copy can be found here: https://github.com/shvr/fedora-surface-pro-3-kernel). If you need any logs or other information I'll be happy to supply them.

Thanks for your work,

Donavan

Donavan,
(In reply to Donavan Lance from comment #120)
> Chen Yu,
>
> I've applied your patch to 4.2-rc2, however the buttons no longer do
> anything. The power button will not put my SP3 to sleep, the volume buttons
> will not adjust volume, and the Windows key no longer brings up the GNOME
> Shell overlay. All of this worked with your previous testing patch.
>
[Yu] Do you mean it works on 4.2-rc2 with previous patch comment #56 applied?

> For reference, I'm using Fedora 22 with your patch applied to the master
> branch of Fedora's kernel git tree (my copy can be found here:
> https://github.com/shvr/fedora-surface-pro-3-kernel). If you need any logs
> or other information I'll be happy to supply them.
>
[Yu] I've not tested on fedora, and could you please do the following:

1. # cd /sys/kernel/debug/dynamic_debug
2. 
# cat control | grep acpi_ec_run
drivers/acpi/ec.c:628 [acpi]acpi_ec_run =p "##### Query(0x%02x) stopped #####\012"
drivers/acpi/ec.c:623 [acpi]acpi_ec_run =p "##### Query(0x%02x) started #####\012"
3. file name and line number should be the same as step 2
# echo -n 'file drivers/acpi/ec.c line 628 +p' > control
# echo -n 'file drivers/acpi/ec.c line 623 +p' > control
4. press the power button,volume, etc, and please provide the dmesg log.


5. please do the following:
cat /proc/bus/input/devices and find the input device for MSHW0028,
and find which input event number it is using, the use this number as 
a parameter to execute check_sp3_buttons attached. 
For example, here's my step to check keyboard event(you should replace it
with MSHW0028):
5.1 cat /proc/bus/input/devices
from "H: Handlers=sysrq kbd event12"
we know the number is 12
5.2 gcc check_sp3_buttons.c -o check_sp3_buttons
5.3 ./check_sp3_buttons 12
5.4 press power button, volume button to see if there's any information.

thanks.
Yu

Created attachment 182901 [details]
check_sp3_buttons.c: check sp3 button input events after patch applied

Created attachment 182921 [details]
dmesg output for 4.2-rc2

(In reply to Chen Yu from comment #121)
> Donavan,
> (In reply to Donavan Lance from comment #120)
> > Chen Yu,
> >
> > I've applied your patch to 4.2-rc2, however the buttons no longer do
> > anything. The power button will not put my SP3 to sleep, the volume buttons
> > will not adjust volume, and the Windows key no longer brings up the GNOME
> > Shell overlay. All of this worked with your previous testing patch.
> >
> [Yu] Do you mean it works on 4.2-rc2 with previous patch comment #56 applied?
> 

[Donavan] It works on 4.1, with the patch from comment #56 applied.

> > For reference, I'm using Fedora 22 with your patch applied to the master
> > branch of Fedora's kernel git tree (my copy can be found here:
> > https://github.com/shvr/fedora-surface-pro-3-kernel). If you need any logs
> > or other information I'll be happy to supply them.
> >
> [Yu] I've not tested on fedora, and could you please do the following:
> 
> 1. # cd /sys/kernel/debug/dynamic_debug
> 2. 
> # cat control | grep acpi_ec_run
> drivers/acpi/ec.c:628 [acpi]acpi_ec_run =p "##### Query(0x%02x) stopped
> #####\012"
> drivers/acpi/ec.c:623 [acpi]acpi_ec_run =p "##### Query(0x%02x) started
> #####\012"
> 3. file name and line number should be the same as step 2
> # echo -n 'file drivers/acpi/ec.c line 628 +p' > control
> # echo -n 'file drivers/acpi/ec.c line 623 +p' > control
> 4. press the power button,volume, etc, and please provide the dmesg log.
> 
> 
> 5. please do the following:
> cat /proc/bus/input/devices and find the input device for MSHW0028,
> and find which input event number it is using, the use this number as 
> a parameter to execute check_sp3_buttons attached. 
> For example, here's my step to check keyboard event(you should replace it
> with MSHW0028):
> 5.1 cat /proc/bus/input/devices
> from "H: Handlers=sysrq kbd event12"
> we know the number is 12
> 5.2 gcc check_sp3_buttons.c -o check_sp3_buttons
> 5.3 ./check_sp3_buttons 12
> 5.4 press power button, volume button to see if there's any information.
> 
> thanks.
> Yu

[Donavan] I've attached my dmesg output. The volume buttons now seem to be working but the power and windows button still do nothing. The windows button did not register in either the dmesg or check_sp3_buttons output. Here's the output I received from check_sp3_buttons:

key 114 Pressed
key 114 Released
key 115 Pressed
key 115 Released
key 116 Pressed
key 116 Released

I'm using a couple extra patches to enable multitouch on my touchpad and to get the cameras working. I'm going to rebuild my kernel without any extra patches to rule out the chance that they are interfering with this. I'll report back with any information.

Cheers,

Donavan

Tried a new build without any additional patches. Didn't help or change anything, got the same results as I did in my previous comment (comment #124).

(In reply to comment #119)
Sorry, I don't currently have the time to go and check the thermal probes, I'm up to my eyes in work at the moment, but I will check within the next day or so. Also, (in relation to comment #120 & comment #124) I haven't been able to get any of the buttons working on my SP3. I've compiled the kernel versions, 4.0.2, 4.1.2, & 4.2-rc2, and I cannot get the buttons to work at all, so I don't know if like Donavan said, I have to map them, or they are just not registering. 

Oh and to Donavan, what patches are you using for multitouch because I can't seem to get that working either. I was able to get the cameras and microphone working, but after updating from kernel 4.0.2 I haven't even been able to move the mouse onscreen with the touchpad.

Regards,
Matthew

(In reply to Donavan Lance from comment #125)
> Tried a new build without any additional patches. Didn't help or change
> anything, got the same results as I did in my previous comment (comment
> #124).
thanks.
1. There is something wrong with touchscreen driver(home button rely on this), maybe a regression.
2. I'll install Fedora on my sp3 and have a try.
Yu

@Yu,

If it would be helpful I can also provide logs / information from your patch applied to 4.2-rc1 and 4.1.2. I still have my RPMs for those builds.


@Matthew, all of the patches I am using can be found in my GitHub repo that I linked to in comment #120. Patches are for 4.2-rc1 but older patches exist in the repo history.

(In reply to Donavan Lance from comment #128)
> @Yu,
> 
> If it would be helpful I can also provide logs / information from your patch
> applied to 4.2-rc1 and 4.1.2. I still have my RPMs for those builds.
> 
humm, I confirmed the touchscreen problem is brought between 4.1-rc8 and 4.2-rc1. So I have two things to do, bisect and try on fedora.
this weekend I'll try to spend some time on it.
Thanks for your patience.
Yu

commit d32932d02e1869be838cea3ace42467c360db377
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date:   Mon Apr 13 14:11:59 2015 +0800

    x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces

bisect shows this one breaks the sp3 driver, need to take a look at why it break touchscreen driver.

Jiang has fixed above issue and patch has been sent out, please refer to:
http://www.gossamer-threads.com/lists/linux/kernel/2227028

after applied the patch, my surface pro 3 works again, but once I updated my kernel to 4.2-rc4, the screentouch does not work. So I did another bisect, and found the regression commit at this one:

commit 20dacb71ad283b9506ee7e01286a424999fb8309
    ACPI / PM: Rework device power management to follow ACPI 6

will look at it.

Yu

Yu,

With the above patch in comment #130 applied to 4.2-rc4 and your patch from comment #115 the volume buttons now work. However pressing the power button still will not put the Surface to sleep. The power button is detected and will wake the Surface from sleep. Is there a way to get the Surface to sleep when the power button is pushed or is something else interfering with that?

Another thing I've noticed is that the even with the touchscreen not working the Windows button will also wake the Surface from sleep. Once woken up the button will not function anymore. Using the steps you outlined in comment #121 the Windows button showed up in my dmesg as follows:

[  857.857597] ACPI : EC: Query(0x51) started
[  857.857597] ACPI : EC: Query(0x51) stopped

I've also attached my full dmesg. Output from your check_sp3_buttons program is the same as I received in comment #124.

Thanks,

Donavan Lance

Created attachment 184061 [details]
dmesg output for 4.2-rc4

Yu,

Ok, an update on my comment #132. The power button does indeed work, but it will only work at the GDM login screen and in the virtual console. Inside of a DE (GNOME 3.16, Xfce 4.12) the power button will do nothing. It is being detected within the DE, as power button presses are logged in journalctl and viewable when performing an evtest. I've tried to custom map the button to "systemctl sleep" and have also tried to map it to "XF86Sleep" without any success.

But at least the button itself (and the button patch - comment #115) is working! Thanks for that. If you have any ideas on getting the button working in a DE I'm all ears. I've done all I know to do. Maybe it's evdev / libinput related?

Cheers,

Donavan Lance

Hi, Donavan Lance
do you have bandwidth to help test this patch attached, which will fix a regression at comment #131, please also with http://www.gossamer-threads.com/lists/linux/kernel/2227028 patched.
thanks.

Yu

Created attachment 184101 [details]
Patch to fix a regression for D3Hot power switching to D0

Sure. I'll reply back in a few hours.

With the patches from comment #136, http://www.gossamer-threads.com/lists/linux/kernel/2227028, and the button patch from comment #115 I can confirm that the buttons and the touchscreen work on kernel 4.2-rc4.

Everything seems to be working fine with the exception of the power button. I'm getting the same behavior as I did previously, the power button will put the Surface to sleep at the GDM login screen and virtual console but not while logged into GNOME.

Amending my previous comment, with all of the patches everything works fine. Touchscreen, hardware buttons, everything works as expected. Tested on a clean installation of Fedora 22. It seems there was an issue with my old installation which affected the use of the power button inside of GNOME.

Sorry for the confusion and noise about that, and thanks for the patches.

Donavan Lance

BTW, the power transition regression was already fixed by another upstream patch at
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi/device_pm.c?id=71b65445f0ed04c2afe3660f829779fddb2890c1
so it should work on latest kernel v4.2-rc5.
With regard to button patch, is it ok to add
Tested-by: Donavan Lance <tusklahoma@gmail.com> ?

Yeah, looks good.

Hi Chen,

Is it possible for the device filter on this patch to be more specific? (If that makes any sense.)

The Surface 3 (non-pro) also has an MSHW0028 as part of device TEV2 in its ACPI tables, which also seems to include references to the power button device, but the operation is completely different from the SP3 (and your patch doesn't work, but does cause the Surface Pro 3 Buttons driver to be associated with the device).

Thanks

Thanks Stephen,
do you mean, the device name of hid MSHW0028 on surface 3 is 'TEV2',
rather than 'VGBI' on surface pro 3?

maybe following code will work:


static int surface_button_add(struct acpi_device *device)
{
	struct surface_button *button;
	struct input_dev *input;
	const char *hid = acpi_device_hid(device);
	char *name;
	int error;

+	if(strncmp(acpi_device_bid(device), "VGBI", 4))
+		return -ENODEV;

Thanks, this seems to work as expected, and your module is no longer loaded for my Surface 3.

Here's a quick question;
I want to install Android Lollipop on my SP3 as an alternate "tablet" like OS. Will these Linux kernel patches work with the Android kernel? I have never compiled an Android kernel so that's why i'm asking.

I haven't compiled Android kernel neither, but this patch should work on Android too, you can have a try.
thx

patch merged:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/surfacepro3_button.c?id=2508a45a924dfa4a5f6e60675aa4732d888134a7

Another quick question:

Are the buttons sending any scancodes? If not, is there a way to include this?