Bug 102281
|
Description
Jan-Michael Brummer
2015-08-05 00:18:33 UTC
please attach the acpidump output. Created attachment 186241 [details]
acpidump of DV11P 7140
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. 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. 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 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). 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 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. 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 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. 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. Sign up for the acpi kernel mailing list and submit it that way. 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? 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.
With regard to wake up problem, is the power button wakable in /proc/wakeup? 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 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 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? 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. 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. 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? 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 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. 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. 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 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)? 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 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. 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
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 :) 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. 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) 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. 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... Created attachment 209511 [details]
Output of grep . -r "/sys/firmware/acpi/interrupts/"
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.
Created attachment 209531 [details]
Decompiled DSDT (from version A09)
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? @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... 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 :) Created attachment 210051 [details]
DV11P platform driver v3 with working resume functionality.
For linux kernel >= 4.5.
Created attachment 210061 [details]
DV11P platform driver v3 with working resume functionality.
For linux kernel <4.5.
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. Created attachment 210071 [details]
DV11P platform driver v3 with working resume functionality.
Fixed malformed patch.
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) @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.
Did not help, I guess I have a different error. Here is the error - http://pastie.org/10769036 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. 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 :/ @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.
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.
Used the latest patch 210311, works well! Looking forward to any news from you guys regarding a proper fix and a merge 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. 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... 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. >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? Can someone forward this to the Linux ACPI mailing list https://patchwork.kernel.org/project/linux-acpi/list/ if Chen is not available? 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"
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 > it has the same issues as my driver...
But will it allow to at least wakeup tablet from suspend freeze state?
>> 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. 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 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 *** Bug 150701 has been marked as a duplicate of this bug. *** [ 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? *** Bug 150701 has been marked as a duplicate of this bug. *** 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. Alexander, by any chance do you have this issue with suspend freeze? https://bugzilla.kernel.org/show_bug.cgi?id=153101 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. 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. 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 ? > 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! @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. (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. (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. @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. Created attachment 246951 [details]
Patch for mainlined driver (ACPI part)
Created attachment 246961 [details]
Patch for mainlined driver (Platform part)
Are you planing to add my support for sw_dock/tablet as well? Or do you need a patch? 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. Alexander, I am glad to let you know that with your patches suspend/wakeup by Dell's folio cover works without "double suspend" issue. Created attachment 247001 [details]
Dock and tablet mode detection for recent driver
Created attachment 247011 [details]
Ignore double power release on resume
(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 (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 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). *** Bug 153101 has been marked as a duplicate of this bug. *** Any idea when this is going to land and can be tested? @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? 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 }; 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
Try as is then, and if it doesn't work - try to change UUID in patch. 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
@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 :(
What is content of /sys/power/mem_sleep on your tablet? If [deep], then try to echo s2idle to mem_sleep. 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. Your issue is different. Re-check resume from suspend with 4.11.0 and if it will be still reproducibe - then fill separate bugreport. @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. @sac, just to be sure, could you please publish your static const u8 upep_dsm_uuid with b8febfe0-baf8-454b-aecd-49fb91137b21 UUID? @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
};
Ok, that was correct then. 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 @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 @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). @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. @Lv Zheng @Zhang Rui What info is needed to continue? Power button is detected and handled correctly since Linux 4.17rc1. Do you mean that the power button initiates and resumes from s2idle, or from S3 suspend? > 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. Is anyone else observe same behaviour with Linux 4.18? https://bugzilla.kernel.org/show_bug.cgi?id=201469 |