Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logind does not detect docking station, goes into sleep when turning on the monitor #18333

Closed
javiertury opened this issue Jan 21, 2021 · 12 comments
Labels

Comments

@javiertury
Copy link

systemd version the issue has been seen with

systemd.x86_64                                     246.7-2.fc33

Used distribution
Fedora 33

Linux kernel version used (uname -a)

5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

CPU architecture issue was seen on
x86_64 Intel core i5 7th gen

Expected behaviour you didn't see

According to this function, if the docking station had been detected, systemd should have printed "System is docked." instead of "External (1) displays connected."

bool manager_is_docked_or_external_displays(Manager *m) {
int n;
/* If we are docked don't react to lid closing */
if (manager_is_docked(m)) {
log_debug("System is docked.");
return true;
}
/* If we have more than one display connected,
* assume that we are docked. */
n = manager_count_external_displays(m);
if (n < 0)
log_warning_errno(n, "Display counting failed: %m");
else if (n >= 1) {
log_debug("External (%i) displays connected.", n);
return true;
}
return false;
}

In my system, the docking station can be found in /sys/devices/platform/dock.0/.

Unexpected behaviour you saw

Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Got message type=signal sender=:1.9 destination=n/a path=/org/freedesktop/systemd1/unit/systemd_2dhostnamed_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=607 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scan all dirs
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/bus
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/class
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: External (1) displays connected.
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Handling of handle-lid-switch (level) is disabled, taking no action.
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Got message type=signal sender=:1.9 destination=n/a path=/org/freedesktop/systemd1/unit/systemd_2dhostnamed_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=608 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Got message type=signal sender=:1.9 destination=n/a path=/org/freedesktop/systemd1/unit/systemd_2dhostnamed_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=609 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Got message type=signal sender=:1.9 destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=610 reply_cookie=0 signature=so error-name=n/a error-message=n/a
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scan all dirs
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/bus
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/class
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: External (1) displays connected.
Jan 21 10:16:33 MiWiFi-R3L-srv systemd-logind[1154]: Handling of handle-lid-switch (level) is disabled, taking no action.
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scan all dirs
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/bus
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: sd-device-enumerator: Scanning /sys/class
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: Sleep mode "mem" is supported by the kernel.
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: Suspending...
Jan 21 10:16:38 MiWiFi-R3L-srv systemd-logind[1154]: Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1/unit/suspend_2etarget interface=org.freedesktop.DBus.Properties member=Get cookie=117 reply_cookie=0 signature=ss error-name=n/a error-message=n/a

Steps to reproduce the problem

Place the laptop (t470) in its docking station. Have an external monitor attached and turn it on, close the lid of the laptop.

# logind.conf

[Login]
HandlePowerKey=suspend
HandleHibernateKey=suspend

Lock the screen and wait until it times out and turns off the screen (from software, swaymsg "output * dpms off"). Then manually turn off the monitor (physically).

The problem is that now, when you turn on again the monitor (physically) the system will go into sleep. Since I'm docked I expected that logind should not suspend the system I think there are two issues:

  • logind is not detecting the docking-station
  • why does logind suspend the system when the monitor is turned on? That's weird. Even if I want the system not to enter sleep when docked, I think it would be more understandable to suspend the system when the monitor is turned off.
@poettering
Copy link
Member

is this reproducible in something less exotic than swamsg? no idea what that does with logind, i.e. whether it inibits its handling or not...

how does your docking station communicate its state? logind only checks for an SW_DOCK input device. If you docking station doesn't have that we have no idea about the docking state. That's why we also check the displays.

@javiertury
Copy link
Author

Following your comments in older issues, I used evtest to search for a SW_DOCK event.

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Sleep Button
/dev/input/event1:	Lid Switch
/dev/input/event2:	Power Button
/dev/input/event3:	AT Translated Set 2 keyboard
/dev/input/event4:	SynPS/2 Synaptics TouchPad
/dev/input/event5:	SINO WEALTH USB KEYBOARD
/dev/input/event6:	SINO WEALTH USB KEYBOARD Mouse
/dev/input/event7:	SINO WEALTH USB KEYBOARD System Control
/dev/input/event8:	SINO WEALTH USB KEYBOARD Consumer Control
/dev/input/event9:	TPPS/2 IBM TrackPoint
/dev/input/event10:	Logitech USB Optical Mouse
/dev/input/event11:	ELAN Touchscreen
/dev/input/event12:	ELAN Touchscreen UNKNOWN
/dev/input/event13:	ELAN Touchscreen UNKNOWN
/dev/input/event14:	Video Bus
/dev/input/event15:	ThinkPad Extra Buttons
/dev/input/event16:	PC Speaker
/dev/input/event17:	HDA Intel PCH Mic
/dev/input/event18:	HDA Intel PCH Dock Mic
/dev/input/event19:	HDA Intel PCH Dock Headphone
/dev/input/event20:	HDA Intel PCH Headphone
/dev/input/event21:	HDA Intel PCH HDMI/DP,pcm=3
/dev/input/event22:	HDA Intel PCH HDMI/DP,pcm=7
/dev/input/event23:	HDA Intel PCH HDMI/DP,pcm=8
/dev/input/event24:	HDA Intel PCH HDMI/DP,pcm=9
/dev/input/event25:	HDA Intel PCH HDMI/DP,pcm=10
/dev/input/event26:	Integrated Camera: Integrated C

I searched for SW_DOCK in supported events for each of them, but didn't find anything. I tested "ThinkPad Extra Buttons" to see if there was any event triggered when I undock-and-redock the laptop but there was none. I also tested "HDA Intel PCH Dock Mic" and "HDA Intel PCH Dock Headphone", only the latter did something.

Input device name: "HDA Intel PCH Dock Headphone"
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
    Event code 2 (SW_HEADPHONE_INSERT) state 1
Properties:
Testing ... (interrupt to exit)
Event: time 1611267137.426764, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1611267137.426764, -------------- SYN_REPORT ------------
Event: time 1611267142.469390, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1611267142.469390, -------------- SYN_REPORT ------------

Back to the reproduction steps, I've realized that swaymsg is not necessary.

1 - Turn on the monitor, place the laptop in the docking station and close the lid.
2 - Turn off the monitor (physically), the laptop remains awake
3 - Turn on the monitor (physically), the laptop goes into sleep

@javiertury
Copy link
Author

javiertury commented Jan 21, 2021

Also, these are some of the files in /sys/devices/platform/dock.0/, if they are of any help.

$ ls /sys/devices/platform/dock.0/
docked  driver_override  firmware_node  flags  modalias  power  subsystem  type  uevent  uid  undock

docked = 1
modalias = acpi:PNP0C0A:
type = battery_bay
uevent = MODALIAS=acpi:PNP0C0A:
flags = 64

@javiertury
Copy link
Author

javiertury commented Jan 23, 2021

I investigated further into the monitor issue. I've run evtest on the display port device and followed this:

1 - Turn on the monitor place the laptop in the docking station. The lid remains open, running evtest.
2 - Turn off the monitor (physically), the laptop remains awake
3 - Wait 30+ seconds
4 - Turn on the monitor (physically), the laptop goes into sleep

This is the result

Input device name: "HDA Intel PCH HDMI/DP,pcm=7"
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
    Event code 6 (SW_LINEOUT_INSERT) state 1
    Event code 8 (SW_VIDEOOUT_INSERT) state 1
Properties:
Testing ... (interrupt to exit)
Event: time 1611413349.093500, type 5 (EV_SW), code 6 (SW_LINEOUT_INSERT), value 0
Event: time 1611413349.093500, type 5 (EV_SW), code 8 (SW_VIDEOOUT_INSERT), value 0
Event: time 1611413349.093500, -------------- SYN_REPORT ------------
Event: time 1611413352.784636, type 5 (EV_SW), code 6 (SW_LINEOUT_INSERT), value 1
Event: time 1611413352.784636, type 5 (EV_SW), code 8 (SW_VIDEOOUT_INSERT), value 1
Event: time 1611413352.784636, -------------- SYN_REPORT ------------

All events are repoted to evtest at the time I turn on the monitor in step 4. According to evtest all events happen within a 4 seconds interval, but this is not true. The disconnect event should have been reported at least 30 seconds earlier.

EDIT: This was with an Display Port cable, because it's a 4k monitor. I tried with an HDMI cable and the problem did not happen, no events are triggered when the monitor is turned on/off. There are only events when the HDMI cable is plugged/unplugged.

@javiertury
Copy link
Author

So the problem appears to be the Display Port Protocol. Turning the monitor on or off doesn't trigger any event when connected by HDMI, only if the cable is connected/disconnected. However when connected by Display Port, the monitor appears to trigger a new display port handshake after being turned on[1], that explains why both disconnect and connect events are sent almost simultaneously.

Regarding docking support, is there any chance of supporting the thinkpad ultra dock station? Could something be patched so that a SW_DOCK event is triggered when connected? Or could logind somehow subscribe to /sys/devices/platform/dock.0/ changes?

@poettering
Copy link
Member

we never had support for such "acpi dock" devices. Is that a class device with a defined API?

Ideally these devices would just generate SW_DOCK input events like any other dock... i.e. I'd really prefer for this to be fixed in the kernel.

That said, supporting this in logind dirctly would probably be OK. We don't like adding code that deals with specific hardware, specific drivers, but I guess a reasonably ACPI interface is probably OK to support, it's after all already an abstraction layer of its own.

That said, this would require a patch being submitted, by someone who has the hw, i.e. not us...

Summary: unless you prep a patch this is not going to get fixed, and I'd suggest fixing it in the kernel by changing the driver to register an SW_DOCK input device like all other dock drivers. But if that's not in the cards, it shoul dbe OK to submit a patch against logind instead — however only if the driver is reasonably OK, i.e. has notifications in some form?

@javiertury
Copy link
Author

javiertury commented Jan 25, 2021

I decided to see how deep the rabbit hole goes, and I'm afraid it there is nothing we can do. Let me explain.

First I located the kernel driver behind /sys/devices/platform/dock.0/docked, which is drivers/acpi/dock.c. Then I located the driver that is ultimately responsible for reporting the dock/undock status in thinkpad laptops, which is drivers/platform/x86/thinkpad_acpi.c.

The thinkpad_acpi driver is huge and complex, so first I gathered some general information about the context. ACPI is how the t470 communicates with the dock station. I installed acpid and listened to all acpi events with acpid/acpi_listen as described here[1].

battery PNP0C0A:00 00000080 00000001
battery PNP0C0A:00 00000080 00000001
ac_adapter ACPI0003:00 00000080 00000001
ibm/hotkey LEN0268:00 00000080 00006030
thermal_zone LNXTHERM:00 00000081 00000000
battery PNP0C0A:00 00000080 00000001
battery PNP0C0A:00 00000080 00000001
ac_adapter ACPI0003:00 00000080 00000000
ibm/hotkey LEN0268:00 00000080 00006030
thermal_zone LNXTHERM:00 00000081 00000000

None of these events is related to dock/undock. Only ibm/hotkey LEN0268:00 00000080 00006030 could have some relation, but after reading thinkpad_acpi.c I quickly discarded that idea. Assuming I interpreted the code correctly, that event has the following description.

windows; thermal table changed

I found similar reports[2] complaining about t470 not detecting dock status. At this point I was completely puzzled, how does /sys/devices/platform/dock.0/docked figure out that my laptop is docked?

To cope with the confusion and uncertainty generated by this information, I needed some entertainment. I typed the following command in the terminal from time to time. I was amazed, wondering about all the complexities hidden behind such a simple command.

$ cat /sys/devices/platform/dock.0/docked
1

I picked up the laptop and moved to the living room. There I continued typing the same command every minute or so.

$ cat /sys/devices/platform/dock.0/docked
1

And... I finally realized what was going on. There is no way to know if the laptop is docked and the kernel doesn't know it either.

So if someone reading this is facing the same problem, consider these workarounds.

  • If you don't use a 4k monitor or if 4k@30hz is acceptable to you, use an HDMI cable instead of Display Port.
  • Use HandleLidSwitchExternalPower=ignore in /etc/systemd/logind.conf to inhibit sleep while your laptop is connected to AC.

@poettering, thanks for bearing with me.

@poettering
Copy link
Member

but that sounds like some bug in the kernel driver that could be fixed, no? Ping the kernel driver maintainers maybe?

@javiertury
Copy link
Author

I've just contacted kernel driver maintainers to let them know

@vale981
Copy link

vale981 commented Oct 20, 2021

I've just contacted kernel driver maintainers to let them know

I'm on Kernel 5.14.8 and still experience that issue. Are there any updates on this?
cat /sys/devices/platform/dock.0/docked always yields 1 irrespective of the docking status.

@javiertury
Copy link
Author

On January 26 I posted a text-only email to ibm-acpi-devel@lists.sourceforge.net[^1]. I waited for days but I received no answer in my inbox and the email doesn't appear in the mailing list archives.

I also received no bounce notification. My guess is that the email was filtered out because it was not interesting enough or because there were some requirements that I was not aware of and this message didn't meet.

@vale981
Copy link

vale981 commented Oct 21, 2021

On January 26 I posted a text-only email to ibm-acpi-devel@lists.sourceforge.net[^1]. I waited for days but I received no answer in my inbox and the email doesn't appear in the mailing list archives.

I also received no bounce notification. My guess is that the email was filtered out because it was not interesting enough or because there were some requirements that I was not aware of and this message didn't meet.

Thank you for the reply. I can launch another attempt to get a foot in the door.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants