Samsung Smart TV "crashes" NVidia driver, can't detect TV any more?

[Rogan Dawes]

Hi folks,

I have a 43" Samsung Smart TV that I am using as a monitor with a ThinkPad P51, running Fedora 35 Workstation Edition. This laptop has a "NVIDIA Corporation GM206GLM [Quadro M2200 Mobile] / Mesa Intel® HD Graphics 630 (KBL GT2)" graphics subsystem. As far as I can make out, I am using the latest NVidia driver (495.46).

What is unfortunately happening, is that if my laptop goes to sleep, the TV sees that the source disappears, and "tries to look for the laptop", repeatedly. This ends up waking up the laptop (sometimes), until the TV eventually gives up and turns itself off. The problem is then that the laptop no longer detects that the TV is connected to the HDMI port, and I have to reboot to allow the laptop to detect the screen again. Xrandr does not detect the display if run manually, and the Settings app Displays page also doesn't show the TV.

This is a rather difficult thing to google, I have had zero results in my searching.

I also tried looking for any logs that would indicate what went wrong, but I found nothing in the syslog, etc.

Can anyone give me pointers on how I can start debugging this? I am fairly technical, so can certainly follow instructions. I'm guessing I need to enable verbose logging for the driver so it can report when new displays are connected or disconnected, as well as any actions around those events?

Thanks

Rogan

[stan]

On Tue, 18 Jan 2022 14:55:11 -0000
"Rogan Dawes"  wrote:
> I have a 43" Samsung Smart TV that I am using as a monitor with a
> ThinkPad P51, running Fedora 35 Workstation Edition. This laptop has
> a "NVIDIA Corporation GM206GLM [Quadro M2200 Mobile] / Mesa Intel® HD
> Graphics 630 (KBL GT2)" graphics subsystem. As far as I can make out,
> I am using the latest NVidia driver (495.46).
>
> What is unfortunately happening, is that if my laptop goes to sleep,
> the TV sees that the source disappears, and "tries to look for the
> laptop", repeatedly. This ends up waking up the laptop (sometimes),
> until the TV eventually gives up and turns itself off. The problem is
> then that the laptop no longer detects that the TV is connected to
> the HDMI port, and I have to reboot to allow the laptop to detect the
> screen again. Xrandr does not detect the display if run manually, and
> the Settings app Displays page also doesn't show the TV.

When you say 'turns itself off', does it actually fully power down?
Have you tried powering down the TV, waiting 10 or 15 seconds, and then
powering back up?  It should look for a source again, and if the laptop
is not sleeping, it should find it, and everything should just work.

Another thought.  Have you tried reloading the video driver when you
take the laptop out of sleep?  It should look for outputs, and if the
TV is only in suspend, it might respond to status queries.  Seems
doubtful, because if the laptop was aware there was a connection when
it went to sleep, it probably tries sending output to the TV when it
wakes.  And that isn't waking the TV.
> This is a rather difficult thing to google, I have had zero results
> in my searching.
>
> I also tried looking for any logs that would indicate what went
> wrong, but I found nothing in the syslog, etc.

I don't think anything went wrong.  There is just a procedural mismatch
between the TV and the laptop.  Once the TV turns itself off because
there is no input, it seems to be unavailable for being turned on.
What is the startup sequence like?  Do you start the laptop and then
turn the TV on?  Or could it be that they are turned on simultaneously,
and the TV is still looking for a source when the laptop finishes
booting, and thus finds one?
> Can anyone give me pointers on how I can start debugging this? I am
> fairly technical, so can certainly follow instructions. I'm guessing
> I need to enable verbose logging for the driver so it can report when
> new displays are connected or disconnected, as well as any actions
> around those events?

No experience whatsoever with this, but that sounds reasonable.  From
the symptoms though, I don't think this is a driver issue.  I think the
TV is set up to ignore attempts to connect once it doesn't find a
source, and that it only looks for sources at power up.

[Rogan Dawes]

I don't believe that this is a TV issue (other than its behaviour on input loss triggering the resulting behaviour on the laptop). This is because if I reboot the laptop, the TV is quite happy to recognise it again, while disconnecting and reconnecting the HDMI cable does not have the same effect.

I can perhaps look at interposing a breakout board on the HDMI cable, and using a logic analyser on certain pins (i.e. those that carry the DDC protocol used to enumerate the display modes supported by the connected display). That might allow me to see that the laptop is or isn't recognising that the display is connected and performing the DDC interrogation. But I imagine this would also be possible by enabling verbose logging too, which would probably be a lot easier in the short term.

[Jon LaBadie]

On Tue, Jan 18, 2022 at 04:02:41PM -0000, Rogan Dawes wrote:
> I don't believe that this is a TV issue (other than its behaviour on input loss triggering the resulting behaviour on the laptop). This is because if I reboot the laptop, the TV is quite happy to recognise it again, while disconnecting and reconnecting the HDMI cable does not have the same effect.
>
> I can perhaps look at interposing a breakout board on the HDMI cable, and using a logic analyser on certain pins (i.e. those that carry the DDC protocol used to enumerate the display modes supported by the connected display). That might allow me to see that the laptop is or isn't recognising that the display is connected and performing the DDC interrogation. But I imagine this would also be possible by enabling verbose logging too, which would probably be a lot easier in the short term.
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> > > End of included message <<<

I have a similar problem with a Dell 35 inch monitor.  If my desktop
is idle long enough and I have no screensaver, the screen goes blank.
Note, the computer does not go to suspend or hibernate ever.  After
a time, the blank monitor does not come back if I key press or mouse
move.  Yet I can here the computer has been stimulated.

Sometimes if I power cycle the monitor it comes back though most
often not.

Rebooting of course awakens the monitor.

Also, I've found if I ssh in remotely and log out my console
session, when the display manager presents its login screen,
the monitor awakens.

Jon

[Sam Varshavchik]

Rogan Dawes writes:
> have to reboot to allow the laptop to detect the screen again. Xrandr does  
> not detect the display if run manually, and the Settings app Displays page  
> also doesn't show the TV.
>
> This is a rather difficult thing to google, I have had zero results in my  
> searching.

This seems to be a long running issue with various Nvidia cards, in my  
experience. If a monitor is present and powered on at boot time everything is  
fine. If the monitor gets powered off or disconnected it won't ever come  
alive again, until the next reboot. This is not limited just to nvidia's  
drivers. In all other respects my old geforce gtx 285 works just fine with  
nouveau; this is the only defect.

[Patrick O'Callaghan]

On Tue, 2022-01-18 at 18:40 -0500, Sam Varshavchik wrote:
> Rogan Dawes writes:
> > have to reboot to allow the laptop to detect the screen again.
> > Xrandr does  
> > not detect the display if run manually, and the Settings app
> > Displays page  
> > also doesn't show the TV.
> >
> > This is a rather difficult thing to google, I have had zero results
> > in my  
> > searching.
>
> This seems to be a long running issue with various Nvidia cards, in
> my  
> experience. If a monitor is present and powered on at boot time
> everything is  
> fine. If the monitor gets powered off or disconnected it won't ever
> come  
> alive again, until the next reboot. This is not limited just to
> nvidia's  
> drivers. In all other respects my old geforce gtx 285 works just fine
> with  
> nouveau; this is the only defect.

I have a single monitor connected via a KVM switch to two video
outputs, the onboard Intel and an NVidia GPU card. I use this setup for
VMs with GPU passthrough. The first switch I tried had exactly this
problem, i.e. if I switched away from the NVidia and then back again it
would remain off. I ended up getting a different model KVM switch that
maintains each of its connections "live" so the problem doesn't occur.
Possibly this is something the OP could consider.

poc

[Dave Ulrick]

On 1/18/22 5:40 PM, Sam Varshavchik wrote:
> Rogan Dawes writes:
> > have to reboot to allow the laptop to detect the screen again. Xrandr 
> > does not detect the display if run manually, and the Settings app 
> > Displays page also doesn't show the TV.
> >
> > This is a rather difficult thing to google, I have had zero results 
> > in my searching.
>
> This seems to be a long running issue with various Nvidia cards, in my 
> experience. If a monitor is present and powered on at boot time 
> everything is fine. If the monitor gets powered off or disconnected it 
> won't ever come alive again, until the next reboot. This is not 
> limited just to nvidia's drivers. In all other respects my old geforce 
> gtx 285 works just fine with nouveau; this is the only defect.

Several months ago I started to experience a similar issue: screen going 
off while PC is sleeping then never coming back on until reboot.

When a sleep event occurred, syslog showed a failed attempt to suspend 
the NVIDIA device. This led me to do a Google search that led me to a 
new RPM:

xorg-x11-drv-nvidia-power

It installed several service unit files:

/usr/lib/systemd/system/nvidia-fallback.service
/usr/lib/systemd/system/nvidia-hibernate.service
/usr/lib/systemd/system/nvidia-resume.service
/usr/lib/systemd/system/nvidia-suspend.service

I don't recall whether I had to manually enable any of these services, 
but I eventually managed to restore proper NVIDIA behavior for power events.

Dave

[Tim]

On Tue, 2022-01-18 at 12:33 -0500, Jon LaBadie wrote:
> I have a similar problem with a Dell 35 inch monitor.  If my desktop
> is idle long enough and I have no screensaver, the screen goes blank.

I, too, had similar issues.  In my case, one of those multi-input
monitors.  If it doesn't see an input (e.g. you rebooted, long-idle
time screen-blanked, etc), the monitor would go scanning through its
other input choices.

Unfortunately, like nearly all modern devices, it's painfully slow at
doing this (quite why anything needs 10 - 15 seconds to change inputs
escapes me, other than designed by an arse).  Then, when you tried to
do something it was probably on the wrong input, and was so slow to get
around to the input you wanted the display card had given up on the
monitor (chicken and egg problem).  Not to mention being painful to see
boot-up screens.

If you had two devices connected to the monitor, it was a real
nuisance.  It'd latch onto the always-on source, and was nearly
impossible to get it to wait for the just switched on source.

If you have any automatic input scanning options on your display,
switch them off.  And connecting your source to input one may help.

[Rogan Dawes]

Wow! That is awesome! Hopefully this will give me some pointers in the right direction (if it doesn't "just work"(tm)).

From reading the script at /usr/bin/nvidia-sleep.sh, it seems that when it happens, I can try to change to a console VT, suspend and awaken the driver, then change back, and hopefully it will revive the display!

Thanks!

[Rogan Dawes]

That is excellent! Thanks for the pointer to this.

[Rogan Dawes]

If I don't find a software solution, I'm going with a smart power switch that will power the TV off whenever the laptop screen blanks. Taking no prisoners! :-)

[Rogan Dawes]

I can attach the TV to my laptop long after boot, with no issues. However, once this sleep behaviour has triggered, I can disconnect and reconnect as many times as I like without resuscitating it.

[Rogan Dawes]

> Wow! That is awesome! Hopefully this will give me some pointers in the right direction (if
> it doesn't "just work"(tm)).
>
> From reading the script at /usr/bin/nvidia-sleep.sh, it seems that when it happens, I can
> try to change to a console VT, suspend and awaken the driver, then change back, and
> hopefully it will revive the display!
>
> Thanks!

Unfortunately, this didn't work. I still sit with the same problem.

Can anyone point me to some debug settings that I can enable, that will potentially give me some insight into what the two different graphics devices are seeing when this is happening?

i.e. logs that would show e.g. external monitor connected, external monitor disconnected events, graphics wakeup events, etc?

[Rogan Dawes]

> Hi folks,
>
> I have a 43" Samsung Smart TV that I am using as a monitor with a ThinkPad P51,
> running Fedora 35 Workstation Edition. This laptop has a "NVIDIA Corporation GM206GLM
> [Quadro M2200 Mobile] / Mesa Intel® HD Graphics 630 (KBL GT2)" graphics subsystem. As
> far as I can make out, I am using the latest NVidia driver (495.46).
>
> What is unfortunately happening, is that if my laptop goes to sleep, the TV sees that the
> source disappears, and "tries to look for the laptop", repeatedly. This ends up
> waking up the laptop (sometimes), until the TV eventually gives up and turns itself off.
> The problem is then that the laptop no longer detects that the TV is connected to the HDMI
> port, and I have to reboot to allow the laptop to detect the screen again. Xrandr does not
> detect the display if run manually, and the Settings app Displays page also doesn't
> show the TV.

Just to be absolutely clear, it doesn't seem to be a requirement that the TV eventually gives up and turns itself off before the behaviour manifests on my laptop. I have caught it "searching" for a signal (although not cycling between inputs), but I was too late to save my laptop from going into this state where it no longer detects the external display.

Also, I can unplug and replug the HDMI cable, and the TV detects that there is a connection (display changes from "No signal" to a blue background, but eventually goes back to "No signal"), but the laptop does not detect the external display.

Also, if I use a USB-C to HDMI adapter, it does detect the display being connected while in this state, but this is not a great solution because the laptop does not appear to like the USB-C to HDMI adapter being disconnected. This is what I get:

[377553.263099] usb 3-1: USB disconnect, device number 2
[377553.363447] xhci_hcd 0000:3d:00.0: xHCI host controller not responding, assume dead
[377553.363451] xhci_hcd 0000:3d:00.0: HC died; cleaning up
[377553.380937] xhci_hcd 0000:3d:00.0: remove, state 4
[377553.380940] usb usb4: USB disconnect, device number 1
[377553.381199] xhci_hcd 0000:3d:00.0: USB bus 4 deregistered
[377553.381346] xhci_hcd 0000:3d:00.0: remove, state 1
[377553.381349] usb usb3: USB disconnect, device number 1
[377553.381725] xhci_hcd 0000:3d:00.0: Host halt failed, -19
[377553.381729] xhci_hcd 0000:3d:00.0: Host not accessible, reset failed.
[377553.381846] xhci_hcd 0000:3d:00.0: USB bus 3 deregistered
[377553.394128] pci_bus 0000:06: Allocating resources
[377553.394140] pcieport 0000:06:01.0: bridge window [io  0x1000-0x0fff] to [bus 08-3c] add_size 1000
[377553.394143] pcieport 0000:06:02.0: bridge window [io  0x1000-0x0fff] to [bus 3d] add_size 1000
[377553.394144] pcieport 0000:06:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 3d] add_size 200000 add_align 100000
[377553.394146] pcieport 0000:05:00.0: bridge window [io  0x1000-0x0fff] to [bus 06-3d] add_size 3000
[377553.394149] pcieport 0000:05:00.0: BAR 13: no space for [io  size 0x3000]
[377553.394150] pcieport 0000:05:00.0: BAR 13: failed to assign [io  size 0x3000]
[377553.394151] pcieport 0000:05:00.0: BAR 13: no space for [io  size 0x3000]
[377553.394152] pcieport 0000:05:00.0: BAR 13: failed to assign [io  size 0x3000]
[377553.394156] pcieport 0000:06:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[377553.394157] pcieport 0000:06:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[377553.394158] pcieport 0000:06:01.0: BAR 13: no space for [io  size 0x1000]
[377553.394158] pcieport 0000:06:01.0: BAR 13: failed to assign [io  size 0x1000]
[377553.394159] pcieport 0000:06:02.0: BAR 13: no space for [io  size 0x1000]
[377553.394160] pcieport 0000:06:02.0: BAR 13: failed to assign [io  size 0x1000]
[377553.394162] pcieport 0000:06:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[377553.394163] pcieport 0000:06:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[377553.394164] pcieport 0000:06:02.0: BAR 13: no space for [io  size 0x1000]
[377553.394164] pcieport 0000:06:02.0: BAR 13: failed to assign [io  size 0x1000]
[377553.394165] pcieport 0000:06:01.0: BAR 13: no space for [io  size 0x1000]
[377553.394166] pcieport 0000:06:01.0: BAR 13: failed to assign [io  size 0x1000]
[377558.553883] pcieport 0000:06:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[377558.554278] pci_bus 0000:07: busn_res: [bus 07] is released
[377558.554418] pci_bus 0000:08: busn_res: [bus 08-3c] is released
[377558.554530] pci_bus 0000:3d: busn_res: [bus 3d] is released
[377558.554725] pci_bus 0000:06: busn_res: [bus 06-3d] is released

And reconnecting it does nothing immediately, but about two to three minutes later, the USB-C adapter is recognised again:

[377710.601196] pci 0000:05:00.0: [8086:15da] type 01 class 0x060400
[377710.601265] pci 0000:05:00.0: enabling Extended Tags
[377710.601403] pci 0000:05:00.0: supports D1 D2
[377710.601404] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[377710.601672] pcieport 0000:00:1c.4: ASPM: current common clock configuration is inconsistent, reconfiguring
[377710.605116] pci 0000:06:00.0: [8086:15da] type 01 class 0x060400
[377710.605185] pci 0000:06:00.0: enabling Extended Tags
[377710.605322] pci 0000:06:00.0: supports D1 D2
[377710.605323] pci 0000:06:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[377710.605576] pci 0000:06:01.0: [8086:15da] type 01 class 0x060400
[377710.605644] pci 0000:06:01.0: enabling Extended Tags
[377710.605776] pci 0000:06:01.0: supports D1 D2
[377710.605778] pci 0000:06:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[377710.606003] pci 0000:06:02.0: [8086:15da] type 01 class 0x060400
[377710.606073] pci 0000:06:02.0: enabling Extended Tags
[377710.606203] pci 0000:06:02.0: supports D1 D2
[377710.606205] pci 0000:06:02.0: PME# supported from D0 D1 D2 D3hot D3cold
[377710.606444] pci 0000:05:00.0: PCI bridge to [bus 06-3d]
[377710.606457] pci 0000:05:00.0:   bridge window [mem 0xd4000000-0xea0fffff]
[377710.606465] pci 0000:05:00.0:   bridge window [mem 0x2fc0000000-0x2fe1ffffff 64bit pref]
[377710.606523] pci 0000:06:00.0: PCI bridge to [bus 07]
[377710.606535] pci 0000:06:00.0:   bridge window [mem 0xea000000-0xea0fffff]
[377710.606612] pci 0000:06:01.0: PCI bridge to [bus 08-3c]
[377710.606625] pci 0000:06:01.0:   bridge window [mem 0xd4000000-0xe9efffff]
[377710.606633] pci 0000:06:01.0:   bridge window [mem 0x2fc0000000-0x2fe1ffffff 64bit pref]
[377710.606735] pci 0000:3d:00.0: [8086:15db] type 00 class 0x0c0330
[377710.606763] pci 0000:3d:00.0: reg 0x10: [mem 0xe9f00000-0xe9f0ffff]
[377710.606838] pci 0000:3d:00.0: enabling Extended Tags
[377710.606978] pci 0000:3d:00.0: supports D1 D2
[377710.606980] pci 0000:3d:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[377710.607090] pci 0000:3d:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:06:02.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[377710.607317] pci 0000:06:02.0: PCI bridge to [bus 3d]
[377710.607330] pci 0000:06:02.0:   bridge window [mem 0xe9f00000-0xe9ffffff]
[377710.607368] pci_bus 0000:06: Allocating resources
[377710.607386] pci 0000:06:01.0: bridge window [io  0x1000-0x0fff] to [bus 08-3c] add_size 1000
[377710.607389] pci 0000:06:02.0: bridge window [io  0x1000-0x0fff] to [bus 3d] add_size 1000
[377710.607392] pci 0000:06:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 3d] add_size 200000 add_align 100000
[377710.607395] pci 0000:05:00.0: bridge window [io  0x1000-0x0fff] to [bus 06-3d] add_size 3000
[377710.607399] pci 0000:05:00.0: BAR 13: no space for [io  size 0x3000]
[377710.607401] pci 0000:05:00.0: BAR 13: failed to assign [io  size 0x3000]
[377710.607403] pci 0000:05:00.0: BAR 13: no space for [io  size 0x3000]
[377710.607405] pci 0000:05:00.0: BAR 13: failed to assign [io  size 0x3000]
[377710.607410] pci 0000:06:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[377710.607411] pci 0000:06:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[377710.607413] pci 0000:06:01.0: BAR 13: no space for [io  size 0x1000]
[377710.607415] pci 0000:06:01.0: BAR 13: failed to assign [io  size 0x1000]
[377710.607416] pci 0000:06:02.0: BAR 13: no space for [io  size 0x1000]
[377710.607418] pci 0000:06:02.0: BAR 13: failed to assign [io  size 0x1000]
[377710.607421] pci 0000:06:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
[377710.607423] pci 0000:06:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
[377710.607425] pci 0000:06:02.0: BAR 13: no space for [io  size 0x1000]
[377710.607426] pci 0000:06:02.0: BAR 13: failed to assign [io  size 0x1000]
[377710.607428] pci 0000:06:01.0: BAR 13: no space for [io  size 0x1000]
[377710.607430] pci 0000:06:01.0: BAR 13: failed to assign [io  size 0x1000]
[377710.607432] pci 0000:06:00.0: PCI bridge to [bus 07]
[377710.607438] pci 0000:06:00.0:   bridge window [mem 0xea000000-0xea0fffff]
[377710.607449] pci 0000:06:01.0: PCI bridge to [bus 08-3c]
[377710.607455] pci 0000:06:01.0:   bridge window [mem 0xd4000000-0xe9efffff]
[377710.607459] pci 0000:06:01.0:   bridge window [mem 0x2fc0000000-0x2fe1ffffff 64bit pref]
[377710.607468] pci 0000:06:02.0: PCI bridge to [bus 3d]
[377710.607474] pci 0000:06:02.0:   bridge window [mem 0xe9f00000-0xe9ffffff]
[377710.607489] pci 0000:05:00.0: PCI bridge to [bus 06-3d]
[377710.607495] pci 0000:05:00.0:   bridge window [mem 0xd4000000-0xea0fffff]
[377710.607502] pci 0000:05:00.0:   bridge window [mem 0x2fc0000000-0x2fe1ffffff 64bit pref]
[377710.609138] xhci_hcd 0000:3d:00.0: xHCI Host Controller
[377710.609281] xhci_hcd 0000:3d:00.0: new USB bus registered, assigned bus number 3
[377710.610442] xhci_hcd 0000:3d:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x0000000200009810
[377710.610740] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.15
[377710.610743] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[377710.610744] usb usb3: Product: xHCI Host Controller
[377710.610746] usb usb3: Manufacturer: Linux 5.15.14-200.fc35.x86_64 xhci-hcd
[377710.610747] usb usb3: SerialNumber: 0000:3d:00.0
[377710.610910] hub 3-0:1.0: USB hub found
[377710.610932] hub 3-0:1.0: 2 ports detected
[377710.611391] xhci_hcd 0000:3d:00.0: xHCI Host Controller
[377710.611489] xhci_hcd 0000:3d:00.0: new USB bus registered, assigned bus number 4
[377710.611494] xhci_hcd 0000:3d:00.0: Host supports USB 3.1 Enhanced SuperSpeed
[377710.611551] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.15
[377710.611554] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[377710.611555] usb usb4: Product: xHCI Host Controller
[377710.611557] usb usb4: Manufacturer: Linux 5.15.14-200.fc35.x86_64 xhci-hcd
[377710.611558] usb usb4: SerialNumber: 0000:3d:00.0
[377710.611887] hub 4-0:1.0: USB hub found
[377710.611904] hub 4-0:1.0: 2 ports detected
[377711.244021] usb 3-1: new full-speed USB device number 2 using xhci_hcd
[377711.370890] usb 3-1: not running at top speed; connect to a high speed hub
[377711.375024] usb 3-1: New USB device found, idVendor=9636, idProduct=9300, bcdDevice= 2.01
[377711.375032] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[377711.375036] usb 3-1: Product: USB C Video Adaptor      
[377711.375039] usb 3-1: Manufacturer: WinUSB 
[377711.375041] usb 3-1: SerialNumber: 000000000001

and the display is recognised, and I am back in business. So perhaps this would be a reasonable workaround, but I'd really like to get to the bottom of the original problem.
> Can anyone give me pointers on how I can start debugging this? I am fairly technical, so
> can certainly follow instructions. I'm guessing I need to enable verbose logging for
> the driver so it can report when new displays are connected or disconnected, as well as
> any actions around those events?

Or perhaps there is a better mailing list (graphics driver focused) that I should be sending these reports to?

Thanks

Rogan
P.S. Any idea why I can only see these messages on the HyperKitty list interface, rather than getting them in my email?