Devices connected through USB-C broken before graphical target

robin92 · 2023-10-28 16:15:45

Hello guys!

I got a monitor with an integrated docking station, it offers a few USB2 and USB3 ports, Ethernet, and of course a display (DisplayPort). I use the USB ports to connect the devices like webcam and keyboard. I connect the monitor through a USB-C port to my laptop (ThinkPad T14 G1) and also get power delivered to my laptop through the same cable. Everything works fine after graphical.target is reached. However, my setup also involves a LUKS encrypted disk that gets unlocked through a manually entered password (sd-encrypt hook). Now, when I need to enter my LUKS password, I don't get the video output on the monitor, I must open the laptop's lid and use its screen. Also, sometimes I must use the laptop's keyboard as the keyboard connected to the monitor does not work either. Adding to that, after the disk is unlocked, I need to re-plug the USB-C cable to get the devices working again.

This is very frustrating as the point of this setup is to keep the laptop hidden under the display which right now is hardly convenient before it boots... What's interesting is that everything used to work just fine before I replaced my disk and reinstalled the system which I also used as an opportunity to (at last) encrypt my data. Is that the hook to get the LUKS working causing all that mess or am I missing something and this is fixable without resigning from disk encryption? I'd really appreciate your expertise and ideas on this. I don't have anymore on my own and seem to struggle with the problem for far too long.

Thanks in advance.

seth · 2023-10-28 19:12:52

You could use a keyfile instead of a passphrase to sidestep that issue, then put the key onto a removable device (usb key) and use that as effective HW lock to the system
https://wiki.archlinux.org/title/Dm-cry … n#Keyfiles
https://wiki.archlinux.org/title/Dm-cry … crypt_hook

Before the kernel loads, you're w/ the bootloader and before that w/ the UEFi, so if your external output doesn't work at this stage (and I assume didn't before, you were just not running into that b/c you were booting through into the system?) there's not much you can do at the OS side to fix that.

robin92 · 2023-10-29 09:13:52

seth wrote:

You could use a keyfile instead of a passphrase to sidestep that issue, then put the key onto a removable device (usb key) and use that as effective HW lock to the system

Yeah, I was thinking about that but figured I'd need to bring my "keydrive" together with my laptop or somehow go back to password method when the key is not detected. Probably I'll look into this even if I managed to fix the issue.

seth wrote:

Before the kernel loads, you're w/ the bootloader and before that w/ the UEFi, so if your external output doesn't work at this stage (and I assume didn't before, you were just not running into that b/c you were booting through into the system?) there's not much you can do at the OS side to fix that.

Sure, that's true, though it works before the kernel loads. When the laptop starts and before I run my UKI, I got the external display running just fine and can use the keyboard. Also, when I reboot the system after I logged in to a fully working system, I also get all the devices running while entering the password in the sd-encrypt hook. It's kinda interesting as I think the problem is with device discovery during initramfs which I think is the actual environment I am in while running the sd-encrypt hook. I don't know how to debug and confirm/disprove this theory. Maybe you have some knowledge about that?

seth · 2023-10-29 12:56:59

Basically "what do you see before you're asked to enter the password" (you can encrypt the entire system or everything but the boot partition or only the home partition) - if you get to select a kernel before being asked to enter the password, the bootloader isn't encrypted. Does it still show up on the external output?
Does it work if you select the fallback initramfs?

You can force outputs to be enabled, https://www.kernel.org/doc/Documentation/fb/modedb.rst
The relevant output names show up on /sys/class/drm - maybe post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

and if this seems a recent regression and eg. the LTS kernel isn't affected, enable https://wiki.archlinux.org/title/NVIDIA … de_setting and in doubt add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters (it doesn't matter whether there's an nvidia GPU, the kernel will disable the simpledrm device if that parameter is there regardless of the actual HW)

robin92 · 2023-10-29 20:09:56

I tried getting the boot logs for you but surprisingly I cannot reproduce the issue in full. In a few attempts I made I got the screen during the full power on but not the keyboard. I don't have logs from a situation that both work or don't work at all.
I also have a log file from resuming from hibernation which also had a display working but not the keyboard.

I put both here.

seth · 2023-10-29 22:19:23

Crucial device is the

Oct 29 20:32:31 think14 kernel: hid-generic 0003:413C:4503.0022: input,hidraw3: USB HID v1.11 Keyboard [Dell Computer Corp Dell Universal Receiver] on usb-0000:07:00.3-1.1.2/input0

Do you have a $5 wired keyboard/mouse you could try?

robin92 · 2023-10-31 05:50:13

Unfortunately no wired keyboard available right now. I'll get some for testing purposes. However, today when resuming my laptop, I got the display not to start. New logs have been uploaded to the same location.

Also, I run some tests yesterday and it looks like the wireless device is detected and can be used something like 30s after the `sd-encrypt` hook enters (so I see a disk encryption password prompt).

seth · 2023-10-31 07:54:27

You can btw. make this easer for everyone by posting files to eg. 0x0.st

Oct 31 06:43:39 think14 gnome-shell[2081]: Could not release device '/dev/input/event15' (13,79): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:39 think14 gnome-shell[2081]: Could not release device '/dev/input/event16' (13,80): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:40 think14 gnome-shell[2081]: Could not release device '/dev/input/event18' (13,82): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:40 think14 gnome-shell[2081]: Could not release device '/dev/input/event19' (13,83): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:40 think14 gnome-shell[2081]: Could not release device '/dev/input/event20' (13,84): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:40 think14 gnome-shell[2081]: Could not release device '/dev/input/event21' (13,85): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:40 think14 gnome-shell[2081]: Could not release device '/dev/input/event22' (13,86): GDBus.Error:org.freedesktop.login1.DeviceNotTaken: Device not taken
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event21: Could not get device info for path /dev/input/event21: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event20: Could not get device info for path /dev/input/event20: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event22: Could not get device info for path /dev/input/event22: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event16: Could not get device info for path /dev/input/event16: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event18: Could not get device info for path /dev/input/event18: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event17: Could not get device info for path /dev/input/event17: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event15: Could not get device info for path /dev/input/event15: No such file or directory
Oct 31 06:43:45 think14 gnome-shell[2081]: Could not open device /dev/input/event19: Could not get device info for path /dev/input/event19: No such file or directory
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Oct 31 06:43:49 think14 gnome-shell[2081]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed

Is this actually hibernation specific or does it also affect cold boots?
https://bbs.archlinux.org/viewtopic.php?id=289770
Can you reproduce any of this when not using gnome or GDM?

Arch Linux

#1 2023-10-28 16:15:45

Devices connected through USB-C broken before graphical target

#2 2023-10-28 19:12:52

Re: Devices connected through USB-C broken before graphical target

#3 2023-10-29 09:13:52

Re: Devices connected through USB-C broken before graphical target

#4 2023-10-29 12:56:59

Re: Devices connected through USB-C broken before graphical target

#5 2023-10-29 20:09:56

Re: Devices connected through USB-C broken before graphical target

#6 2023-10-29 22:19:23

Re: Devices connected through USB-C broken before graphical target

#7 2023-10-31 05:50:13

Re: Devices connected through USB-C broken before graphical target

#8 2023-10-31 07:54:27

Re: Devices connected through USB-C broken before graphical target

Board footer