P.S.: I completely failed to find any explanation/definition of "VBDL" or "VGBS". If someone could point me to that, I might be able to experiment more on my own. If I understand correctly, the purpose of acpi_evaluate_object(handle, "VBDL", NULL, NULL) is to evaluate the SW_TABLET_MODE state and to perform some kind of reset for devices that don't update the state otherwise after resume. Calling detect_table_mode() instead seems to satisfy at least the first purpose, and remedies the problem for me - but I guess that's not a full solution? Cheers, Alex On 13/02/2024 23.35, Alexander Kobel wrote: > Hi Hans, all, > > after upgrading to 6.7.1 or 6.6.13 (LTS), my Thinkpad X1 Tablet doesn't suspend anymore. Or, rather, it suspends, but wakes again immediately. This happens regardless of whether the keyboard is attached or not, with all ACPI wakeup triggers disabled according to /proc/acpi/wakeup. > I could identify the following commit as the culprit: > > 14c200b7ca46b9a9f4af9e81d258a58274320b6f > platform/x86: intel-vbtn: Fix missing tablet-mode-switch events > > First, it's a suspiciously related patch going into both kernel versions. > Second, unloading intel-vbtn resolves the problem; machine suspends as usual. > Third, I tried modifying the patch. Commenting out the newly introduced > > /* Some devices need this to report further events */ > acpi_evaluate_object(handle, "VBDL", NULL, NULL); > > resolves the problem on my machine. > > I understand that the change was in for a reason, but the deeper meaning of that statement eludes me; is it possible that my model is quirky for that one? > > FWIW: > - SW_TABLET_MODE is properly updated about half a second after I attach/detach/fold the keyboard during suspend with that statement commented out (but attaching/detaching/folding all wake the device, unless I also `echo Y > /sys/module/acpi/parameters/ec_no_wakeup` - but then I can't wake the tablet at all anymore). > - Folding the keyboard to the back of the device disables the keyboard. > With that statement in (as in 6.7.1 upstream), SW_TABLET_MODE is set to 1 (correct), but reverts to 0 again after about a second (incorrect); the keyboard remains disabled. > Without the statement, SW_TABLET_MODE remains on 1 until I flip back the keyboard to normal (expected behavior). > > > On a side note, I initially thought that detect_tablet_mode() in resume() is the culprit. intel_vbtn_pm_resume() is also included in the thaw callback (and I usually use hybrid suspend) and, after the patch, augmented with the detect_tablet_mode() routine. > If I understand correctly the description in [1], thaw is not really resume-/restore-like except perhaps for the corner case of failed hibernation image creation. Turns out it doesn't seem to cause the harm, but still: is intel_vbtn_pm_resume() on thaw really intended? The description says it's used to undo the changes made by the preceding freeze (including prepare), but this rather seems to match intel_vbtn_pm_complete()'s definition than intel_vbtn_pm_resume()'s... > > [1] https://www.kernel.org/doc/html/v4.12/driver-api/pm/types.html > > > Of course, I stand available for any debugging or further investigations; happy to do some work myself if someone can guide me through. > > > Cheers, > Alex
