Bug 102281 - Powerbutton not detected/handled on Dell Venue 11 Pro (7140)
Summary: Powerbutton not detected/handled on Dell Venue 11 Pro (7140)
Status: NEEDINFO
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: platform_x86_64@kernel-bugs.osdl.org
URL:
Keywords:
: 150701 153101 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-05 00:18 UTC by Jan-Michael Brummer
Modified: 2018-10-19 12:01 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.2-rc5
Tree: Mainline
Regression: No


Attachments
Power button handling for Dell Venue 11 Pro (7140) (6.52 KB, application/octet-stream)
2015-08-05 00:18 UTC, Jan-Michael Brummer
Details
acpidump of DV11P 7140 (132.79 KB, application/octet-stream)
2015-08-31 06:04 UTC, Jan-Michael Brummer
Details
Updated driver (6.55 KB, application/octet-stream)
2016-02-08 19:24 UTC, Jan-Michael Brummer
Details
Updated driver v2 (7.13 KB, application/octet-stream)
2016-02-10 22:00 UTC, Jan-Michael Brummer
Details
Output of grep . -r "/sys/firmware/acpi/interrupts/" (7.35 KB, text/plain)
2016-03-16 21:35 UTC, Alexander Diewald
Details
Dmesg with "acpi.debug_layer=0xffffffff acpi.debug_level=0x4" bootline (495.23 KB, text/plain)
2016-03-16 21:38 UTC, Alexander Diewald
Details
Decompiled DSDT (from version A09) (594.23 KB, text/x-dsl)
2016-03-16 21:39 UTC, Alexander Diewald
Details
DV11P platform driver v3 with working resume functionality. (7.56 KB, patch)
2016-03-20 20:55 UTC, Alexander Diewald
Details | Diff
DV11P platform driver v3 with working resume functionality. (7.49 KB, patch)
2016-03-20 20:57 UTC, Alexander Diewald
Details | Diff
DV11P platform driver v3 with working resume functionality. (7.49 KB, patch)
2016-03-20 21:50 UTC, Alexander Diewald
Details | Diff
Intermediate patch enabling resume via PBTN for 4.4.X kernels. (7.88 KB, patch)
2016-03-23 07:53 UTC, Alexander Diewald
Details | Diff
Patch for mainlined driver (ACPI part) (4.48 KB, patch)
2016-12-06 08:06 UTC, Alexander Diewald
Details | Diff
Patch for mainlined driver (Platform part) (2.18 KB, patch)
2016-12-06 08:06 UTC, Alexander Diewald
Details | Diff
Dock and tablet mode detection for recent driver (1.08 KB, application/octet-stream)
2016-12-06 13:07 UTC, Jan-Michael Brummer
Details
Ignore double power release on resume (1.49 KB, application/octet-stream)
2016-12-06 14:19 UTC, Jan-Michael Brummer
Details
DSDT Dell 7140 Venue 11 Pro (565.32 KB, text/x-csrc)
2017-05-01 11:47 UTC, sac
Details

Description Jan-Michael Brummer 2015-08-05 00:18:33 UTC
Created attachment 184301 [details]
Power button handling for Dell Venue 11 Pro (7140)

Currently the power button is not handled within linux. Although it is detected as ACPI power button it does not react on pressing it.

Based on the patch for the Surface Pro 3 (https://bugzilla.kernel.org/show_bug.cgi?id=84651) i've modified it for the DV11P and it works fine for suspend. After waking the device up, it boots through the firmware/bios which is under investiagion at the moment. This seems to be another problem, unrelated to this patch.
Comment 1 Zhang Rui 2015-08-31 05:54:10 UTC
please attach the acpidump output.
Comment 2 Jan-Michael Brummer 2015-08-31 06:04:05 UTC
Created attachment 186241 [details]
acpidump of DV11P 7140
Comment 3 axfelix 2015-10-05 01:32:18 UTC
Hm, is this perhaps a regression? I have the prior year's model (I think -- 7140 is Broadwell; I have Haswell), and it's worked fine for me (including the power button; basically everything but the second camera works, and the mic is unreliable) on 3.17 and 3.18. I haven't updated beyond 3.18 because of https://bugzilla.kernel.org/show_bug.cgi?id=102281 so I'm not sure if this is a new issue.
Comment 4 Jan-Michael Brummer 2015-11-01 13:10:01 UTC
Just for the record: I've tested Fedora 21 (Kernel 3.17) with DV11P 7140. It is the same as with recent kernel, no power button press/release is recognize. Only my above patch helps.
Comment 5 Chen Yu 2015-11-01 15:29:25 UTC
Hi,Michael
do you mean, with your patch applied, after you pressed the power button, the system will fall asleep(suspend to mem)? But if you press the power button again, the system will do a fresh reboot?
Thanks
Comment 6 Jan-Michael Brummer 2015-11-01 19:59:48 UTC
Actually it is not waking up at all. I have to long-press the power button and that's why it reboots. Using my patch it at least switches into suspend (verified with journal log and manual tests).
Comment 7 axfelix 2015-11-01 23:28:47 UTC
If this is getting looked at, I'd love it if someone could also address this regression in 3.18+:

https://bugzilla.kernel.org/show_bug.cgi?id=94281
Comment 8 Jan-Michael Brummer 2015-11-02 20:45:00 UTC
After attaching a usb keyboard (or docking station) i can successfully resume the tablet after pressing a keyboard key. Pressing a tablet button still has no effect. So its the question on how to convince the kernel to accept actions in suspend.
Comment 9 Chen Yu 2015-11-03 11:55:25 UTC
1. Waking up from S3 is implemented in firmware(BIOS)->at least jumping back from S3 to the wakeup vetor address, so I think being woken up by a usb keyboard(docking station) make sense to me(I assume the BIOS is capable of detecting usb/dock event/signal)
2. The surface pro 3 button code is already in upstream kernel, you can refer to it and send a patch to pm-linux/x86-platform maillist IMO.

Yu
Comment 10 Jan-Michael Brummer 2015-11-04 21:24:22 UTC
I did a quick reinstall of Windows 8.1 in order to test the behaviour there. The power button (and the windows touch button) is always capable resuming the tablet, no matter if there is a keyboard (or dock) connected. So this is currently a bug under linux.

Please help me investigating which device is responsible for this (acpidump is attached) and why it is not triggering a resume.

In the meantime i will post my driver patch on the pm-linux maillist. Thanks.
Comment 11 Dmitry Sutyagin 2016-02-03 15:25:59 UTC
Dear all,

Can I do anything to get this merged? I own a Dell Venue 11 Pro and power button does not work for me with kernel 4.4.1, obviously because the patch provided by Jan-Michael Brummer has not been merged.
Comment 12 axfelix 2016-02-03 15:28:19 UTC
Sign up for the acpi kernel mailing list and submit it that way.
Comment 13 Dmitry Sutyagin 2016-02-08 07:20:42 UTC
axfelix,

I tried doing this:
http://www.spinics.net/lists/linux-acpi/msg63485.html
http://www.spinics.net/lists/linux-acpi/msg63489.html
but my emails have never been answered. Looks like this process is not straight forward at all, can anyone help me with this? I would like to submit a patch for both master and 4.4.1 branches - I can make the patches but how do I make them merged?
Comment 14 Jan-Michael Brummer 2016-02-08 19:24:53 UTC
Created attachment 203161 [details]
Updated driver

I've updated my driver in the mean time:
 
 - Simplified structure based on Surface Pro 3 commit
 - Added support for docking and undocking event detection and notification

Can you test it with your device please? Afterwards we can try to commit it.
Comment 15 Chen Yu 2016-02-09 04:24:43 UTC
With regard to wake up problem, is the power button wakable in /proc/wakeup?
Comment 16 Chen Yu 2016-02-09 04:29:00 UTC
BTW, the patch might be better send to platform driver list & acpi list, you can use linux/script/get_maintainers.pl to find which list to send to, and plz CCed me as well
Comment 17 Jan-Michael Brummer 2016-02-09 16:53:35 UTC
Chen,

here is my output of /proc/acpi/wakeup:

Device	S-state	  Status   Sysfs node
PEG0	  S4	*disabled
PEGP	  S4	*disabled
PEG1	  S4	*disabled
PEGP	  S4	*disabled
PEG2	  S4	*disabled
PEGP	  S4	*disabled
RP01	  S4	*disabled
PXSX	  S4	*disabled
RP02	  S4	*disabled
PXSX	  S4	*disabled
RP03	  S4	*disabled  pci:0000:00:1c.0
PXSX	  S4	*disabled  pci:0000:01:00.0
RP04	  S4	*disabled  pci:0000:00:1c.3
PXSX	  S4	*disabled  pci:0000:02:00.0
RP05	  S4	*disabled
PXSX	  S4	*disabled
RP06	  S4	*disabled
PXSX	  S4	*disabled
RP07	  S4	*disabled
PXSX	  S4	*disabled
RP08	  S4	*disabled
PXSX	  S4	*disabled
UAR1	  S3	*disabled
GLAN	  S4	*disabled
EHC1	  S0	*disabled
EHC2	  S0	*disabled
XHC	  S0	*enabled   pci:0000:00:14.0
HDEF	  S4	*disabled
LID0	  S3	*enabled   platform:PNP0C0D:00
PBTN	  S3	*enabled   platform:PNP0C0C:00
Comment 18 Dmitry Sutyagin 2016-02-09 18:01:34 UTC
Jan-Michael, Chen,

Wake up works as expected - but you need to change the sleep state - https://bbs.archlinux.org/viewtopic.php?pid=1601365#p1601365. It's just that the tablet does not support S3 and freezes instead of suspending, so you cannot wake it up normally. Same situation with Windows - if you edit the registry to allow "Sleep" and press the power button the tablet will not be able to wake up - it will only crash & reboot.

Jan-Michael, I will try to build a patched kernel with your updated patch, and see how it behaves.

BTW is there any direct use in docking-undocking - anything happens in system? Or just for potential future use for someone who'd like to bind an action to that event?
Comment 19 Jan-Michael Brummer 2016-02-09 18:19:07 UTC
Yes i'm aware of freeze and that's what i'm using. But its not possible to wake up the device with the power button, only with an attached usb keyboard.

systemd reacts on the docking changes, e.g. not suspending the device if it is docked and lid is closed.
Comment 20 Dmitry Sutyagin 2016-02-09 18:32:32 UTC
Jan,

That's interesting because in my case system reacts to power button and wakes up - at least with the original version of your patch.
Comment 21 Jan-Michael Brummer 2016-02-09 18:44:30 UTC
Indeed...

 - Which tablet do you have, 7140?
 - Which bios version, A08?
 - Which distribution?
 - Which DE, in case something is in the chain?
 - Which kernel?
 - Whats your output of /proc/acpi/wakeup?
Comment 22 Dmitry Sutyagin 2016-02-09 19:11:36 UTC
Jan,

Tablet is Dell Venue 11 Pro 7140, Core M 5Y71, 4GB RAM, 128SSD
BIOS is A07 if I am not mistaken (btw A09 is available), have not updated since A07
Distro is Arch Linux
Kernel is 4.4.1, current default in Arch Linux
I've modified your new patch to apply to 4.4.1 which I build using PKGBUILD method (https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System)
The build is currently in progress. Current kernel (without the patch) has the following output of /proc/acpi/wakeup (which looks identical to yours):

Device	S-state	  Status   Sysfs node
PEG0	  S4	*disabled
PEGP	  S4	*disabled
PEG1	  S4	*disabled
PEGP	  S4	*disabled
PEG2	  S4	*disabled
PEGP	  S4	*disabled
RP01	  S4	*disabled
PXSX	  S4	*disabled
RP02	  S4	*disabled
PXSX	  S4	*disabled
RP03	  S4	*disabled  pci:0000:00:1c.0
PXSX	  S4	*disabled  pci:0000:01:00.0
RP04	  S4	*disabled  pci:0000:00:1c.3
PXSX	  S4	*disabled  pci:0000:02:00.0
RP05	  S4	*disabled
PXSX	  S4	*disabled
RP06	  S4	*disabled
PXSX	  S4	*disabled
RP07	  S4	*disabled
PXSX	  S4	*disabled
RP08	  S4	*disabled
PXSX	  S4	*disabled
UAR1	  S3	*disabled
GLAN	  S4	*disabled
EHC1	  S0	*disabled
EHC2	  S0	*disabled
XHC	  S0	*enabled   pci:0000:00:14.0
HDEF	  S4	*disabled
LID0	  S3	*enabled   platform:PNP0C0D:00
PBTN	  S3	*enabled   platform:PNP0C0C:00
Comment 23 Dmitry Sutyagin 2016-02-09 19:31:35 UTC
The new patch does not work right for me with 4.4.1 kernel - the button press definitely gets detected because as soon as I press it the cursor in gnome-terminal changes to while and freezes, but nothing else happens except the terminal window stops responding to input for a few seconds.
Comment 24 Dmitry Sutyagin 2016-02-09 19:33:05 UTC
However I can see "systemd-logind[504]: Power key pressed." in log - maybe something wrong with my system after the recent update. Will try the older patch again to see if there is any difference.
Comment 25 Dmitry Sutyagin 2016-02-09 19:38:28 UTC
When undocking and docking with the new patch I get this in log:

undocking:
systemd-logind[504]: System undocked.
kernel: dell venue 11 pro button INT33D6:00: Unsupported event [0xcc]
kernel: dell_wmi: Unknown WMI event type 0x11: 0xfff2
kernel: acpi PNP0501:00: Still not present

docking:
systemd-logind[504]: System docked.
kernel: dell venue 11 pro button INT33D6:00: Unsupported event [0xcd]
kernel: acpi PNP0501:00: Still not present
kernel: dell_wmi: Unknown WMI event type 0x11: 0xfff3
Comment 26 Jan-Michael Brummer 2016-02-09 19:47:50 UTC
Yes, we can handle those messages too. 0xcc is most likely the release event which we can handle in my driver.

0x11 - 0xfff2 and 0xfff3 can be added to dell_wmi as undock/docking events.

Is the power button working in all situations (docked and undocked)?
Comment 27 Dmitry Sutyagin 2016-02-09 19:55:46 UTC
Yes the button works bot hwhen docked and undocked.

Ok so it was my mistake that the power button did not work - I changed sleep state in /etc/systemd/sleep.conf to "standby" just to test and forgot to change back. Now I fixed this - power button works for both suspend-to-idle and resume. However I must state that suspend and resume, at least with button, is quite unstable, and docking/undocking add to it. For example I have already experienced the following situations:

Suspend w. pbtn -> 5 sec -> resume with Win -> 5 sec -> Suspend w. pbtn = dead

Undock -> Suddenly screen goes black = dead

Suspend w. pbtn -> 5 sec. -> resume w. pbtn -> 5 sec and suddenly screen goes black without me doing anything = dead

dead = tablet vibrates when I press Win touch button on it but screen stays off
Comment 28 Dmitry Sutyagin 2016-02-10 11:38:05 UTC
UPD. If you don't rush it, it works ok.

Hm, now it stopped working for resume. I've switched from kernel 4.4.1-1 to 4.4.1-2. I'll try rebuilding again with an older source and see if there is any difference.
Comment 29 Jan-Michael Brummer 2016-02-10 22:00:08 UTC
Created attachment 203371 [details]
Updated driver v2

v2:
 - Split dock and tablet mode event handling
 - Add SW_TABLET_MODE capability
 - Clean left over button names
Comment 30 Alexander Diewald 2016-02-17 21:35:56 UTC
Hi there,

I'm also owning a Venue 7140 (with BIOS version A09).

After applying the patch to the 4.5-rc4 kernel, the power button partially works. I sets the system to S0 mode in every state. However, resuming works only partially.

Here is the behaviour that I have observed:
- With a keyboard dock, I can wake the system by pressing any key on the keyboard.
- Closing the magnetic lid (cover, keyboard, all works) allows me to "suspend" the system and to wake it up.
- Resuming with the power button only works up to 3 seconds after putting the system into "suspend".
- Changing the "docked state" (keyboard, real dock) causes the system to hang if it was in the S0 state when the event happened.

Does the x86 platform patch that was merged during the 4.5 feature window have any impact on this driver?

Anyways, I will try again with a 4.4.1 kernel and change the behaviour of the triver to wake the system on dock events. This would still better than the hang.


Last but not least, thanks for your efforts! The device is now becoming usable as a mobile device :)
Comment 31 Dmitry Sutyagin 2016-02-18 07:21:24 UTC
Alexander,

4.4.1 should give you the same results, I have it exactly the way you have described - incl. freezing when docked/undocked during S0, power button only working for 3 sec after screen goes off, etc. I tried to compile 4.1.17 with this patch but have not succeeded so far.

BTW in Windows the tablet is also prone to freeze / crash if docked or undocked during S0 - not 100% but happened to me many times.
Comment 32 Alexander Diewald 2016-02-18 18:35:07 UTC
Hi Dmitry,


thanks for your feedback. All this ACPI button seems to be under heavy development right now. Just FYI, there is aslo a patch by Chen that improves the lid handling: https://bugzilla.kernel.org/show_bug.cgi?id=89211. It should be generic such that it applies to DV11P as well.

However, after digging in the code for some, time, I see that either DSDT is somehow corrupt (although it looks fine for me). If one compares the Power Button section and the LID section, it seems fine:

Method (PPRW, 0, Serialized)
            {
                Name (EPRW, Package (0x02)
                {
                    Zero, 
                    0x03
                })
                Local0 = EEAC (0x03, Zero)
                Index (EPRW, Zero) = Local0
                Return (EPRW) /* \_SB_.PPRW.EPRW */
            }

            Device (LID0)
            {
                Name (_HID, EisaId ("PNP0C0D") /* Lid Device */)  // _HID: Hardware ID
                Method (_LID, 0, NotSerialized)  // _LID: Lid Status
                {
                    Local0 = ECG3 ()
                    Return (Local0)
                }

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (PPRW ())
                }

                Method (_PSW, 1, NotSerialized)  // _PSW: Power State Wake
                {
                    EEAC (0x02, Arg0)
                }
            }

            Device (PBTN)
            {
                Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */)  // _HID: Hardware ID
                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return (PPRW ())
                }

                Method (_PSW, 1, NotSerialized)  // _PSW: Power State Wake
                {
                    EEAC (0x02, Arg0)
                }
            }


Also, I see no difference in the acpi wakeup table comparing the LID with the power button.

So, I assume, that the interrupt vector for the button alone must be written somehow wrong? 

Also, another (related) question: is the output of /proc/acpi/wakeup just the device struct from the kernel, or are the values actually read from the firmware (did not dig deep enough in the code there yet)?

Finally, does the resume from Surface Pros (1/2/3) actually work with the power button? (Don't know if this would really help, as the SP's DSDT is quite a mess compared with the Venue's)
Comment 33 Alexander Diewald 2016-02-19 11:59:20 UTC
So, I did some more testing yesterday. Here are the results:

First, I selectively (each in the list separately) disabled HW components features in the UEFI setup screen, none helped. This is the stuff I tried:
- Disable all power management stuff (C-states, Hyperthreading) etc.
- Disabled additional HW devices (USB, sdcard etc.)
- Diasbled radio modules (WIFI, BT, etc.)

Furthermore, I have build a 4.3.3-3 kernel from the arch build system svn repository. This caused the system to crash on both freeze and suspend actions (the screen was still active during that). However this might be related to a btrfs bug that strikes on suspend (patch is referenced in the current 4.4.1-2 kernel of ARCH, don't know if it is needed for 4.3.3.).

Then, I examined the changes that were applied to the ARCH 4.4-kernel and found that the ACPI_REV_OVERRIDE setting was removed in one of the 4.4 versions. I enabled it again, and was not able to resume the system via the keyboard dock again. So, this setting correlates with our issue.

As a final note, I may add that resuming (from S3!) worked for me under my previous gentoo system that had a custom config, 4.3.5 kernel and the grsec patches applied, if and only if the system was not plugged to AC during the suspend or the resume action.

Next, I will try to boot the gentoo kernel image with Arch and test the S0 mode. Also, I will experiment with the C-State command line parameter and report back.
Comment 34 Dmitry Sutyagin 2016-03-12 06:31:07 UTC
Folks,

Any chance we get this merged? I know it does not work well in the end but I assume not because of the patch code - the same issue observed if suspend is triggered via command line, so...
Comment 35 Alexander Diewald 2016-03-16 21:35:39 UTC
Created attachment 209511 [details]
Output of grep . -r "/sys/firmware/acpi/interrupts/"
Comment 36 Alexander Diewald 2016-03-16 21:38:50 UTC
Created attachment 209521 [details]
Dmesg with "acpi.debug_layer=0xffffffff acpi.debug_level=0x4" bootline

Note: Dmesg using the version A09; contains some custom debug statements.
Comment 37 Alexander Diewald 2016-03-16 21:39:55 UTC
Created attachment 209531 [details]
Decompiled DSDT (from version A09)
Comment 38 Alexander Diewald 2016-03-16 22:24:50 UTC
Hello again,

sorry for the very long delay. I could have poseted the results from comment #33 earlier: There were none. I could not boot with the old gentoo kernel and an 4.4 arch kernel with the same config (as for the gentoo kernel) did not show any change, so a misconfiguration is not the issue here.

However, I must note that my inital observation that the lid switch is working was just wrong. It just does not resume the tablet. Likely, I trapped into the freeze delay trap.


I used the time up to now to dig deeper in the kernel code, the  ACPI spec and the DSDT and I want to share some thoughts about it - maybe one of the ACPI gurus here could give me a hint - or correct me where I draw some wrong conclusions.
In the DSDT there is a PBTN and a LID0 device, which both have a _PRW method that returns a Package (0x03, 0x08). This indicates that the GPE we are looking for has the number 0x08 (enabled before suspend). There also exists a _L08 method in the _GPE scope which calls the method EV6 with the arguments (1,1) under certain conditions. EV6(1,1) would then trigger the method BTNV(1,1) which again would notify the PBTN device.
By following the methods in the DSDT, I found that bit 1 (lowest) of the EC-device register number 9 must be 0 such that EV6(1,1) is called. In short: ECr9[0] == 0. Also the _REG method for the ECDV must be called, which is actually done by the kernel.

A second suspicious method is the method _Q66 which triggers the NEVT method calling the VGBI device that also emits the button press codes that are captured by the driver. Here, we find a similar condition (EC register 7 bit 4 must be set: ECr7[3] == 1) such that the corresponding button presses are reported. Unfortunately, I do not know if the corresponding GPE is enabled while the tablet is in sleep mode.

Unfortunately, I have not yet been able to write to these registers (have seen it in other platform drivers), nor to read from them. Also, I do not know if this path (for the EC registers) is promising at all. Could someone with more knowledge comment on this, please?

If this approach fails, I will examine the EC interrupts as described in https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips. Here, I have another question: Are those button events triggered solely via the SCI interrupt or are there more candidates?

@Dmitry: I don't know if it would make sense to add support for putting the device into sleep mode from the power button, if you are only able to wake it via a USB keyboard. Do you have some other benefit from the current version of the driver?
Comment 39 Dmitry Sutyagin 2016-03-17 12:20:53 UTC
@Alexander: initially I thought that it would make the button useable at least to turn the screen off, but yes, on second thought - if I cannot turn it back on without a usb keyboard or a dock then no real use - with a keyboard I can trigger freeze via command line, with a dock I can close the lid. I agree this needs more fixes before merging. I would be happy to help but I am not familiar with such low level kernel stuff I don't even know where to start. I thought maybe we can use SystemTap to record button presses and relevant event to see what events arrive when tablet is in freeze and button is pressed, but not sure it'll work and not sure it's easy to implement and never worked with SystemTap before so I'm not much of a help in the end...
Comment 40 Alexander Diewald 2016-03-19 14:27:31 UTC
Good news: The source of the resume problem is identified. It is the wake bit mask of GPE 96 that prevents the capability to resume from suspend. It is set to the value 70 when setting the wakeup GPEs. If I use the runtime bit mask (being 0) for this GPE, resuming works.

For a proper fix it now remains to identify why the ACPI subsystem uses this problematic bit mask. Also, I probably need to fix something in the platform driver since the device goes into freeze mode again if it is resume via the power button (This does not happen when waking the device via a usb device).

Nevertheless, this is big step forward in making the power button to operate properly :)
Comment 41 Alexander Diewald 2016-03-20 20:55:38 UTC
Created attachment 210051 [details]
DV11P platform driver v3 with working resume functionality.

For linux kernel >= 4.5.
Comment 42 Alexander Diewald 2016-03-20 20:57:01 UTC
Created attachment 210061 [details]
DV11P platform driver v3 with working resume functionality.

For linux kernel <4.5.
Comment 43 Alexander Diewald 2016-03-20 21:13:49 UTC
So, the resume is working properly now.

@Dmitry: Could you please verify if the patch is working for you as well? On my machine it operates as expected.

@Jan: If the update of the patch is fine (see details below), could you please make a proper "git patch" out of the uploaded version 3? Unfortunately, I did not setup a git clone of the kernel repo when I started working on this problem...


Technical details:
First of all, the analysis in comment #40 is wrong, it was the bit mask of GPE 8 that was wrong. I was just to stupid to read my if statements correctly :/
If the runtime bitmask is set for this GPE (0x05, instead of 0x01), the tablet is able to resume.
I have added a method which implements a callback such that the aforementioned bitmask is set. It is called whenever the tablet enters suspend/freeze mode. Therefore, I used a "ACPICA internal" method to iterate over the GPEs. Although it is now required to include some headers that are seemingly intended to be used only by the ACPI subsystem, this solution seems suitable for me. Otherwise an "interface" must be implemented in the ACPI subsystem to set the correct bitmask, or the calculation of the bitmasks must be somehow corrected. However, I did not dare to imlement the fix using these options, as I do not have enough knowledge of the ACPI kernel implementation and the high risk of introducing regressions. This should only be done by someone with more ACPI knowledge.

Furthermore, I added another boolean flag to the device structure such that an additional PBTN event is ignored during resuming. When resuming the driver gets two PBTN events: One when the suspend flag is still set (OK), and one while this flag is already cleared. The latter results in the tablet to suspend again immediately. Therefore, the requirement for the second flag.


If this implementation is fine we could consider merging this driver into mainline soon.
Comment 44 Alexander Diewald 2016-03-20 21:50:51 UTC
Created attachment 210071 [details]
DV11P platform driver v3 with working resume functionality.

Fixed malformed patch.
Comment 45 Romain Sahut 2016-03-21 15:08:11 UTC
I had to add this line in drivers/acpi/acpica/evgpeutil.c to compile the module using linux kernel 4.5 (undefined acpi_ev_walk_gpe_list error).

ACPI_EXPORT_SYMBOL(acpi_ev_walk_gpe_list)
Comment 46 Dmitry Sutyagin 2016-03-21 19:21:56 UTC
@Alexander: I used attachment 210071 [details] to patch kernel 4.4.5 - got an error about acpi_ev_walk_gpe_list just like @Romain. Applied his workaround, re-building now.
Comment 47 Dmitry Sutyagin 2016-03-21 19:36:48 UTC
Did not help, I guess I have a different error.
Here is the error - http://pastie.org/10769036
Comment 48 Jan-Michael Brummer 2016-03-21 19:45:08 UTC
Patch file is broken, just add it manually and it works. Nevertheless it is not the correct way of handling this issue. I'll try to investigate it and create a new acceptable patch.
Comment 49 Alexander Diewald 2016-03-22 08:16:01 UTC
Thanks for your feedback and sorry for the trouble! If desired, I could upload a corrected patch if needed, but I think it will be quite useless as this "fix" is not sustainable.

@Jan: I think the correct way to handle this issue would be to identify, why the "enable_for_wake" mask is read incorrectly from the tables whereas the "enable_for_run" mask is not. Somehow the references to the GPEs are not identified 100% correctly.
Also, thank you for investing time in this! My knowledge of the ACPI subsystem is too limited to provide a proper fix without breaking other stuff, as said before.


P.S: I really wonder why I did not get the error about the missing symbol export. I did a completely clean rebuild (4.4.5), and did not see this error...
And sorry again for the broken patch, I assumed this was a local error due to my editor... It would have been way smarter to setup a proper git tree in the beginning already :/
Comment 50 Dmitry Sutyagin 2016-03-22 11:29:59 UTC
@Alexander: no worries! Could you provide me with a working patch for 4.4.5? Your patch from attachment 210071 [details] applies fine but I get compilation error which you can see via the pastie link I have provided earlier. I would really love to get at least a temporary solution which works reliably, I'm fine with this being temporary/ not sustainable.
Comment 51 Alexander Diewald 2016-03-23 07:53:17 UTC
Created attachment 210311 [details]
Intermediate patch enabling resume via PBTN for 4.4.X kernels.

Corrected patch for 4.4.X kernels (Used 4.4.6, but it should apply without problems to 4.4.5 kernels). This one also includes the export_symbol fix (BTW, likely, I did not notice this issue sine I compiled the driver in the kernel, not as a module).

@Dmitry: Just FYI, the problems you mentioned earlier was due to the broken patch file which caused the file "dv11p-tablet.c" not to be written completely, some lines were missing.
Comment 52 Dmitry Sutyagin 2016-03-23 17:13:16 UTC
Used the latest patch 210311, works well! Looking forward to any news from you guys regarding a proper fix and a merge 
Comment 53 Chen Yu 2016-05-11 09:03:13 UTC
Have not seen drivers/platform/x86/dv11p-tablet.c  in upstream kernel, @Alexander Diewald @Jan-Michael Brummer  would you plan to send it to x86 platform driver mailling list? thanks.
Comment 54 Alexander Diewald 2016-06-02 18:20:04 UTC
Hi Chen,

sorry for the delayed answer. I do not have plans to send the patch as-is to the mailing list. Also, I stopped working on it, since I received no feedback for a proper solution to enable the problematic GPE before trigging the suspend.

To summarize, the current implementation of the platform driver enables GPE08 (the powerbutton/lid GPE) before going to suspend. I have done this in the platform driver to avoid side-effects on other platform drivers if enabling some wake-GPEs. However, this implementation requires exporting a subsystem-internal method to iterate over the GPEs, which, I think, breaks encapsulation.
I don't know if there is some "bug" in the mechanism that reads the ACPI tables or if some wakeup GPEs should stay enable when suspending...
Comment 55 RussianNeuroMancer 2016-06-07 10:01:46 UTC
Alexander, according to reports that I have seen in Venue 7140 discussion on 4pda, S3 and S4 is quite buggy even with Windows. It's possible that BIOS was not tested to work properly with S3/S4, because AFAIK Windows tablets use Connected Standby mode by default (and most of users doesn't disable this feature, so that mode recieve most of testing by hardware vendor).

In Linux we can use suspend into freeze mode, so power button that works with your patches is usable with freeze and very much needed for owners of this tablets who run Linux.

If possible, you could clean up your code to work properly just with freeze suspend and then submit it. Working S3/S4 would be cool, but power button that can suspend/wakeup tablet to/from freeze mode is cool too.
Comment 56 sac 2016-07-24 16:21:38 UTC
>Working S3/S4 would be cool, but power button that can suspend/wakeup tablet
>to/from freeze mode is cool too.
Indeed, most critical: if the tablet is locked, the screen is deactivated and there's no way to unlock / activate the screen again without attached keyboard, because none of the HW buttons is recognized.

Kubuntu somehow manages to handle this. Hibernate and Standby work there in 16.04.1, however Fedora and all others currently have to be setup to only deactivate the monitor at the same time when it should enter standby. Then /etc/systemd/sleep.conf has to be adjusted to "[Sleep] SuspendState=freeze", then one can even close the lid of the attached slim keyboard and is able to activate it again via long push of the PBT.

What I want to say: if there is any possibility to implement this patch now in upstream, we should proceed. S3/S4 can be commented out (and possibly enabled via later update), although I read many successful reports using it as is ( http://en.community.dell.com/support-forums/mobile-devices/f/4586/t/19678425?pi41117=2 ). 

"which, I think, breaks encapsulation."
Are there any known issues that declares this as a showstopper?
Comment 57 sac 2016-07-25 10:16:05 UTC
Can someone forward this to the Linux ACPI mailing list https://patchwork.kernel.org/project/linux-acpi/list/ if Chen is not available?
Comment 58 sac 2016-07-25 13:04:54 UTC
BTW: If this is about
"for (i = 0; i < gpe_block->register_count; i++) {"

According to https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips & http://kernel.ubuntu.com/%7Ecking/presentations/gpes-and-embedded-controller/EmbeddedControllerAndACPI.odp this is INDEED the best practice:
"Wiggle hardware, look for a GPE count count, e.g. Lid up/down, cat /sys/firmware/acpi/interrupts/gpe* to see which GPE count changes"
Comment 59 Jan-Michael Brummer 2016-07-27 20:05:11 UTC
Quick note: There is a new intel virtual button driver which offers support for our powerbutton. But it has the same issues as my driver...

http://lkml.iu.edu/hypermail/linux/kernel/1607.3/01919.html
Comment 60 RussianNeuroMancer 2016-07-29 16:08:39 UTC
> it has the same issues as my driver...
But will it allow to at least wakeup tablet from suspend freeze state?
Comment 61 sac 2016-08-01 20:10:38 UTC
>> it has the same issues as my driver...
Well, of course it has.

OK, I think I found the reason for these "strange behavior". Seems the driver is good, but the HW is good as well. It's not a bug, it's a feature (according to Microsoft & Intel): Connected Standby.
http://mobilitydigest.com/connected-standby-be-damned-a-sort-of-workaround/

It replaces the PC power states S0-S4 to create some mobile phone behavior, where the device wakes up from time to time to check mails, etc.. It should enter "connected standby" when the screen is turned off, but it should also sleep when the device is put into "airplane mode" and then sleep.

I don't like it, but it seems that we're not getting around this. It will consume 1% battery per hour in connected standyb, overall lasting 4d in this mode.

I tested the latest Kernel (github.com/torvalds/linux.git) today and the Intel virtual button driver was not working for me. Please submit the driver within this weeks merge window for 4.8. Certainly, it will not get any better.
Comment 62 sac 2016-08-02 01:04:32 UTC
All supported power states (p. 44; S0 (freeze - Connected Standby), S3 Cold (sleep - Suspend to RAM), S4 (hibernate - Suspend to Disk), S5 (Soft Off)):
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/5th-gen-core-family-datasheet-vol-1.pdf
Comment 63 sac 2016-08-02 02:11:04 UTC
Last update for today:
>If the runtime bitmask is set for this GPE (0x05, instead of 0x01), the tablet
>is able to resume.

All GPE / GPIs are described in detail on http://www.intel.com/content/www/us/en/processors/core/5th-gen-core-family-platform-i-o-datasheet.html

GPI        Power Well    Wake From     Notes
GPI[7:0]   Core          S1            ACPI Compliant
GPI[15:8]  Suspend       S1 – S5       ACPI Compliant
Comment 65 Zhang Rui 2016-08-08 13:41:28 UTC
*** Bug 150701 has been marked as a duplicate of this bug. ***
Comment 66 RussianNeuroMancer 2016-08-13 22:08:35 UTC
[   71.691528] intel_vbtn: module verification failed: signature and/or required key missing - tainting kernel
[   71.692479] input: Intel Virtual Button driver as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input14

intel-vbtn is detecting button, so seems like powerbutton is supported now. But pressing button while suspend freeze doesn't wake up tablet.

p.s. By the way, what can be done to enable wakeup via Home button? Is it configurable via something (logind maybe?) or changes on kernel level is required to make it work?
Comment 67 Zhang Rui 2016-08-15 06:37:25 UTC
*** Bug 150701 has been marked as a duplicate of this bug. ***
Comment 68 Alexander Diewald 2016-09-18 19:03:07 UTC
FYI, I have made a cleaner implementation of the GPE fix. Therefore, I created an interface to set the mask for single GPEs from other drivers. The suspend hook is basically the same. On my machine, it works absolutely fine.

The patch based on the other driver has just been sent to the linux-acpi mailing list.
Comment 69 RussianNeuroMancer 2016-09-19 07:00:20 UTC
Alexander, by any chance do you have this issue with suspend freeze?
https://bugzilla.kernel.org/show_bug.cgi?id=153101
Comment 70 Alexander Diewald 2016-09-19 07:05:18 UTC
Nope, but I also disabled suspend actions in systemd since they interfere with the ones from the desktop manager. In my setup that's gnome's power manager.
Comment 71 RussianNeuroMancer 2016-09-28 16:30:02 UTC
Alexander, I testing kernel with your patches. Seems like powerbutton have same issue as volume buttons - as you probably noticed one push on volume buttons generate two volume up or volume down actions. 
Looks like one push on powerbutton generate two actions too. With enabled systemd suspend actions my tablet suspend after wake up. 

Moreover, when tablet is suspended, I can press powerbutton, but instead of releasing finger from powerbutton, I may hold it, then tablet WILL NOT suspend UNTIL I RELEASE FINGER FROM BUTTON. When I release finger from button tablet will suspend again. If I didn't release finger from button, ten seconds later it get power down, as usually.
Comment 72 Alexander Diewald 2016-09-28 16:44:41 UTC
I have the issue with the volume button, but not with the suspend button. Please check if your display manager interfers with systemd.
Please report this issue to the maintainer of the mainlined platform driver patch. For me, this is not directly related to getting the suspend functionality working since it is a problem combined with the ACPI subsystem and the platform driver. The issue you are describing is soey related to the platform driver.

@Chen Yu: Do you have some spare time or know someone (maybe from intel) to take a look this one: http://www.spinics.net/lists/linux-acpi/msg69270.html ?
Comment 73 RussianNeuroMancer 2016-09-28 17:08:16 UTC
> Please check if your display manager interfers with systemd.
I tried to disable reaction on power/suspend buttons in Gnome Shell by changing button-power/button-hibernate/button-sleep/button-suspend to 'nothing' but tablet still suspend as soon as I release finger from powerbutton. 
I could try configure this other way, as you do, but how to disable suspend actions in systemd? (I search for info about this, tried to edit logind.conf, reboot, no changes, so probably it should be done some other way.) Any how intel-vbtn is recognized by Gnome's power management, as power button or as suspend button?

> Please report this issue to the maintainer of the mainlined platform driver
> patch. 
You mean intel-vbtn or something different?

> For me, this is not directly related to getting the suspend functionality
> working 
Suspend and wake up via keyboard works now without issues, thanks!
Comment 74 Alexander Diewald 2016-10-01 13:16:53 UTC
@Chen Yu: Please forget my request for the review for now, @RussianNeuroMancer contacted the developer of the mainlined platform driver for a review of the ACPI patch. I was not in the loop about this, so I am sorry if it caused any overhead for you.

@RussianNeuroMancer:
The power button is AFAIK  recognized as a power button, but I may be wrong. For the other bug (keypresses are regognized twice) there must be a change done in the platform driver such that either only actions on presses or releases must be triggered. It is a general behaviour that happens for all kinds of keypresses handled by the intel-vbtn driver. The original driver had this feature. I will implement this in a separate patch at some point in time, but I do not consider it directly related to the issue mentioned here.
Comment 75 Lv Zheng 2016-12-06 02:48:38 UTC
(In reply to RussianNeuroMancer from comment #71)
> Alexander, I testing kernel with your patches. Seems like powerbutton have
> same issue as volume buttons - as you probably noticed one push on volume
> buttons generate two volume up or volume down actions. 
> Looks like one push on powerbutton generate two actions too. With enabled
> systemd suspend actions my tablet suspend after wake up. 
> 
> Moreover, when tablet is suspended, I can press powerbutton, but instead of
> releasing finger from powerbutton, I may hold it, then tablet WILL NOT
> suspend UNTIL I RELEASE FINGER FROM BUTTON. When I release finger from
> button tablet will suspend again. If I didn't release finger from button,
> ten seconds later it get power down, as usually.

You issue sounds like that the vbtn driver is not able to distinguish release/press.
Let me re-assign this bug to a new category.
Comment 76 Lv Zheng 2016-12-06 02:59:49 UTC
(In reply to Dmitry Sutyagin from comment #13)
> axfelix,
> 
> I tried doing this:
> http://www.spinics.net/lists/linux-acpi/msg63485.html
> http://www.spinics.net/lists/linux-acpi/msg63489.html
> but my emails have never been answered. Looks like this process is not
> straight forward at all, can anyone help me with this? I would like to
> submit a patch for both master and 4.4.1 branches - I can make the patches
> but how do I make them merged?

+ACPI_MODULE_NAME("dv11p power button");
+
+#define _COMPONENT              ACPI_BUTTON_COMPONENT

+	ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+			"%s [%s]\n", name, acpi_device_bid(device)));

Shouldn't be used outside of ACPICA.
It's determined to be ACPICA internal mechanism.
We have dynamic debugging for Linux.
Comment 77 Alexander Diewald 2016-12-06 08:05:04 UTC
@Lv: Thanks for looking into this again.

I am currently in contact with AceLan Kao who wrote the intel virtual button platform driver that has been mainlined. Thanks toi the support of him I created two patches that probably sacrifices the quality criteria for kernel patches.

NOTE: This patch set is WIP and currently only works for the DV11P. The platform protion seems to be device specific and I am investigating support for the Dell XPS 2016 such that AceLan can verify the approach for this device.

The patch itself is split into two parts:
- ACPI: Adds support to set the required wake mask for power button GPE.
- Platform: Set the correct wake mask for DV11P's power button.

NOTE 2: The previously described wakeup issue rarely occurs when usking wayland, it is mainly an issue with Xorg. I would treat this issue separately to not complicaate thing further. A possible way to solve this issue has been outlined in Jan's patch.
Comment 78 Alexander Diewald 2016-12-06 08:06:19 UTC
Created attachment 246951 [details]
Patch for mainlined driver (ACPI part)
Comment 79 Alexander Diewald 2016-12-06 08:06:52 UTC
Created attachment 246961 [details]
Patch for mainlined driver (Platform part)
Comment 80 Jan-Michael Brummer 2016-12-06 08:21:15 UTC
Are you planing to add my support for sw_dock/tablet as well? Or do you need a patch?
Comment 81 Alexander Diewald 2016-12-06 08:31:38 UTC
Not for this patch set as-is, but we could add the support with an additional patch/commit. I think it is a valuable feature that should be added to the plaform driver in the next iteration when also the "double suspend" would be tackled (actually, this is just an adaptation of your code to the mainlined driver). Do you agree?

If you have time for this, please feel free to create the adapted patch. Otherwise, I could to do it within the next 3 to 4 weeks. Please notify me which option you prefer.
Comment 82 RussianNeuroMancer 2016-12-06 10:16:31 UTC
Alexander, I am glad to let you know that with your patches suspend/wakeup by Dell's folio cover works without "double suspend" issue.
Comment 83 Jan-Michael Brummer 2016-12-06 13:07:10 UTC
Created attachment 247001 [details]
Dock and tablet mode detection for recent driver
Comment 84 Jan-Michael Brummer 2016-12-06 14:19:03 UTC
Created attachment 247011 [details]
Ignore double power release on resume
Comment 85 Lv Zheng 2016-12-08 02:26:31 UTC
(In reply to Alexander Diewald from comment #78)
> Created attachment 246951 [details]
> Patch for mainlined driver (ACPI part)

I have filed an ACPICA bug here:
http://bugs.acpica.org/show_bug.cgi?id=1337

So I'll leave this discussion as platform specific.
We can track the patch there.

Thanks
Lv
Comment 86 Lv Zheng 2016-12-12 07:27:57 UTC
(In reply to Alexander Diewald from comment #79)
> Created attachment 246961 [details]
> Patch for mainlined driver (Platform part)

BTW, how do you figure this out?
#define PWR_BTN_GPE				8
#define PWR_BTN_WAKE_MASK		5
 
Thanks
Comment 87 Alexander Diewald 2016-12-12 07:54:15 UTC
Basically by reading the DSDT. Starting from the PBTN method, i had to follow all the function calls to see which GPE(s) potentially trigger this method: GPE 8 was left. The wake mask was then easliy determined by placing a print method in the corresponding ACPICA function.

Before doing that, I called "enable_all_runtime_GPEs" in the suspend hook to verfiy that the wake masks were not correct (I suspected this already from reading the DSDT).
Comment 88 Zhang Rui 2016-12-22 02:07:17 UTC
*** Bug 153101 has been marked as a duplicate of this bug. ***
Comment 89 sac 2017-01-28 10:15:32 UTC
Any idea when this is going to land and can be tested?
Comment 90 sac 2017-04-30 10:39:32 UTC
@Lv
related spec seems to be stucked ( http://bugs.acpica.org/show_bug.cgi?id=1337 ). I thought this is also needed for all new generation tablet (Surface 4, Thinkpads...). Anything we can help with or any chance to implement a workaround in the kernel, until the spec is signed?
Comment 91 RussianNeuroMancer 2017-04-30 20:17:54 UTC
Try latest six patches here: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=s2idle-dell-test

But pay attention to _DSM UUID. In this patches UUID is c4eb40a0-6cd2-11e2-bcfd-0800200c9a66, which is works for me on Dell 9250 (now tablet can suspend and wakeup from S0i3 by lid events, because UUID is the same) but for Dell 7140 you probably will need to change it to (b8febfe0-baf8-454b-aecd-49fb91137b21 (check  this in dsdt.dsl). When you will update UUID in upep_dsm_uuid please note that some values are reverse: 

/* uPEP device _DSM UUID: c4eb40a0-6cd2-11e2-bcfd-0800200c9a66 */
static const u8 upep_dsm_uuid[16] = {
       0xa0, 0x40, 0xeb, 0xc4, 0xd2, 0x6c, 0xe2, 0x11,
       0xbc, 0xfd, 0x08, 0x00, 0x20, 0x0c, 0x9a, 0x66
};
Comment 92 sac 2017-05-01 11:47:11 UTC
Created attachment 256153 [details]
DSDT Dell 7140 Venue 11 Pro

Pretty cool, thx. However, not sure about the UUID. Attached is my DSDT.dsl from my Dell 7140 (Venue 11 Pro), both UUIDs are listed. Can I use the patches directly?

c4eb40a0-6cd2-11e2-bcfd-0800200c9a66
b8febfe0-baf8-454b-aecd-49fb91137b21
Comment 93 RussianNeuroMancer 2017-05-01 15:11:38 UTC
Try as is then, and if it doesn't work - try to change UUID in patch.
Comment 94 Lv Zheng 2017-05-04 07:34:21 UTC
sac:

@Lv: related spec...

Sorry I didn't notice your request.
This bug has already been marked as platform specific, thus it's not on my radar. And it's finally platform specific.

I think Dell is not using the expected way to specify a wake capable GPE.
See surface pro, its EC GPE is marked in this way:
                    Device (LID0)
                    {
                        Name (_HID, EisaId ("PNP0C0D"))  // _HID: Hardware ID
                        ...
                        Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
                        {
                            0x38, 
                            0x03
                        })
                    }                    Device (EC0)
                    {
                        Name (_HID, EisaId ("PNP0C09"))  // _HID: Hardware ID
                        ...
                        Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
                        {
                            0x38, 
                            0x03
                        })
                        ...
                        Name (_GPE, 0x38)  // _GPE: General Purpose Events
                        ...
                    }
It contains a _PRW, which correctly marks the GPE as wake capable.
And linux has no problem to handle such platform.

If Linux unconditionally marks EC GPE as wake capable.
I'm afraid many platforms will no longer be able to enter S3.

Thanks and best regards
Lv
Comment 95 sac 2017-05-04 20:36:20 UTC
@Lv,RussianNeuroMancer:
>And it's finally platform specific.
JFYI, the patches didn't work for my Dell 7140, with neither UUID. Tested with patched 4.11 Stable Mainline, but there was no difference in behavior compared to original Mainline 4.10:
Tablet goes to sleep in Kubuntu, when the lid is closed. It will only wake up if the power button is pressed (no wakeup from touchscreen, touchpad, keyboard, "windows" screen button or volume keys). Unfortunately, I can only provide this test result :(
Comment 96 RussianNeuroMancer 2017-05-04 22:31:29 UTC
What is content of /sys/power/mem_sleep on your tablet? If [deep], then try to echo s2idle to mem_sleep.
Comment 97 axfelix 2017-05-04 22:36:02 UTC
At the risk of cluttering up this thread, did anything relevant get merged around 4.8?

I'm still running a 4.7.xx kernel on my Venue 11 Pro 7130 (the prior year's Haswell model) because resume-from-suspend stopped working reliably when opening the lid (with the keyboard cover attached) in 4.8.
Comment 98 RussianNeuroMancer 2017-05-04 22:47:48 UTC
Your issue is different. Re-check resume from suspend with 4.11.0 and if it will be still reproducibe - then fill separate bugreport.
Comment 99 sac 2017-05-05 22:16:34 UTC
@RussianNeuroMancer:
Yes, it was [deep]. However, unfortunately still no difference between 4.11.0 (patches with 
c4eb40a0-6cd2-11e2-bcfd-0800200c9a66 / b8febfe0-baf8-454b-aecd-49fb91137b21) and Kubuuntu 4.10.0.19 after "echo s2idle > /sys/power/mem_sleep". Cannot wakeup the Dell 7140. Maybe someone else has more success with other Dell models.
Comment 100 RussianNeuroMancer 2017-05-06 00:22:12 UTC
@sac, just to be sure, could you please publish your static const u8 upep_dsm_uuid with b8febfe0-baf8-454b-aecd-49fb91137b21 UUID?
Comment 101 sac 2017-05-06 09:08:52 UTC
@RussianNeuroMancer
Honestly,I already deleted the patch files, but I used a calculation like following, in "ACPI / sleep: EC-based wakeup from suspend-to-idle on Dell systems" (some patches were applied with fuzz):

/* uPEP device _DSM UUID: c4eb40a0-6cd2-11e2-bcfd-0800200c9a66 */
/* uPEP device _DSM UUID: b8febfe0-baf8-454b-aecd-49fb91137b21 */
static const u8 upep_dsm_uuid[16] = {
	0xe0, 0xbf, 0xfe, 0xb8, 0xf8, 0xba, 0x4b, 0x45,
	0xae, 0xcd, 0x49, 0xfb, 0x91, 0x13, 0x7b, 0x21
};
Comment 102 RussianNeuroMancer 2017-05-06 10:10:59 UTC
Ok, that was correct then.
Comment 103 Andrew Charnley 2017-08-13 16:35:41 UTC
Dell 5175 user here (essentially the same as the Venue 11 with a few updates) and in Fedora 26 I have the same issue with the power button. dmesg reports:

890.601021] intel-hid INT33D5:00: unknown event 0xce
[  890.821635] intel-hid INT33D5:00: unknown event 0xcf
Comment 104 Jérôme de Bretagne 2017-09-08 20:32:15 UTC
@Andrew
Your situation is expected to improve within Linux 4.14 hopefully, following this recent pull request: https://lkml.org/lkml/2017/9/4/463 and in particular this patch from Rafael J. Wysocki:
platform/x86: intel-hid: Wake up Dell Latitude 7275 from suspend-to-idle

This should handle your wakeup scenario as in fact, the fix is not specific to a given device model as you can see in the patch itself:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=635173a17b0323c28a39fb06fa36d876035cd2b9


I haven't see recent discussions since then, about how to fix the other half of the issue which is triggering the suspend. For reference, the above improvement was discussed and the patch checked in this other thread:

https://bugzilla.kernel.org/show_bug.cgi?id=196115#c4
Comment 105 RussianNeuroMancer 2017-09-11 21:27:08 UTC
@Jérôme 

> This should handle your wakeup scenario as in fact, the fix is not specific
> to a given device model as you can see in the patch itself

If this patch is sufficient, I tested it on top of 4.13.1, and tablet does not wakeup from suspend by pressing power button or opening folio cover. 

> I haven't see recent discussions since then, about how to fix the other half
> of the issue which is triggering the suspend.

Suspend to idle works just fine, see Comment 19 (still works, with Linux 4.13.1 too). What doesn't work is wakeup. If you are interested in looking into this issue, please check Comment 78. Patches from Comment 83 probably was covered by https://github.com/torvalds/linux/commit/c801603e6d0c1bf87930402462d2e4185b1e9264 and https://github.com/torvalds/linux/commit/91f9e850d465147197280cbeaf51d3fb51f61ca0 (besides docking/undocking part).

@Alexander Diewald
Is it possible to refresh your patches to make wakeup work with Linux 4.13? Your patches is apply clearly but tablet doesn't wakeup by power button (with patched Linux 4.10 wakeup works).
Comment 106 Jérôme de Bretagne 2017-09-11 22:00:19 UTC
@RussianNeuroMancer

I was replying @Andrew who was bringing some specific and different symptoms (intel-hid INT33D5:00: unknown event 0xce/0xcf) as those should be fixed for his Dell 5175 model with the same patches as the ones working on the Latitude 7275.

Sorry if I created some confusion as I didn't want to imply that this was also going to fix the issues raised on the 7140 and the main focus of this thread.
Comment 107 RussianNeuroMancer 2018-02-01 07:30:20 UTC
@Lv Zheng 
@Zhang Rui 

What info is needed to continue?
Comment 108 RussianNeuroMancer 2018-04-16 04:44:56 UTC
Power button is detected and handled correctly since Linux 4.17rc1.
Comment 109 Tristian Celestin 2018-04-22 22:59:59 UTC
Do you mean that the power button initiates and resumes from s2idle, or from S3 suspend?
Comment 110 RussianNeuroMancer 2018-04-23 03:33:47 UTC
> Do you mean that the power button initiates and resumes from s2idle, or from
> S3 suspend?

Power button can resume and suspend to and from s2idle. On a side note, S3 is broken even with preinstalled OS as per Comment 18, Comment 55 and Comment 56, so AFAIK no one expect it to work properly on Dell Venue 11 Pro 7140.
Comment 111 RussianNeuroMancer 2018-10-19 12:01:09 UTC
Is anyone else observe same behaviour with Linux 4.18?

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

Note You need to log in before you can comment on or make changes to this bug.