The X1 Yoga is a convertible laptop which can be opened 360° to convert it into tablet mode. On windows the laptop will ask to switch into tablet mode after opening it slightly more than 180°. This is a sensible behaviour as the keyboard is disabled at that point and the laptop touchpad will be usually be opened between 270°-360° with the touchpad facing either the table or e.g. a hand. We do already have an implementation in the kernel to expose an SW_TABLET_MODE switch (which will be used to disable the touchpad in the future, see https://bugs.freedesktop.org/show_bug.cgi?id=102408). Unfortunately this switch currently is triggered only when the laptop is opened 360°. To correctly disable tablet mode needs to be activated earlier at around 180° in the same way as windows 10 does it. Note that we currently have no ACPI specification on how the tablet mode switch works which makes it almost impossible to correctly implement it.
The same applies to the Thinkpad Yoga 370. But more things happen while slowly opening the laptop beyond 180°: Slightly before and slightly after 180°, this happens in dmesg: [ 9704.827487] thinkpad_acpi: unknown possible thermal alarm or keyboard event received [ 9704.827489] thinkpad_acpi: unhandled HKEY event 0x60f0 [ 9704.827490] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel.net I'd guess at 165° and at 195°. But I'm not sure. These don't always consistently happen. SW_TABLET_MODE always does, at nearly 360°. I own the Yoga 370 and I'm happy to test anything and supply more information.
I have submitted a patch upstream which can be found here: https://lkml.org/lkml/2017/9/15/188 This patch should work fine on the Yoga 370, but I cannot verify. I don't know what the HKEY 0x60f0 event is. Maybe there is something else that should change in response to how far the laptop is opened (e.g. wifi TX power configuration).
I think HKEY 0x60f0 is almost the same as 0x60c0 on the X1 Yoga 2016. https://github.com/torvalds/linux/blame/master/drivers/platform/x86/thinkpad_acpi.c#L195 But I can't be sure.
I do also see 0x60f0 being fired on the Yoga X1 2nd generation. But Lenovo has said that 0x60c0 is the right event for detecting tablet mode changes. There must be some other unknown meaning to 0x60c0 (which is related to the hinge state in some way).
Ah, it looks like 0x60f0 is related to the screen rotation. i.e. it can be triggered by simply rotating the laptop without changing the hinge position.
I just changed the event in https://github.com/torvalds/linux/blob/master/drivers/platform/x86/thinkpad_acpi.c#L195 from 0x60c0 to 0x60f0 and tested, the only thing that changed is the message, from 0x60f0 to 0x60c0. This means that both events trigger whenever I move the hinge past 180 degrees. I can't trigger any of those with just rotating the screen.
I have tried some more things on my Yoga 370 and have confirmed that in most (somehow not all) cases where 0x60c0 triggers, 0x60f0 also triggers. My guess is that 0x60c0 triggers whenever the keyboard should turn off and on again, but 0x60f0 triggers in every case where the tablet mode changes. None of the events trigger on my hardware when just rotating the screen. I added some print statements to the current thinkpad-acpi.c and recorded a video of what happens. Code at https://gist.github.com/Peetz0r/144f80758ce72ffe578a60a0feb70912 and video at https://www.youtube.com/watch?v=AjrIgAtJAe4 After doing so I decided to look at your patch to find out that the code I just checked out from kernel.org did not yet include the patch. I copied thinkpad-acpi.c from your patch and again added some print statements. Code at https://gist.github.com/Peetz0r/782de9e1bf03a2670aebab0300075d09 A few things stand out to me. First the list of possible values for `valid_modes` seems strange. Types 2 and 5 seem identical. Literally no difference at all. Modes `TP_ACPI_MULTI_MODE_STAND` and `TP_ACPI_MULTI_MODE_TENT` seem very similar, with the hinge in the same position, but a 180-degree difference in screen orientation. Somehow my hardware seems to be able to correctly identify those. It reports changing between those two based on which end of the screen points up. I guess `TP_ACPI_MULTI_MODE_STAND_TENT` exists for yoga-hardware that is not capable of this trick. This would be the difference between `type == 1` and `type == 4` I think. My laptop seems to be a type `4`, which means that in addition to the above, it would be unable of `TP_ACPI_MULTI_MODE_FLAT`. As far as I know, every ThinkPad supports this since way before convertibles, but I can obviously not be 100% sure. Anyway, when I lay my laptop flat on my desk, this happens: [ 4224.965683] thinkpad_acpi: Multi mode status type 4 with value 0x0002 [ 4224.965700] thinkpad_acpi: TP_ACPI_MULTI_MODE_FLAT [ 4224.965708] thinkpad_acpi: Unknown/reserved multi mode value 0x0002 for type 4, please report this to ibm-acpi-devel.net Sometimes followed by this: [ 4224.977831] thinkpad_acpi: unknown possible thermal alarm or keyboard event received [ 4224.977845] thinkpad_acpi: unhandled HKEY event 0x60f0 [ 4224.977855] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel.net I hope this information is useful in any way.
The reason for the code to be that verbose is that it closely follows the specification. I am aware that the code could be written in a much more terse way. Yeah, the warning message you mentioned was fixed in v2 of the patch (which is pending as it apparently it did not apply, will look into that in a bit). This is a mismatch between the specification that was provided to us and what the notebook actually sends. The specification said, that those laptops cannot detect the FLAT state. The hardware does have an accelerometer in the screen, so I am not surprised that it can correctly report tent/stand states. We don't really care about that though, as userspace can directly read the accelerometer value.
I somehow completely missed this, because I subscribed to the ibm-acpi-devel list a few days before you posted te v2 there. I just found it sitting in my mailbox staring at me for over 2 weeks. Nice to see the issue being fixed before I even noticed :) And yes, I now understand that the result of this method is a combination the hinge state and the accelerometer. I was expecting it to be just the hinge but it must be both. I also just noticed that I forgot to mention one specific thing: SW_TABLET_MODE now triggers at exactly the right moment. So, basically, this bug is fixed now (as soon as the patch lands in a fedora kernel). Right?
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs. Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27. If you experience different issues, please open a new bug report for those.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
OK, I believe this is fixed in the current release (i.e. F28) as the relevant patches have been upstream and should be included in the newer kernel.
This has been merged into newer Fedora releases.