Bug 2014261 - Powerprofile ‘performance’ is inhibited by ‘lap-detected’ if ThinkPad is tilted on a desktop-stand
Summary: Powerprofile ‘performance’ is inhibited by ‘lap-detected’ if ThinkPad is tilt...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: power-profiles-daemon
Version: 34
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-14 18:18 UTC by Armin Warda
Modified: 2022-06-07 20:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-07 20:09:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Armin Warda 2021-10-14 18:18:41 UTC
Description of problem:

fedora 34 Silverblue on a lenovo ThinkPad X1 Carbon, which resides on a desktop-stand, tilted by ~30 degrees: I would like to permanently switch to the ‘performance’ power profile while the ThinkPad is on the desktop-stand in a tilted position. Gnome settings does not allow to select the 'performance' profile. I can force a switch to the 'performance' profile by exeuting the following command twice:

  echo performance > /sys/firmware/acpi/platform_profile

But after a few minutes it switches back to ‘balanced’.

Version-Release number of selected component (if applicable):

fedora 34 silverblue Version: 34.20211013.0 BaseCommit 153d*9221
Layered Package power-profiles-daemon-0.8.1-1.fc34.x86_64

How reproducible:

Put ThinkPad in a tilted position and try to select the 'performance' profile. Check the current profile after a few minutes.

Steps to Reproduce:

1. put Thinkpad on the flat desktop
2. powerprofilesctl # check current profile
3. echo performance > /sys/firmware/acpi/platform_profile
4. powerprofilesctl # check current profile, should be 'performance'
5. wait a few minutes
6. powerprofilesctl # check current profile, should still be 'performance'

7. put Thinkpad on the desktop-stand in a tilted position, e.g. 30 degrees
8. powerprofilesctl # check current profile, will be 'balanced' and 'performance' is 'inhibited (lap-detected)'
9. echo performance > /sys/firmware/acpi/platform_profile # will not switch
10. powerprofilesctl # check current profile, will still be 'balanced' and 'performance' is 'inhibited (lap-detected)'
11. echo performance > /sys/firmware/acpi/platform_profile # will switch
12. powerprofilesctl # check current profile, will now be 'performance' despite 'performance' is 'inhibited (lap-detected)'
13. wait a few minutes
14. powerprofilesctl # check current profile, will again be 'balanced' and 'performance' is 'inhibited (lap-detected)'

Actual results:

When the ThinkPad is in a tilted position, e.g. 30 degrees, the 'performance' profile will be 'Inhibited' with reason 'lap-detected'.

Expected results:

It should be possible to select and stay in the 'performance' profile if the ThinkPad sits *motionless* in a tilted position, e.g. on a desktop-stand.

Additional info:

I suspect, that the ‘lap-detected’ inhibitor might be accidentally triggered by having the ThinkPad in a tilted position (by some acceleration sensors?) on the desktop-stand: if I put it flat on the desktop surface, the ‘inhibited yes (lap-detected)’ changes to ‘no’ after a while (minutes). If I then put it back to the tilted position on the desktop-stand, the ‘inhibited’ immediately changes back to ‘yes (lap-detected)’ and the power profile switches back from ‘performance’ to ‘balanced’.

Comment 1 Bastien Nocera 2021-10-14 20:02:34 UTC
power-profiles-daemon isn't where the lap detection is made. It's made in the firmware, and power-profiles-daemon or the kernel have no control over how it's done.
At least the version of power-profiles-daemon in F35 won't change the profile when the lap is detected, just show a message in powerprofilesctl or the Power panel.

Your best bet for getting this problem looked at would be to file a bug at https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers under "Platform_x86" as a component, and mentioning "thinkpad_acpi" in the summary.
Mark, Hans, is it correct to say that's still the preferred way to report firmware bugs?

Comment 2 Mark Pearson 2021-10-15 18:53:11 UTC
I have a sneaking suspicion that @armin.warda@redhat.com might be SOL on this one.
The laptop sensor setting is just reporting the status of the laptop sensor - I don't think FW particularly gets involved in the degress the platform is set at.

I've created an internal ticket to confirm with the firmware/hardware team (for my reference LO-1393). Nag me if I don't update by end of next week.

For issues like this - I don't really mind where the original bug comes from. If we had an external facing Lenovo ticket system that would be nice...but we don't.

Mark

Comment 3 Mark Pearson 2021-10-15 19:34:23 UTC
Sadly Outta Luck

Comment 4 Timothée Ravier 2021-10-19 08:55:57 UTC
Is there any specific reason this bug is restricted to the Fedora contrib private group?

Comment 5 Armin Warda 2021-10-19 09:19:06 UTC
Sorry, I have no idea why this bug is in the fedora_contrib_private group, and I don't know how I can remove the group from the bug. Any idea? A.

Comment 6 Hans de Goede 2021-10-19 09:44:17 UTC
(In reply to Armin Warda from comment #5)
> Sorry, I have no idea why this bug is in the fedora_contrib_private group,
> and I don't know how I can remove the group from the bug. Any idea? A.

There is a groups list on the right of the comments, active groups on the list have a [x] next to them to remove them, if all groups are removed then the bug becomes public.

I've removed the fedora_contrib_private group now.

Comment 7 Hans de Goede 2021-10-19 09:45:02 UTC
Oh, I just notice this is under "Advanced fields" so you need to show those first.

Comment 8 Armin Warda 2021-10-19 10:24:11 UTC
Thanks, Hans, for removing the "fedora_contrib_private" group from this bug report.

Yes, I saw this under the "advanced fields", but for me it showed no [x] next to the group name, thus I was not able to remove it. I was able to add and remove another group, e.g. "security", but not the "fedora_contrib_private" group.

regards, Armin.

Comment 9 Mark Pearson 2021-12-02 16:05:18 UTC
I got an update on this:

---	
If user doesn't move system for 270 sec, then lapmode will be undetected as "cql" flag will be disabled as per our implementation. I don't know whether the machine is really stable or not. But if the machine is very stable, CQL should be disabled after 270 sec.  So, this looks to me as unexpected behavior .
---

Armin - are you seeing the lapmode sensor still set after 270s?
I sort of tested this: With a X1C9 I triggered the lapmode sensor, propped it up on a roll of packing tape (classy I know) and waited - and the sensor cleared

Mark

Comment 10 Armin Warda 2021-12-02 17:28:21 UTC
Yes, Mark, I still see this. 

"Lap detected: performance mode temporarily unavailable. Move the device to a stable surface to restore" is reported by Gnome Settings > Power > Power Mode. But now, after I rebased to f35 Silverblue with Gnome 41, the Power Mode remains in "Performance" and is not switched to "Balanced", like when I was still on f34 Silverblue with Gnome 40.

awarda@fedora:~$ powerprofilesctl 
* performance:
    Driver:     platform_profile
    Degraded:   yes (lap-detected)

  balanced:
    Driver:     platform_profile

  power-saver:
    Driver:     platform_profile

The message is also shown when I switch to "Balanced":

awarda@fedora:~$ powerprofilesctl 
  performance:
    Driver:     platform_profile
    Degraded:   yes (lap-detected)

* balanced:
    Driver:     platform_profile

  power-saver:
    Driver:     platform_profile

The ThinkPad is on a very solid, rigid stand, very stable, not moving or shaking. I would guess the body of the ThinkPad is at an angle of 30-45 degrees tilted to me, while the lid with the display is almost vertical.

Could it be that this is neither a SW or FW issue, but simply that the acceleration sensor HW of my ThinkPad is defective?

Armin.

Comment 11 Mark Pearson 2021-12-02 18:58:57 UTC
> Could it be that this is neither a SW or FW issue, but simply that the acceleration sensor HW of my ThinkPad is defective?

I'm wondering that too - but that should be easily proven by putting it on a desk flat for 5 mins.

Just to rule out it being a Gnome bug - can you do:
   cat /sys/devices/platform/thinkpad_acpi/dytc_lapmode
As this returns the sensor status

I'll check with the FW team if there's any other ideas of what might be causing it.

Thanks
Mark

Comment 12 Armin Warda 2021-12-03 08:15:05 UTC
I took the ThinkPad from the tilted laptop stand and put it flat on the table. Then I observed /sys/devices/platform/thinkpad_acpi/dytc_lapmode and powerprofilesctl with the "watch -d" command

After ~6min30s the /sys/devices/platform/thinkpad_acpi/dytc_lapmode changed from 1 to 0 and "Degraded" changed from "yes (lap-detected)" to "no":

awarda@fedora:~$ powerprofilesctl 
* performance:
    Driver:     platform_profile
    Degraded:   no

  balanced:
    Driver:     platform_profile

  power-saver:
    Driver:     platform_profile

What does this tell us regarding the acceleration sensor HW, the FW or SW?

Best regards
Armin.

Comment 13 Mark Pearson 2021-12-03 15:04:52 UTC
Hi Armin,

Well that confirms the sensor and the FW are working I'm afraid.

When the system is on it's stand are you interacting with it (keyboard/mouse/touchscreen) or is it just sitting there? Is it possible to leave it on the stand completely untouched so we're sure that it's not small movements that are triggering it?

I'll see if there are any other suggestions from the FW team.

Thanks
Mark

Comment 14 Armin Warda 2021-12-03 15:15:37 UTC
Yes, the Thinkpad is completely solid, untouched on the stand. 

I am not typing on the ThinkPad, I use a wireless keyboard and mouse. The table is not shaking or vibrating. The only physical interaction with the ThinkPad is touching the fingerprint sensor (unlock the screen and sudo) or yubikey (2FA), but that happens only maybe 3-5x per day. 

Armin.

Comment 15 Ben Cotton 2022-05-12 15:00:15 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 16 Ben Cotton 2022-06-07 20:09:16 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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