Black Screen or no signal on resume

seth · 2025-09-14 13:58:46

Also, as already mentioned, Windows has no such oddity at all.

It's likely a race condition on the handshake (DP and HDMI cables aren't passive copper, there're tiny computers in each plug) - so getting superfluous hops out of the way allows us to eliminate that variable.

Can you please post the entire X11 log for the incident in #25?

As for networkd, you've NetworkManager enabled and are not supposed to run multiple network configuration daemons (on the same NIC) as they will in doubt just trip over each other.
https://wiki.archlinux.org/title/Networ … k_managers - see the blue note.

Azuredas · 2025-09-14 15:45:44

A little update on my situation. Plasma seems to have it's own interesting issues when resuming on occasion. It will resume with a locked refresh rate of 60 or lower and it wouldn't let me open a steam game until I did a restart. I tried logging off and logging back in, but it didn't work until I did a full restart. It also made my colors over saturated when I had hdr enabled. Mostly plasma seems to work pretty well though and it at least will always give me a display or I can get one to come up without having to reboot. I had some free time so I reinstalled gnome next to plasma. I read that if I setup a second user account for it that it shouldn't cause me issues. So I did some testing on gnome based on what you asked and here is what I found.

I mean like "one second" (the plan is to prevent the monitor from responding to the DPMS by powering down, though that won't lead to a solution, because that's the whole point of DPMS)
Do you btw. have a different monitor you could test?

When I interrupt the monitor when it's "Scanning for signal" before entering power save it seems to resume pretty consistently. I also seem to have no issue resuming from my monitor's power save on x11. Could this be a wayland specific issue? I do have another monitor that I was using prior to this that had zero issues, but it's just a 60hz monitor.

Can you ssh into the compromised system?
https://man.archlinux.org/man/gdctl.1 - check the condition and try to change the mode (eg. from 240Hz to 120Hz or 60Hz or whatever is available)

I did this and it said it didn't see any monitors when I tried

gdctl show

Also when I try to reboot through ssh it doesn't work and I have to kill the power and power it back on to reboot.

pswiatki · 2025-09-14 16:15:58

seth wrote:

Also, as already mentioned, Windows has no such oddity at all.
It's likely a race condition on the handshake (DP and HDMI cables aren't passive copper, there're tiny computers in each plug) - so getting superfluous hops out of the way allows us to eliminate that variable.

Sure, I understand (I am an embedded software engineer, so hear you loud and clear). So, will switch to direct HDMI on the notebook and report back. Interesting what you say about DP and HDMI (if I read you correctly): my understanding so far was that HDMI-to-DP was an active cable. Even DP-to-HDMI was passive (same with HDMI-HDMI or DP-DP, right?) Sure, there may be line drivers, serializers/deserializers and whatnot, but those are not parts of the cable itself. This comment seems to summarise the whole thing quite well.

seth wrote:

Can you please post the entire X11 log for the incident in #25?

Sure, I uploaded the file to the usual place.
The main issue (AOC going to sleep without a suspend / resume of the system!) happened between 23039.898 and 41897.694.

seth wrote:

As for networkd, you've NetworkManager enabled and are not supposed to run multiple network configuration daemons (on the same NIC) as they will in doubt just trip over each other.
https://wiki.archlinux.org/title/Networ … k_managers - see the blue note.

That's what I kind of suspected when you turned my attention to systemd-networkd. I wasn't aware it was enabled and active. Will correct it promptly, thanks for letting me know!

ps: quick qestion on formatting in the post: can I inline monospace text (like [ code ] but a single phrase only, not the whole section)?

Last edited by pswiatki (2025-09-14 16:20:23)

pswiatki · 2025-09-14 16:28:19

pswiatki wrote:

Yes, all of them are attached to the dock. HPs are DP (1 normal, 1 mini-DP), while AOC is HDMI.

I think I wasn't clear on the above. I took an extra step to make sure I only go DP-DP-DP (src-kvm-sink) and HDMI-HDMI-HDMI. No mixing, no DP switching to HDMI mode to drive an HDMI sink.
All of these displays are multi-input, and I selected the inputs on each of them for the above (no mixing) to be true for all three of the video sinks.

Last edited by pswiatki (2025-09-14 16:28:44)

seth · 2025-09-14 19:13:31

there may be line drivers, serializers/deserializers and whatnot

which is all very relevant wrt the time critical HDCP handshake
Also probably every hub (your dock and the kvm switch) acts as a repeater.

can I inline monospace text

Nope, unfortunately not.

Back on topic: the eDP responds to the TTY switch, the other outputs don't (they don't display the console at all?) and no output other change is recognized after the initial setup.

nb.:

[    15.463] (II) modeset(0): Manufacturer: LGD  Model: 684  Serial#: 0

[    15.523] (II) modeset(0): Manufacturer: HWP  Model: 26f9  Serial#: 16843009
[    15.523] (II) modeset(0): Buggy monitor, no preferred refresh rate given

[    15.760] (II) modeset(0): Manufacturer: AOC  Model: 2702  Serial#: 9288

[    15.780] (II) modeset(0): Manufacturer: HWP  Model: 26f9  Serial#: 16843009
[    15.780] (II) modeset(0): Buggy monitor, no preferred refresh rate given

pswiatki · 2025-09-14 22:43:25

seth wrote:

there may be line drivers, serializers/deserializers and whatnot
which is all very relevant wrt the time critical HDCP handshake
Also probably every hub (your dock and the kvm switch) acts as a repeater.

Got it! Just to make it clear: my cables are passive, they were too cheap to contain any fancy electronics inside the connectors.

seth wrote:

Back on topic: the eDP responds to the TTY switch, the other outputs don't (they don't display the console at all?) and no output other change is recognized after the initial setup.

nb.:

[    15.463] (II) modeset(0): Manufacturer: LGD  Model: 684  Serial#: 0

[    15.523] (II) modeset(0): Manufacturer: HWP  Model: 26f9  Serial#: 16843009
[    15.523] (II) modeset(0): Buggy monitor, no preferred refresh rate given

[    15.760] (II) modeset(0): Manufacturer: AOC  Model: 2702  Serial#: 9288

[    15.780] (II) modeset(0): Manufacturer: HWP  Model: 26f9  Serial#: 16843009
[    15.780] (II) modeset(0): Buggy monitor, no preferred refresh rate given

What does it mean? What I get is: soon after I switch to VT, I get clones of a console on each and every display. All of them activate and remain active (most of the time, at least!) after switching back to X.
Strangely, one of the HPs got stubborn somewhat and kept switching off after restoring to normal operation. I restored it via: xrandr --output DP-1-2 --mode 0x9f or 0x587 (mode added manually, lower frame rate of 58 Hz)
The latest Xorg log is here: http://0x0.st/Kcmo.txt

seth wrote:

can I inline monospace text
Nope, unfortunately not.

Thank you. So now I know. Such a pity.

Last edited by pswiatki (2025-09-14 22:56:35)

seth · 2025-09-15 08:22:20

The EDIDs of the both HWP outputs (afaiu main troublemakers) are reported to have buggy monitors despite

  Detailed Timing Descriptors:
    DTD 1:  1920x1200   59.950171 Hz  16:10    74.038 kHz    154.000000 MHz (546 mm x 352 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   6 Vback   26 Vpol N
    Display Product Name: 'HP LP2475w'

idkw, "Buggy monitor, no preferred refresh rate given" has 9 hits on google (including this thread…)
https://linux-hardware.org/?probe=294fe … xorg.log.1 has your exact model, most others seem to be Dell.

https://wiki.archlinux.org/title/Xrandr … esolutions

Modeline "1920x1200_59.95" 154.000  1920 1968 2000 2080  1200 1203 1209 1235  +HSync -VSync

for DP-1-2 and DP-2-2
Have you btw. meantime tried the behavior on a direct connection?

pswiatki · 2025-09-15 20:17:56

Dear @seth! It seems I have to use a special dictionary to read your special acronyms (afaiu, wrt, idkw, etc.), which I am not immediately familiar with (English is not my native language). But that's OK - I learn something every day.

Now, since it turned out AOC has also given me some grief very recently, and it was the easiest one to switch directly to the notebook's internal HDMI, I just did it and testing. Will report when ready. Also, when I only switched cables, xrandr did show the video modes and EDID for the HDMI port, but no video and the monitor did not show up under xrandr --listmonitors. Instead, it kept holding on to the port that is in the docking station (if I am not mistaken, no HDMI appeared on the list back then, so it seems like the HDMI connector in the dock is recognized as DP - if that is at all possible; but I will double check that to be absolutely sure). I had to reboot to get the AOC working on direct connection to the notebook (with those two HPs still going through the dock). For now, I have a working setup, but have to suspend / resume to see if the issue appears again. Will let you know.

seth wrote:

The EDIDs of the both HWP outputs (afaiu main troublemakers) are reported to have buggy monitors despite
  Detailed Timing Descriptors:
    DTD 1:  1920x1200   59.950171 Hz  16:10    74.038 kHz    154.000000 MHz (546 mm x 352 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   6 Vback   26 Vpol N
    Display Product Name: 'HP LP2475w'
idkw, "Buggy monitor, no preferred refresh rate given" has 9 hits on google (including this thread…)
https://linux-hardware.org/?probe=294fe … xorg.log.1 has your exact model, most others seem to be Dell.
https://wiki.archlinux.org/title/Xrandr … esolutions
Modeline "1920x1200_59.95" 154.000  1920 1968 2000 2080  1200 1203 1209 1235  +HSync -VSync
for DP-1-2 and DP-2-2

Let me check... it seems I got those modes already:

[pswiatki@sdr-aptv ~]$ xrandr --query --verbose | grep -E "(1920x1200)|(1920.*74\.04|1200.*59\.95)"
DP-2-2 connected 1920x1200+0+0 (0x517) normal (normal left inverted right x axis y axis) 546mm x 352mm
  1920x1200 (0x517) 154.000MHz +HSync -VSync *current +preferred
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  74.04KHz
        v: height 1200 start 1203 end 1209 total 1235           clock  59.95Hz
DP-1-2 connected 1920x1200+4480+0 (0x517) normal (normal left inverted right x axis y axis) 546mm x 352mm
  1920x1200 (0x517) 154.000MHz +HSync -VSync *current +preferred
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  74.04KHz
        v: height 1200 start 1203 end 1209 total 1235           clock  59.95Hz

...but will read the links regardless. Thank you for the info.

pswiatki · 2025-09-15 20:27:28

pswiatki wrote:

For now, I have a working setup, but have to suspend / resume to see if the issue appears again. Will let you know.

By the way, if I were to verify those HPs on a direct connection, I could only do it on HDMI (using another input in the monitor), so I am not sure such a test would be relevant at all (too great a change, I think).

That said: I have another PC on that kvm (reason why I decided to use a kvm). The situation there is much different. All DP port (so one must translate to HDMI, because the kvm has 2xDP+1xHDMI per each input section), quite an old nVidia Quadro driving the displays. I experience the same Black Screen situation as @Azuredas, so I will have to check my ssh setup there to be able to connect remotely and look around when this situation happens again. Still, I think I could (blindly) switch to VT and back to restore video on X. Will check that later and confirm.

pswiatki · 2025-09-15 22:39:01

OK, with the HDMI monitor (AOC) hooked up directly to the notebook, upon resume it gets video back very fast - the rest follow shortly after. No issues. The log from X at http://0x0.st/Kc9k.txt. When the system booted up - only the internal LCD and HDMI-connected AOC got enabled and active. The remaining two HPs I xrandr'ed into the desktop as soon as I logged on.

Last edited by pswiatki (2025-09-15 22:40:10)

seth · 2025-09-16 14:00:23

Step #1 - get rid of the KVM.
Do you retain the problem with *only* the dock?

I have to use a special dictionary to read your special acronyms

Sorry
https://www.allacronyms.com/

pswiatki · 2025-09-16 15:38:36

seth wrote:

I have to use a special dictionary to read your special acronyms
Sorry
https://www.allacronyms.com/

Sorry be not - I am OK with it. Just so that I know the meaning precisely - I must seek help in a dictionary. So far, I found (more like: matched) words that fit perfectly in the context those acronyms are used, but nevertherless, thanks for the link!

seth wrote:

Step #1 - get rid of the KVM.
Do you retain the problem with *only* the dock?

Sure thing, I shall do that. Will report when ready.

pswiatki · 2025-09-16 17:21:05

pswiatki wrote:

seth wrote:
Step #1 - get rid of the KVM.
Do you retain the problem with *only* the dock?
Sure thing, I shall do that. Will report when ready.

First resume, no KVM, displays connected directly to connectors of the dock - DP_Full_Size (to HP #1), mini-DP (to HP #2), HDMI_Full_Size (AOC). Video resumed successfully on all displays.
Xorg.log: http://0x0.st/Kcvr.txt
As suspected yesterday: the system gets the HDMI on the dock as DP:

[pswiatki@sdr-aptv ~]$ xrandr --listmonitors
Monitors: 4
 0: +*DP-2-1 2560/597x1440/336+1920+0  DP-2-1 (AOC)
 1: +eDP-1 1920/344x1080/194+1920+1440  eDP-1
 2: +DP-1-2 1920/546x1200/352+0+0  DP-1-2 (HP #1)
 3: +DP-2-2 1920/546x1200/352+4480+0  DP-2-2 (HP #2)

So, I presume, the dock translates packets going out of the HDMI (before they reach the connector), or somehow it is DP, but since the only type of cable one can attach is HDMI (and, presumably, the video sink also has HDMI input), the translation happens automagically.

Latest journal: http://0x0.st/Kcvj.txt

I find it perplexing that Windows doesn't have any such problems (even with the KVM) - ©®It Just Works. Also, another crucial difference is that Windows somehow gets the unique ID of the display and retains the configuration (display arrangement). Still, it seems in Linux, these video port identifiers are not always guaranteed to be bound to the correct physical display. Sometimes I experience a reverse of screens (HPs are to the left and right of the centrally mounted AOC). Also, on occasion, a different port name is used (for a given display), and I am forced to create yet another autorandr configuration. Looked as if the video resources were enumerated differently. Recently, though, I have not seen this particular problem any more, so maybe it has been rectified.
By the way:

[pswiatki@sdr-aptv ~]$ autorandr --help
Usage: autorandr [options]

/CUT!!!/
--fingerprint           fingerprint your current hardware setup

What is this option good for and how can I use it to get a stable display setup for my config? man autorandr doesn't provide any clues.

EDIT: just checked. The cables I recently got for this setup are HDCP 2.3 and backward compatible. Not sure if this implies an active cable.

Last edited by pswiatki (2025-09-16 17:51:30)

pswiatki · 2025-09-16 18:04:17

[pswiatki@sdr-aptv ~]$ autorandr --fingerprint 
DP-1-2 00ffffffffffff0022f0f9260101010108140104a5362378eece50a3544c99260f5054a56b808140a900a940b300d100d1c001010101283c80a070b023403020360022602100001a000000fc004850204c5032343735770a2020000000fd0030551e5e15041150d2f858f000000000ff00504c433030373032334d0a20200025
DP-2-1 00ffffffffffff0005e30227482400000b210103803c22782ab3e5ac5048a426115054bfef00d1c081803168317c4568457c6168617c565e00a0a0a029503020350055502100001e000000000000000000000000000000000000000000fc00513237473247340a2020202020000000fd0030901ee63c000a2020202020200152020330f14c101f0514041303120211013f230907078301000065030c00200067d85dc401788000681a000001013090e66fc200a0a0a055503020350055502100001e5aa000a0a0a046503020350055502100001e023a801871382d40582c450055502100001ef03c00d051a0355060883a0055502100001c00000000000000ed
DP-2-2 00ffffffffffff0022f0f926010101011b120104a5362378eece50a3544c99260f5054a56b808140a900a940b300d100010101010101283c80a070b023403020360022602100001a000000fc004850204c5032343735770a2020000000fd0030551e5e15041150d2f858f000000000ff00434e43383237313030310a202000c4
eDP-1 00ffffffffffff0030e4840600000000001e010495221378ea38d5975e598e271c505400000001010101010101010101010101010101293680a070381f403020350058c21000001a572b80a070381f403020350058c21000001a000000fe003535394431803135365746440a000000000000413199001000000a010a202000eb

hmmm..... it seems to be simply EDID. Yeah, I guess that would be enough to identify the display. Question being how I could make use of it.

seth · 2025-09-16 18:39:02

https://man.archlinux.org/man/autorandr.1#l load and save profile should™ do?
Have you so far experienced failures w/o the kvm?
Wrt windows: you could try to "xrandr --output <output> --off" all ouputs and then re-load the autorandr profile to enforce a new handshake?

pswiatki · 2025-09-16 18:46:40

seth wrote:

https://man.archlinux.org/man/autorandr.1#l load and save profile should™ do?
Have you so far experienced failures w/o the kvm?
Wrt windows: you could try to "xrandr --output <output> --off" all ouputs and then re-load the autorandr profile to enforce a new handshake?

Yes, I have been using autorandr for a long time. I was just wondering how that --fingerprint / --match-edid worked. I am guessing the former simply saves the EDIDs, while the latter instructs autorandr to use EDIDs to match displays rather than their names (of video port names?) - but I am not sure.
As for your suggestion with xrandr --off, do I correctly understand this would have to be scripted so that things can happen all the way, even when all the displays are (temporarily) off?

Not enough suspend/resume to be sure I am completely free from the Black Screen, or display initialising and THEN going dark. But no issues so far.

Last edited by pswiatki (2025-09-16 18:48:02)

seth · 2025-09-16 18:51:11

As for your suggestion with xrandr --off, do I correctly understand this would have to be scripted so that things can happen all the way, even when all the displays are (temporarily) off?

Yes, eg. see https://wiki.archlinux.org/title/Power_ … temd_units and you'll probably also need https://gist.github.com/AladW/de1c5676d93d05a5a0e1 unless you're going to hardcode DISPLAY

pswiatki · 2025-09-16 23:16:32

seth wrote:

As for your suggestion with xrandr --off, do I correctly understand this would have to be scripted so that things can happen all the way, even when all the displays are (temporarily) off?
Yes, eg. see https://wiki.archlinux.org/title/Power_ … temd_units and you'll probably also need https://gist.github.com/AladW/de1c5676d93d05a5a0e1 unless you're going to hardcode DISPLAY

OK, thanks! I will read and understand what needs to be done.

BREAKING NEWS: just a few minutes ago, I resumed from s2idle and everything went back to normal with an active screen saver, but seconds after I unlocked the desktop, one of the HPs lost video and a bit later reported No Signal.
I was able to identify the video port, xrandr --off that display, and finally autorandr the matching profile with --force. Also tried --match-edid together with the rest of the options, but I am not sure if that had any significance, as the output of autorandr is strange when this option is used. Things are back to normal.
Xorg.log is at http://0x0.st/Kcgp.txt
Journal is at http://0x0.st/Kcgf.txt

[EDIT 17 Sept, morning] - same display failed upon resume (same scenario as above). Restored by autorandr. Keeps cycling (no picture and several seconds later, picture autorestored). Sometimes the Black Screen stays for long enough for the No Signal pop-up to appear on the screen. Finally, just seconds ago, the Black Screen stayed (no autorestore). Restored by autorandr again. We'll see if this time the operation is successful. I don't see any relevant activity either in the Xorg.log (http://0x0.st/KcUT.txt) or in journal.

[EDIT #2, 17/18 Sept, after midnight] another suspend / resume situation. Interesting one. I saw displays initialising (but no screensaver login prompt yet), the mouse pointer sprinting across displays and disappearing, and finally No Signal on ALL external displays. Going to VT and back restored things and allowed me to get back to the X session. Xorg.log is http://0x0.st/KcCV.txt and the latest is @25391 and later. Don't think it shows anything new.

Last edited by pswiatki (2025-09-17 23:18:01)

pswiatki · 2025-09-18 08:25:48

Peculiar observation this morning: on the display, which misbehaves, I noticed something while this page came back upon recovery from No Signal:

example page which refreshed strangely

The elements of this page, such as tables, their cells, and the content within them, refreshed slowly. This was visible in the form of small triangles, where part of the content inside the "triangle" was already visible, while the outside wasn't yet drawn. Something like this:

strange refresh of the webpage

but maybe those individual sections (rectangles / triangles) were somewhat smaller and the refresh going from top to bottom of the screen (and left to right in each line of blocks / rectangles). I guess, like a regular content refresh, only much slower than normal.
So far, I have not recreated it again.
I wonder if this is something the video driver could be doing (and perhaps, by extension, also fire up link re-negotiations at random moments, every 5-10 minutes or so - those taking several seconds to complete if at all successful and not producing yet another No Signal situation). Buggy driver, or what?

Last edited by pswiatki (2025-09-18 12:47:58)

seth · 2025-09-18 12:50:32

on the display, which misbehaves, I noticed something while this page came back upon recovery from No Signal

Did/does the behavior of the client change at all when you move it to another monitor?

Is this a webpage (design not updated since '96) rendered on a modern browser (ie. w/ HW acceleration)?

Were/are the incidents from/like 17th and 18th mitigable w/ a xrandr --off/autorandr cycle (you might want to put such script on a shortcut to test it blindly) resp. is such cycle currently being implemented via a sleep/resume hook?

pswiatki · 2025-09-18 23:17:31

seth wrote:

on the display, which misbehaves, I noticed something while this page came back upon recovery from No Signal
Did/does the behavior of the client change at all when you move it to another monitor?

I will have to swap cable and check. Will report when ready.

Is this a webpage (design not updated since '96) rendered on a modern browser (ie. w/ HW acceleration)?

yes, it is.

Were/are the incidents from/like 17th and 18th mitigable w/ a xrandr --off/autorandr cycle (you might want to put such script on a shortcut to test it blindly) resp. is such cycle currently being implemented via a sleep/resume hook?

Yes, they are mitigable, but it seems the result is not persistent. I mean: when a No Signal condition is reached, the display can recover on its own after several seconds, and if it doesn't xrandr --off / autorandr kombo brings it back, but it may go Black Screen again right after the kombo, or several seconds later, or even a minute or so later. Once "automagically" stabilised, it works without further interruptions (until the next suspend / resume).

seth · 2025-09-19 09:05:44

or even a minute or so later

wtf?
Some screensaver/locker?
What happens if you completely disable DPMS https://wiki.archlinux.org/title/Displa … figuration (block the extension) - just to see whether the behavior is maybe coming from there?

pswiatki · 2025-09-19 21:46:05

seth wrote:

or even a minute or so later
wtf?
Some screensaver/locker?
What happens if you completely disable DPMS https://wiki.archlinux.org/title/Displa … figuration (block the extension) - just to see whether the behaviour is maybe coming from there?

Yes, that is true (initial expletive ). It frustrates me greatly, too. I just had an incident upon resume where all external displays went Black Screen / No Signal, and I issued the combo commando, and they got restored. Still, one of the HPs that misbehaved previously started misbehaving again.
As far as DPMS - I will try to disable it completely. However, I suppose that when only one out of three external displays goes Black Screen, it cannot be DPMS (could it be acting by targeting a single external display only? Or perhaps, if it were somehow triggered, then all the external displays would continue to sleep?).
Also, I have to swap cables for HPs to see whether it is the left one (that keeps giving me grief now), or it is one of the dock's DP outputs (standard size DP connector in this case). Will post the result as soon as I see something.

pswiatki · 2025-09-19 21:52:27

pswiatki wrote:

As far as DPMS - I will try to disable it completely. However, I suppose that when only one out of three external displays goes Black Screen, it cannot be DPMS [...]

Hmmm.....

[pswiatki@sdr-aptv ~]$ xset q
[....]
Screen Saver:
  prefer blanking:  no    allow exposures:  no
  timeout:  0    cycle:  0
[....]
DPMS (Display Power Management Signaling):
  Standby: 7200    Suspend: 7200    Off: 14400
  DPMS is Disabled

Seems DPMS is already off, right?

pswiatki · 2025-09-19 22:42:55

aaaha!!
One can read at https://wiki.archlinux.org/title/XScree … g_settings

XScreenSaver manages screen blanking and display energy saving (DPMS) independently of X itself and overrides it.

Let me try if it is going to be any different when I disable DPMS in XScreenSaver.

Last edited by pswiatki (2025-09-19 22:54:06)

Arch Linux

#26 2025-09-14 13:58:46

Re: Black Screen or no signal on resume

#27 2025-09-14 15:45:44

Re: Black Screen or no signal on resume

#28 2025-09-14 16:15:58

Re: Black Screen or no signal on resume

#29 2025-09-14 16:28:19

Re: Black Screen or no signal on resume

#30 2025-09-14 19:13:31

Re: Black Screen or no signal on resume

#31 2025-09-14 22:43:25

Re: Black Screen or no signal on resume

#32 2025-09-15 08:22:20

Re: Black Screen or no signal on resume

#33 2025-09-15 20:17:56

Re: Black Screen or no signal on resume

#34 2025-09-15 20:27:28

Re: Black Screen or no signal on resume

#35 2025-09-15 22:39:01

Re: Black Screen or no signal on resume

#36 2025-09-16 14:00:23

Re: Black Screen or no signal on resume

#37 2025-09-16 15:38:36

Re: Black Screen or no signal on resume

#38 2025-09-16 17:21:05

Re: Black Screen or no signal on resume

#39 2025-09-16 18:04:17

Re: Black Screen or no signal on resume

#40 2025-09-16 18:39:02

Re: Black Screen or no signal on resume

#41 2025-09-16 18:46:40

Re: Black Screen or no signal on resume

#42 2025-09-16 18:51:11

Re: Black Screen or no signal on resume

#43 2025-09-16 23:16:32

Re: Black Screen or no signal on resume

#44 2025-09-18 08:25:48

Re: Black Screen or no signal on resume

#45 2025-09-18 12:50:32

Re: Black Screen or no signal on resume

#46 2025-09-18 23:17:31

Re: Black Screen or no signal on resume

#47 2025-09-19 09:05:44

Re: Black Screen or no signal on resume

#48 2025-09-19 21:46:05

Re: Black Screen or no signal on resume

#49 2025-09-19 21:52:27

Re: Black Screen or no signal on resume

#50 2025-09-19 22:42:55

Re: Black Screen or no signal on resume

Board footer