Hello, I’ve recently updated my system (twice?) about a few days ago after running without any for a few months, installed/updated/changed around a thousand or 2 packages and ran into the issue where my secondary monitor is now no longer displaying anything. I’ve tried changing brightness levels for my monitors before and that seemed to fix it temporarily but the issue is back again; made sure to do another dist-upgrade update today and that has done nothing to fix the issue.
To note my system used x11 previously before the update and is now on wayland; realized just recently as well that I have not been reading the initial warning on dup commands telling me to change my repos and now am confused as to whether or not I’m actually using the correct packages for my system at this point in time. I’d like to know if I need to do anything to fix this and if using zypper mr -da > zypper ar > zypper dup is the correct way to go as advised here going forward.
As a side question, I’ve tried looking at manpages (just recently looked at the one for zypper) and whilst I can mostly locate arguments just fine on my own, I’ve had cases where I needed the search function and have found that Konsole just doesn’t seem able to locate anything beyond what’s currently displayed on screen; is there a setting to fix this or am I just going to have to get a different emulator (like tmux)? I’ve had to look on online man pages because of this which I don’t prefer. Thanks in advance.
I’m not sure if this is related, but since the 7.2 kernel upgrade my main (laptop) monitor is black. I’ve been using Wayland for years. The strange thing is, the screen is powered up, just nothing is displayed. The mouse can be moved onto that blank screen. If I go to Display Settings and change something (doesn’t seem to matter what), the screen starts working normally.
According to your inxi -GSaz output, you have 3 identical displays and one almost identical, all of which are working. Which of the 4 is “no longer displaying”?
The z option is what filters away the serial numbers. Running without it we could see that they are not, which could additionally confirm that you indeed have 4, besides the 4 reported positions.
According to your inxi -GSaz output, you have 3 identical displays and one almost identical, all of which are working. Which of the 4 is “no longer displaying”?
Ah, right. Should’ve clarified; it’s the 2nd displayport monitor, the top right one.
The z option is what filters away the serial numbers. Running without it we could see that they are not, which could additionally confirm that you indeed have 4, besides the 4 reported positions.
I’m not entirely familiar with the privacy standpoint of serial numbers and just simply added the -z argument out of good practice so I’ll just post the inxi -GSa output here.
Have you tried re-seating all 4 video cables?
Tried taking out and putting back in and even switching them around, did not work.
had the output going for 10+ minutes, kernel and udev both kept printing out change /devices/faux/regulatory (faux) .
Likewise, create a test user, login as the test user and confirm DP-2 is also not working…
I imagine you’re just wanting me to double check that I don’t have any native package conflicts? Either way, followed your advice and it seems to be the same result even on another user.
Just to clarify - did you have the udevadm command running before you unplugged and replugged DP-2? The events should be instant, and generate output similar to this…
~> udevadm monitor --kernel --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[47148.628578] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
UDEV [47148.638606] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
KERNEL[47151.242589] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
UDEV [47151.244253] change /devices/pci0000:00/0000:00:02.0/drm/card1 (drm)
Also, try swapping the affected monitor’s DP cable with one from a working monitor. Does the problem follows the cable or remain with DP-2?
Just to clarify - did you have the udevadm command running before you unplugged and replugged DP-2? The events should be instant, and generate output similar to this…
Yeah so your intuition is correct, I managed to completely blank on the sentence where you told me to unplug and replug whilst debugging; here’s the actual output:
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[4577.851361] change /devices/pci0000:00/0000:00:03.1/0000:08:00.0/0000:09:00.0/0000:0a:00.0/drm/card1 (drm)
UDEV [4577.860093] change /devices/pci0000:00/0000:00:03.1/0000:08:00.0/0000:09:00.0/0000:0a:00.0/drm/card1 (drm)
KERNEL[4585.717049] change /devices/pci0000:00/0000:00:03.1/0000:08:00.0/0000:09:00.0/0000:0a:00.0/drm/card1 (drm)
UDEV [4585.727180] change /devices/pci0000:00/0000:00:03.1/0000:08:00.0/0000:09:00.0/0000:0a:00.0/drm/card1 (drm)
Also, try swapping the affected monitor’s DP cable with one from a working monitor. Does the problem follows the cable or remain with DP-2?
The monitor still remains without proper display even when changing which cable is connected to it
Just to confirm, did you connect the affected monitor to a DP port that is known to work with another monitor, using the cable from that working monitor? If so, and it still remains blank, I’d suspect the monitor itself.
Just to confirm, did you connect the affected monitor to a DP port that is known to work with another monitor, using the cable from that working monitor? If so, and it still remains blank, I’d suspect the monitor itself.
You are correct. So do I have to continue debugging or is this specifically a hardware issue with the affected monitor?
This should be obvious to you now - if your testing shows that regardless of output and cable used, that monitor has no output, then one must conclude a hardware issue with the monitor itself.