Multimonitor shows black picture on boot

DrMaex · 2021-12-01 08:28:18

Today the second monitor for my arch desktop arrived. Its an Intel i7 6700 with Amd HD 7900 series graphics. I never used dualmonotor on this pc.
The problem: if I boot with one monitor plugged into dp2, everything is fine, when I hotplug (or just physically switch on) the second monitor (dp0), it gets recognized and everything works as expected BUT when I boot with both monitors plugged in I see grub, then some usual startup systemd messages and then I see only a black picture on the secondary monitor and the primary goes off. i tried the xrandr Xsetup method and could see that the script has been executed but with no luck, (I added "date> file.log" at the end). if am am not wrong I am using amdgpu driver, non pro version. Does someone has any idea what I could try? Ah btw, am am using KDE plasma und sddm, everything up to date

Thanks in advance

p.s.
i created also same topic in r/arch reddit click

Last edited by DrMaex (2021-12-02 21:53:22)

seth · 2021-12-01 13:43:04

Can you boot
1. the multi-user.target (2nd link below)?
2. w/ the "nomodeset" kernel parameter?

Please post an xorg log for a "bad" boot, https://wiki.archlinux.org/title/Xorg#General (you can use the tip in the 1st link below)

DrMaex · 2021-12-02 08:56:31

Hi, i have tried your suggestions
1. changing from graphical.target to multi-user.target did not change anything
2. nomodeset stocks at the beginning but after hitting ALT+F3 I can login in terminal (both monitors are showing the same picture)

Here is the log from Xorg filtered with

cat Xorg.0.log.old | grep '(EE) '

[    15.951] (EE) Failed to load module "ati" (module does not exist, 0)
[    15.952] (EE) Failed to load module "fbdev" (module does not exist, 0)
[    15.952] (EE) Failed to load module "vesa" (module does not exist, 0)
[    17.342] (EE) AMDGPU(0): drmmode_do_crtc_dpms cannot get last vblank counter
[    44.719] (EE) AMDGPU(0): failed to set mode: Permission denied
[    44.720] (EE) AMDGPU(0): failed to set mode: Permission denied

~~of course I can provide the whole log i desired (here or pastebin?)~~ Pastebin

Actually to be precise when I boot with both monitors on, I can see a part of the mousearrow on the secondary monitor (most right edge), but the remaining part of both screens is just black and i cant move the mouse

Last edited by DrMaex (2021-12-02 09:01:11)

seth · 2021-12-02 09:00:46

Full log, but since the issue isn't limited to grphical sessions, actually (also) a full system journal ("sudo journalctl -b -1 | curl -F 'f:1=<-' ix.io" will pipe the journal of the previous boot into ix.io)

DrMaex · 2021-12-02 09:11:55

seth wrote:

Full log, but since the issue isn't limited to grphical sessions, actually (also) a full system journal ("sudo journalctl -b -1 | curl -F 'f:1=<-' ix.io" will pipe the journal of the previous boot into ix.io)

http://ix.io/3GL1

*note: ~~regarding the timestamps there will be several reboots, some of them into dark desktop and some of them with my workaround with hotplugging the second monitor~~ sorry, just misunderstood the first line "Journal begins at Wed 2021-03-31 23:43:22", the timestamps are correct

I updated my previous post with the pastebin link

Last edited by DrMaex (2021-12-02 09:13:55)

seth · 2021-12-02 14:54:11

[    44.719] (II) AMDGPU(0): Allocate new frame buffer 2560x1440
[    44.719] (II) AMDGPU(0):  => pitch 10240 bytes
[    44.719] (EE) AMDGPU(0): failed to set mode: Permission denied
[    44.720] (II) AMDGPU(0): Allocate new frame buffer 5120x1440
[    44.720] (II) AMDGPU(0):  => pitch 20480 bytes
[    44.720] (EE) AMDGPU(0): failed to set mode: Permission denied

is because you switched to another VT, insignificant.

Couple of things:
1. https://wiki.archlinux.org/title/Kernel … _KMS_start (the chip doesn't seem late, but hey)
2. You're running amdgpu on a southern island chip - do you have the same problem w/ the radeon module?
3. Remove all xf86-video-* packages and run the chip on the modesetting driver

Now, the conditions here are slightly weird, because it works when the output gets attached later but the chip isn't late and normally I'd now blame SDDM, but apparently the issue exists w/ the multi-user.target as well?
(How exactly did you go about that? The journal doesn't cover such attempt)

i tried the xrandr Xsetup method

Can you please elaborate on that (what exact xrandr call did you place where)?

DrMaex · 2021-12-02 21:26:25

seth wrote:

Couple of things:
1. https://wiki.archlinux.org/title/Kernel … _KMS_start (the chip doesn't seem late, but hey)

I had already (amdgpu radeon) in my mkinitcpio.conf, removing radeon didnt help, removing amdgpu also did not

seth wrote:

2. You're running amdgpu on a southern island chip - do you have the same problem w/ the radeon module?

After setting Driver "radeon" the system stocked at boot again but with ALT+F3 i could login into terminal

seth wrote:

3. Remove all xf86-video-* packages and run the chip on the modesetting driver

i tried to remove xf86-video-amdgpu (had no others there) and tried to boot with nomodeset as kernel parameter, did not work also, same behavior like 2.

seth wrote:

Now, the conditions here are slightly weird, because it works when the output gets attached later but the chip isn't late and normally I'd now blame SDDM, but apparently the issue exists w/ the multi-user.target as well?
(How exactly did you go about that? The journal doesn't cover such attempt)

i disabled sddm (couldn't uninstall it because of a dependecy) and installed and enabled lightdm and gtk greeter and the system behaved better. Although i still had only one monitor i could login on the secondary display and could even see the secondary display (no taskbar and previously opened browser windows existed on the primiary display, which i then grabbed blindly and moved to secondary display).
The xrandr Xsetup is what i have seen on this blog -> https://blog.victormendonca.com/2018/06 … e-screens/

DrMaex · 2021-12-02 21:30:56

~~I could solve it,~~ the solution didnt work
anything i needed was to add some additional Sections to the xorg.conf

cat /etc/X11/xorg.conf.d/20-amdgpu.conf 
Section "Device"
     Identifier "AMD"
     Driver "amdgpu"
     Option "DisplayPort-2" "dell"
     Option "DisplayPort-0" "benq"
 EndSection

Section "Monitor"
        Identifier "dell"
EndSection

Section "Monitor"
        Identifier "benq"
        Option "Right Of" "dell"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device "AMD"
        Monitor "dell"
        Monitor "benq"
EndSection

Additionally the xrandr Xsetup script should be executed at the start

cat /usr/share/sddm/scripts/Xsetup 
#!/bin/sh
# Xsetup - run as root before the login dialog appears

xrandr --output DisplayPort-2 --primary --mode 2560x1440 --rotate normal
xrandr --output DisplayPort-0  --mode 2560x1440 --pos 2560x0 --rotate normal

cat /etc/sddm.conf
[XDisplay]
# Xsetup script path
# A script to execute when starting the display server
DisplayCommand=/usr/share/sddm/scripts/Xsetup

and dont forget to make the script executable

maybe not all of them are needed but at this point am am afraid to touch anything

thank you for your help, the feeling that someone is trying to help motivated me to continue the research

Last edited by DrMaex (2021-12-02 22:12:14)

seth · 2021-12-02 21:36:19

removing radeon didnt help, removing amdgpu also did not

If anything it would make things worse, so please undo that.

tried to remove xf86-video-amdgpu (had no others there) and tried to boot with nomodeset as kernel parameter

"nomodeset" prevents kernel modesetting what for pratical purposes prevents any graphical display servers - what you experience is the GUI trying to start on the active VT, but failing (hence you can login on the other VT)
=> "nomodeset" was only meant to see whether we could get access to the outputs at all - it is not something you want to use and mutually exclusive w/ the other tests.

i disabled sddm (couldn't uninstall it because of a dependecy) and installed and enabled lightdm and gtk greeter and the system behaved better.

What strongly suggests it's SDDM and the multi-usert.target test was perhaps conducted improperly.

The xrandr Xsetup is what i have seen on this blog

Verbatim?
/usr/share/sddm/scripts/Xsetup should™ be the default setup script anyway and the xrandr calls presented there will most likely fail - if you didn't properly adjust the parameters.
Please post the /usr/share/sddm/scripts/Xsetup you created as well as the output of "xrandr -q" w/ both outputs attached.

DrMaex · 2021-12-02 22:23:58

i posted the contents of the Xsetup in post nr 8

just for the test I changed one Displayport from 2 to 1, in case you should wonder why the numbers from previous posts don't match, so now 1 is primary and 0 is secondary

here is the output of xrandr -q

xrandr -q
Screen 0: minimum 320 x 200, current 5119 x 1440, maximum 16384 x 16384
DisplayPort-0 connected 2560x1440+2559+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     59.95*+
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   832x624       74.55  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
DisplayPort-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     59.95*+
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-D-1 disconnected (normal left inverted right x axis y axis)

seth · 2021-12-02 22:42:34

Section "Monitor"
        Identifier "DisplayPort-2"
        Option  "Enable"        "True"
        Option  "Primary"       "True"
EndSection

Section "Monitor"
        Identifier "DisplayPort-0"
        Option "Right Of" "DisplayPort-2"
        Option  "Enable"        "True"
EndSection

But they should™ be initially enabled no matter what and this would be overwritten by the sddm Xsetup script.
What aspect did you initially believe to have solved (sddm, lightdm, plasma session) - and why did it not solve it in fact?

DrMaex · 2021-12-03 10:58:07

seth wrote:

But they should™ be initially enabled no matter what and this would be overwritten by the sddm Xsetup script.
What aspect did you initially believe to have solved (sddm, lightdm, plasma session) - and why did it not solve it in fact?

Well I feel that I close to the solution. Yesterday, when i thought it was solved, was after i added the monitor and Screen section to my xorg config the pc booted as expected, with both monitors on, but after restart i had again same behavior as before (actually it happened to me twice yesterday) the second time when i commented out "MinimumVT=7"

cat /etc/sddm.conf.d/tty.conf 
#[X11]
#MinimumVT=7

Now the behavior is following: When I boot with both monitors on, i see only a splashscreen of KDE on secondary screen but then nothing happens (the difference now is that i see the splashscreen), i am able to enter terminal (tty3) with ALT+CTRL+F3
If I boot only with Monitor connected to DisplayPort-1 (my primary) the system boots properly, after hotplugging the secondary monitor (DisplayPort-0), both of them are usable.

you say

But they should™ be initially enabled no matter what and this would be overwritten by the sddm Xsetup script.

i disagree, the contents of my xorg config does matter, it is now:

cat /etc/X11/xorg.conf.d/20-amdgpu.conf 
Section "Device"
     Identifier "AMD"
     Driver "amdgpu"
     Option "DisplayPort-0" "benq"
     Option "DisplayPort-1" "dell"
 EndSection

Section "Monitor"
        Identifier "dell"
#       Option  "Enable" "True"
#       Option  "Primary" "True"
EndSection

Section "Monitor"
        Identifier "benq"
        Option "Right Of" "dell"
#       Option "Enable" "True"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device "AMD"
        Monitor "dell"
        Monitor "benq"
EndSection

if I activate the primary and enabled options i get again different behavior:

when i boot with one monitor on (primary) i get only a black screen, but when i hotplug my secondary monitor, they both go on and work as expected, its like the whole X11 is delayed until both monitors are available.
if i boot with both monitors on, i am again stuck at splashcreen on secondary monitor...
could i be a timining issue? my whoole xorg config is in the file "/etc/X11/xorg.conf.d/20-amdgpu.conf"

also there is a difference between being black because monitor goes off and showing "active black" picture and staying on but i cant say now from memory when i get which behavior...

seth · 2021-12-03 13:54:47

When I boot with both monitors on, i see only a splashscreen of KDE on secondary screen but then nothing happens

Do you autologin?

DrMaex · 2021-12-03 13:56:19

seth wrote:

When I boot with both monitors on, i see only a splashscreen of KDE on secondary screen but then nothing happens
Do you autologin?

yes, i do

seth · 2021-12-03 14:04:03

What if you don't?
The issue is more likely w/ kscreen then, trying to be overly smart.
Try to remove its configurations, https://wiki.archlinux.org/title/KDE#Un … lution_set

DrMaex · 2021-12-03 22:06:50

seth wrote:

What if you don't?
The issue is more likely w/ kscreen then, trying to be overly smart.
Try to remove its configurations, https://wiki.archlinux.org/title/KDE#Un … lution_set

We are getting closer, when i disable autologin, i get the login prompt on secondary screen) and can even login and use the system, the primary monitor is active black....
xrandr shows interesting values, it seems like both Displayports are displayed at the same coordinates

xrandr -q
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     59.95*+
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   832x624       74.55  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
DisplayPort-1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     59.95*+
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-D-1 disconnected (normal left inverted right x axis y axis)

i couldnt find any obvious configs of kscreen, only names which were looking like temporary files, like huge hash values....

seth · 2021-12-04 08:29:20

The display config in SDDM will be impacted by the xorg configlet and the SDDM Xsetup script.
Since this is a dynamic setup, I'd drop the xorg configlet and in the sddm Xsetup script only arrange the optional output (sth. like "xrandr --output DisplayPort-2 --primary --auto --left-of DisplayPort-0")

As for kscreen, just remove all the configuration files you find there (outside the kde session, ie. first log out, log into a different VT and from that console clean up the kscreen configuration)
There've been recently more reports about kscreen messing around. Search the forum for "kscreen" and my username…

DrMaex · 2021-12-04 22:26:16

ok, i am giving up now. I cleaned the kscreen folder from terminal after selecting CTRL+ALT+F3. removed all sections from xorg.conf except of the device section and enabled autologin. As long as hotplugging works as expected I have to accept, that i only need to remember to switch off the secondary monitor while booting.
Its not the solution i am proud of but its one that works
Thank you very much for your time, hopefully its just a matter of some configs playing against each other and next clean install will magically fix it

seth · 2021-12-05 08:43:42

There's nothing such as magic.

1. Try to disable the compositor after the login, you might be running into a race condition between kwin and kscreen (Shift+Alt+F12 toggles it)
2. You could try to use a KDE autostart script, https://wiki.archlinux.org/title/KDE#Autostart - it must run *after* kscreen (or anythine else in the session) ruined the setup.

#!/bin/sh
xrandr --output DisplayPort-0 --auto # this will enable DisplayPort-0 w/ the default resolution
xrandr --output DisplayPort-2 --primary --auto --left-of DisplayPort-0 # this will do the same for DisplayPort-2 and position it left of DisplayPort-0 and make it the primary output - iff it exists

DrMaex · 2021-12-05 21:33:41

seth wrote:

There's nothing such as magic.
1. Try to disable the compositor after the login, you might be running into a race condition between kwin and kscreen (Shift+Alt+F12 toggles it)
2. You could try to use a KDE autostart script, https://wiki.archlinux.org/title/KDE#Autostart - it must run *after* kscreen (or anythine else in the session) ruined the setup.
#!/bin/sh
xrandr --output DisplayPort-0 --auto # this will enable DisplayPort-0 w/ the default resolution
xrandr --output DisplayPort-2 --primary --auto --left-of DisplayPort-0 # this will do the same for DisplayPort-2 and position it left of DisplayPort-0 and make it the primary output - iff it exists

I have tried the second point: disabled the Xsetup script which was run by SDDM and added setup_monitors.sh script in .config/plasma-workspace/env actually with the same content which i had in Xsetup before (also same as you provided, only wich adjusted DisplayPort enumerators), it also get executed but it doesn't help.
i didnt understadn what you mean with the first point, After stucked at splash screen (when i boot with both monitors on) i tried to press CTRL+ALT+F12 and got black screen with only a blinking cursor and couldnt do anything except of CTRL+ALT+F3 and then reboot after terminal login.

seth · 2021-12-05 21:47:24

i tried to press CTRL+ALT+F12

seth wrote:

SHIFT+Alt+F12

It turns of the thing that makes shadows and transparency.

DrMaex · 2021-12-06 21:17:12

seth wrote:

SHIFT+Alt+F12
turns of the thing that makes shadows and transparency.

oh my bad, mixed them up, how can i check that it worked? Nothing happens when press SHIFT+ALT+F12

seth · 2021-12-06 22:25:57

qdbus org.kde.KWin /KWin supportInformation

will print a lot of stuff about the WM, including whether the compositor is active.
My hope was that the output is actually active and only "black" because the kwin GL view doesn't extend there (on the theory that kwin starts when only one output is active, configures the gl view and misses that another output became available before it starts monitoring randr events) - in that case the "black" output would show the desktop.
What makes me think: how "black" is it actually? Can you move the mouse cursor and maybe even some windows there?

DrMaex · 2021-12-07 10:45:01

seth wrote:

qdbus org.kde.KWin /KWin supportInformation
will print a lot of stuff about the WM, including whether the compositor is active.
My hope was that the output is actually active and only "black" because the kwin GL view doesn't extend there (on the theory that kwin starts when only one output is active, configures the gl view and misses that another output became available before it starts monitoring randr events) - in that case the "black" output would show the desktop.
What makes me think: how "black" is it actually? Can you move the mouse cursor and maybe even some windows there?

The Display is completely black but monitor is active and I can even move windows into the black monitor or get them back but the picture is just black, like a black curtain over working desktop. no mouse, nothing.
Here is the output of the state with one black monitor
Pastebin.

Edit:
here is another output when booted with one monitor and hotplugged the second
Pastebin_2

they are identical...

i had today again a case when I booted with both monitors on and it worked, I think it it a timing problem of some parts, maybe even the energy saving modes of the display hardware, because they flicker(go to standby and then wake up again) while boot. maybe there is some kind of presence request and they don't service it fast enough or something

Last edited by DrMaex (2021-12-07 10:53:09)

seth · 2021-12-07 14:37:37

Compositing is not active

So that's not it

Since the output is already enabled, what if you turn them off before?

#!/bin/sh
xrandr --output DisplayPort-0 --off # only one of those is likely necessary - the one for the black output
xrandr --output DisplayPort-0 --auto
xrandr --output DisplayPort-2 --off
xrandr --output DisplayPort-2 --primary --auto --left-of DisplayPort-0

Arch Linux

#1 2021-12-01 08:28:18

Multimonitor shows black picture on boot

#2 2021-12-01 13:43:04

Re: Multimonitor shows black picture on boot

#3 2021-12-02 08:56:31

Re: Multimonitor shows black picture on boot

#4 2021-12-02 09:00:46

Re: Multimonitor shows black picture on boot

#5 2021-12-02 09:11:55

Re: Multimonitor shows black picture on boot

#6 2021-12-02 14:54:11

Re: Multimonitor shows black picture on boot

#7 2021-12-02 21:26:25

Re: Multimonitor shows black picture on boot

#8 2021-12-02 21:30:56

Re: Multimonitor shows black picture on boot

#9 2021-12-02 21:36:19

Re: Multimonitor shows black picture on boot

#10 2021-12-02 22:23:58

Re: Multimonitor shows black picture on boot

#11 2021-12-02 22:42:34

Re: Multimonitor shows black picture on boot

#12 2021-12-03 10:58:07

Re: Multimonitor shows black picture on boot

#13 2021-12-03 13:54:47

Re: Multimonitor shows black picture on boot

#14 2021-12-03 13:56:19

Re: Multimonitor shows black picture on boot

#15 2021-12-03 14:04:03

Re: Multimonitor shows black picture on boot

#16 2021-12-03 22:06:50

Re: Multimonitor shows black picture on boot

#17 2021-12-04 08:29:20

Re: Multimonitor shows black picture on boot

#18 2021-12-04 22:26:16

Re: Multimonitor shows black picture on boot

#19 2021-12-05 08:43:42

Re: Multimonitor shows black picture on boot

#20 2021-12-05 21:33:41

Re: Multimonitor shows black picture on boot

#21 2021-12-05 21:47:24

Re: Multimonitor shows black picture on boot

#22 2021-12-06 21:17:12

Re: Multimonitor shows black picture on boot

#23 2021-12-06 22:25:57

Re: Multimonitor shows black picture on boot

#24 2021-12-07 10:45:01

Re: Multimonitor shows black picture on boot

#25 2021-12-07 14:37:37

Re: Multimonitor shows black picture on boot

Board footer