Created attachment 186065 [details] simple rescan bash script that should work for most situations, it should be invoked from system tray Assume TB4/TB5 or USB-C / Display port alternative mode monitors are connected to TB4/TB5 hubs (passive or active) such as https://www.amazon.co.uk/dp/B0CT2HZ1ZY When laptop goes to sleep and resumes most often monitors come to live as well, but sometimes when hub itself goes to sleep , it is not always the case. It is not an easy and user friendly way to trigger USB-C retrain of the links to monitors. One way is to disconnect hub from both the laptop and hub from power supply and connect again to both.(Disconnecting monitors from hub and connecting does not help itself.) Sometimes even disconnecting hub does not help , because OS/linux will not initiate new connection. Manual rescan is a great fallback and it should be in Task bar / Status and Notification /Display configuration or in a new section Thunderbolt. This is to allow users out of the box user friendly experience (following Steve Jobs mantra "It just works out of the box") without letting users figure themselves how to tackle the problem. See attached shell script that works for me. It would be great to trigger execution of it from task bar/Status notification and right click on Display configuration, at the place where "Enable presentation mode" is. The script is generic and should work for all others , it should be executed under elevated privileges (sudo) or suid bit set. f It should be investigated how other devices (not just monitors react to this rescan). For example if external disk is connected to TB4/TB4 hub and IO operations (writing) are in progress ,etc. If you can detect automatically that only monitors are connected , then it is definitely safe to use it. In other situations you can warn users. *** Note that hooking the script automatically as a resume script is pointless, because most of the time the monitors resume well. And script would add like 5 undesirable seconds to initiation. Manual fallback rescan is preferable. ADDITIONAL INFORMATION Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.17.0-rc6-toeirei-ec (64-bit) Graphics Platform: Wayland Processors: 12 × 13th Gen Intel® Core™ i7-1355U Memory: 40 GiB of RAM (38.9 GiB usable) Graphics Processor: Mesa Intel® Iris® Xe Graphics Manufacturer: Notebook Product Name: L140AU
marian@linlap:~$ lspci | grep NHI 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0 (rev 01) In the script we areusing this PCI device ID 0000:00:0d.2
It's good that you've found a personal workaround that works for you, but I'm afraid it won't be suitable for inclusion; we want to be fixing bugs, not working around them. In this Bugzilla ticket, let's focus on the bug itself. You say you have one or more USB-C/Displayport monitor connected to a Thunderbolt dock, and when you put the laptop to sleep and wake it up again, much of the time (but not all the time?) the monitors don't wake up? Is that right?
Hi Nate. If you insist that my original suggestion and title (launch script from system tray) is a workaround, then so is the KDE/Menu Power Session->Restart. Why would you otherwise need to restart laptop if there is not a bug somewhere that is in need of fixing? Why to have a restart feature in the KDE? Ok,it was rhetoric question. Presence of restart feature in KDE , or CTRL+ALT+DEL , or CTRL+ALT+BACKSPACE or hardware reset button on is acceptance that software is not perfect and we need such "workarounds". Please reconsider such rescan/rebind thunderbolt feature. It can be life-safer. If there is a bug somewhere , it is burried underneath of KDE layer, If I had a time or deeper knowledge to debug it I would like not to report it to KDE team as I believe it is outside the scope of KDE project . If I had more info I would report it to linux kernel, or thunderbolt drivers maintaners, potentially to USB-C kernel drivers maintainers. What I asked for KDE team is to do what KDE team can do now and fast.
Please connect with linux kernel team and with the relevant modules (see below, thunderbolt, USB-C, maintainers (you look them up) to validate my little bash script and confirm it is a valid and safe way to restart and rescan the thunderbolt sub-system. Then make the KDE launcher to this or to equivalent solution. That is the job of KDE , give the user-friendly access to essential tools. Such script can be useful not in my situation, there possibly many more bugs that can be temporarily make less urgent having such feature built in KDE Currently I am outside and (https://www.amazon.co.uk/dp/B0CT2HZ1ZY?th=1) is unplugged, my relevant kernel module listings are marian@linlap:~$ lsmod | grep thunderbolt thunderbolt 548864 1 typec marian@linlap:~$ lsmod | grep usb usbhid 77824 1 wacom btusb 81920 0 btrtl 32768 1 btusb btintel 73728 1 btusb btbcm 24576 1 btusb btmtk 32768 1 btusb bluetooth 1085440 44 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm hid 262144 6 i2c_hid,wacom,usbhid,hid_multitouch,snd_soc_sdca,hid_generic usbcore 405504 6 xhci_hcd,usbhid,btmtk,uvcvideo,btusb,xhci_pci usb_common 16384 4 xhci_hcd,usbcore,uvcvideo,typec_ucsi marian@linlap:~$ lsmod | grep pci snd_sof_pci_intel_tgl 12288 0 snd_sof_pci_intel_cnl 20480 1 snd_sof_pci_intel_tgl snd_sof_intel_hda_generic 36864 2 snd_sof_pci_intel_tgl,snd_sof_pci_intel_cnl snd_sof_intel_hda_common 184320 4 snd_sof_intel_hda_sdw_bpt,snd_sof_intel_hda_generic,snd_sof_pci_intel_tgl,snd_sof_pci_intel_cnl snd_sof_pci 24576 3 snd_sof_intel_hda_generic,snd_sof_pci_intel_tgl,snd_sof_pci_intel_cnl snd_sof 401408 6 snd_sof_intel_hda_sdw_bpt,snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_hda_generic,snd_sof_intel_hda,snd_sof_pci_intel_cnl snd_soc_acpi_intel_match 143360 3 snd_sof_intel_hda_generic,snd_sof_pci_intel_tgl,snd_sof_pci_intel_cnl processor_thermal_device_pci 12288 0 processor_thermal_device 20480 1 processor_thermal_device_pci processor_thermal_wt_hint 16384 2 processor_thermal_device_pci,processor_thermal_device processor_thermal_power_floor 12288 2 processor_thermal_device_pci,processor_thermal_device sdhci_pci 110592 0 xhci_pci 24576 0 sdhci_uhs2 36864 1 sdhci_pci sdhci 94208 2 sdhci_uhs2,sdhci_pci xhci_hcd 376832 1 xhci_pci intel_lpss_pci 28672 0 cqhci 32768 1 sdhci_pci intel_lpss 12288 1 intel_lpss_pci mmc_core 270336 4 sdhci_uhs2,sdhci,cqhci,sdhci_pci usbcore 405504 6 xhci_hcd,usbhid,btmtk,uvcvideo,btusb,xhci_pci I will post hwinfo , when I get home and connect hub and monitor. But I believe fixing this 'bug' should not be your focus as it can also be the hub hardware issue or feature.
A bug report needs to be a description of a problem. If it's instead phrased as a proposed solution to a problem, then it's likely the solution will be rejected because it's not suitable in some way, and the underlying problem will remain present but without a bug report to track it. Let's make this bug report about the problem you're seeing, not a particular proposed solution for it.
But this bug report is suitable for kernel team, not KDE team. It is OK to record single individual bug, each of them. I wanted to address the fact that , there were , are and always will be bugs on hardware level or lower sofrware level in thunderbolt subsystem beyond the scope of KDE , so the restart of thunderbolt is needed in KDE. That is missing feature in KDE. I gave me issue only as an example of such multiple bugs to motivate feature request. It is ok you took it as my specific bug report, but you cannot do anything about it in KDE. I meant the entry as feature I wish for wishlist. Bug report is for kernel team, not here. Lets have two separate entries. One my particular bug and second entry feature request. Bug support feature request , but there are two different things you are mixing up, such as restart computer feature in KDE can be used to workaround many other bugs, but it is a separate thing from other bugs.
Related Feature request (FR) https://bugs.kde.org/show_bug.cgi?id=511259
If there's a driver or hardware issue, then that needs to be reported to the kernel, so that the issue can be fixed or worked around in the correct layer. Exposing such workarounds to the user is rather problematic, because in some cases it could lead to data loss (like accidentally disconnecting some USB storage device) and it makes it a lot less likely for affected users to report the actual bug. If you want that for yourself, you can of course create a widget or something that runs the script of course, but it's not something we want to ship upstream.