X virtual frame buffer

Roger Oberholtzer

16 May 2022 16 May '22

12:10

I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X). When there is no display attached, X does not start. I wanted to install xf86-video-dummy, but it complains: error: Failed dependencies: X11_ABI_VIDEODRV = 25.2 is needed by xf86-video-dummy-0.4.0-lp153.24.1.x86_64 So I am guessing that X on 15.3 has recently changed the ABI. The installed xf86-video-* were built on May 2019. Note that these were still the ones that eventually were installed on Feb 2022. Unfortunately I did not install the dummy driver at that time. The change seems recent. As an alternative, I see that one could add some config to X for this. I read mixed things about how that works in terms of systems not booting. I also was considering xrand (xrandr --fb 1280x1024 -display :0). Seems starting that via ssh can be iffy depending on how it is handling X. So I have not been able to test it. If I make it start when the system boots, could it do anything to keep the system from booting? -- Roger Oberholtzer

Show replies by date

David C. Rankin

16 May 16 May

13:55

On 5/16/22 07:10, Roger Oberholtzer wrote:

...

I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start. I wanted to install xf86-video-dummy, but it complains:

error: Failed dependencies: X11_ABI_VIDEODRV = 25.2 is needed by xf86-video-dummy-0.4.0-lp153.24.1.x86_64

Not sure about recent openSUSE changes, but I have always used tigervnc for this purpose. With vncserver running on your headless box and vncviewer on the client, you simply port-forward the display port over ssh and connect with the client. There is a minimal 1-file setup on the headless box, and you need to start the ssh port-forwarding, but then it works seamlessly. I don't game, but for all my purposes, using the remote X is just as fast as sitting down with a hardware display. (even over a wireless connection) openSUSE has had tigervnc as long as I can remember (may have been under a different name in the pre 10.X days), but the same 'vncserver / vncviewer`. -- David C. Rankin, J.D.,P.E.

Andrei Borzenkov

15:26

On 16.05.2022 15:10, Roger Oberholtzer wrote:

...

I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start.

You apparently misunderstand how X11 works. When you are working on a local workstation W and want to start graphical program on remote system R you do not need X server on remote system. You need to tell program on R to use X server on W. If program on R used X server on R you could neither see output nor control it without being physically present at remote site where R is located.

...

I wanted to install xf86-video-dummy, but it complains:

error: Failed dependencies: X11_ABI_VIDEODRV = 25.2 is needed by xf86-video-dummy-0.4.0-lp153.24.1.x86_64

So I am guessing that X on 15.3 has recently changed the ABI. The installed xf86-video-* were built on May 2019. Note that these were still the ones that eventually were installed on Feb 2022. Unfortunately I did not install the dummy driver at that time. The change seems recent.

As an alternative, I see that one could add some config to X for this. I read mixed things about how that works in terms of systems not booting.

I also was considering xrand (xrandr --fb 1280x1024 -display :0). Seems starting that via ssh can be iffy depending on how it is handling X. So I have not been able to test it. If I make it start when the system boots, could it do anything to keep the system from booting?

Adam Mizerski

19:16

W dniu 16.05.2022 o 17:26, Andrei Borzenkov pisze:

...

On 16.05.2022 15:10, Roger Oberholtzer wrote:

...
I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start.

You apparently misunderstand how X11 works. When you are working on a local workstation W and want to start graphical program on remote system R you do not need X server on remote system. You need to tell program on R to use X server on W. If program on R used X server on R you could neither see output nor control it without being physically present at remote site where R is located.

I think you apparently misunderstand what Roger wants to achieve. He wants to start an X server on remote system R and run an application on it. From workstation W he would connect to this X server using for example VNC. Btw, there is a package xorg-x11-Xvnc, which contains Xvnc exactly for that. The downside is that it provides no graphic acceleration even if there is a graphics card attached to the machine.

Roger Oberholtzer

17 May 17 May

06:36

I am using x11vnc. It is managed via xinetd with this command, which is run when a client connects: exec /usr/bin/x11vnc -inetd -rfbauth /etc/vncpasswd -o /var/log/x11vnc.log -display :0 -auth /var/lib/xdm/authdir/authfiles/*:0* -env FD_XDM=1 -shared -forever It expects to access whatever is running on DISPLAY :0. So, if someone is doing something on :0, we share the desktop. On Mon, May 16, 2022 at 9:17 PM Adam Mizerski wrote:

...

W dniu 16.05.2022 o 17:26, Andrei Borzenkov pisze:

...
On 16.05.2022 15:10, Roger Oberholtzer wrote:

...
I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start.

You apparently misunderstand how X11 works. When you are working on a local workstation W and want to start graphical program on remote system R you do not need X server on remote system. You need to tell program on R to use X server on W. If program on R used X server on R you could neither see output nor control it without being physically present at remote site where R is located.

I think you apparently misunderstand what Roger wants to achieve. He wants to start an X server on remote system R and run an application on it. From workstation W he would connect to this X server using for example VNC.

I am using

...

Btw, there is a package xorg-x11-Xvnc, which contains Xvnc exactly for that. The downside is that it provides no graphic acceleration even if there is a graphics card attached to the machine.

-- Roger Oberholtzer

Roger Oberholtzer

06:29

On Mon, May 16, 2022 at 5:27 PM Andrei Borzenkov wrote:

...

On 16.05.2022 15:10, Roger Oberholtzer wrote:

...
I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start.

You apparently misunderstand how X11 works. When you are working on a local workstation W and want to start graphical program on remote system R you do not need X server on remote system. You need to tell program on R to use X server on W. If program on R used X server on R you could neither see output nor control it without being physically present at remote site where R is located.

You would be surprised how well I know X. Both as a user of X apps, and as a writer of them back in the Xt/Motif days. Not to mention the way I manage X apps via Tcl/Tk. I want the remote system to run the complete KDE desktop. I want remote access to that desktop. I do not want to run a single remote X app to be displayed locally. I want it all. And this includes the initial X login screen. -- Roger Oberholtzer

Andrei Borzenkov

15:10

On 16.05.2022 15:10, Roger Oberholtzer wrote:

...

I have a headless 15.3 system that I would like to access remotely. I need access to the desktop (i.e. X).

When there is no display attached, X does not start. I wanted to install xf86-video-dummy, but it complains:

error: Failed dependencies: X11_ABI_VIDEODRV = 25.2 is needed by xf86-video-dummy-0.4.0-lp153.24.1.x86_64

So I am guessing that X on 15.3 has recently changed the ABI. The

No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it: bor@leap15:~> sudo zypper in xf86-video-dummy [sudo] password for root: Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: xf86-video-dummy 1 new package to install. Overall download size: 23.8 KiB. Already cached: 0 B. After the operation, additional 45.3 KiB will be used. Continue? [y/n/v/...? shows all options] (y): n bor@leap15:~>

...

installed xf86-video-* were built on May 2019. Note that these were still the ones that eventually were installed on Feb 2022. Unfortunately I did not install the dummy driver at that time. The change seems recent.

As an alternative, I see that one could add some config to X for this. I read mixed things about how that works in terms of systems not booting.

I also was considering xrand (xrandr --fb 1280x1024 -display :0). Seems starting that via ssh can be iffy depending on how it is handling X. So I have not been able to test it. If I make it start when the system boots, could it do anything to keep the system from booting?

Roger Oberholtzer

19 May 19 May

06:26

On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov wrote:

...

No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it:

Not a different repository. But yes, it seems to be a different RPM. It all stems from how https://software.opensuse.org/ no longer shows packages for 15.3. And the repository one winds up at has these RPMs. I was perhaps fooled by the lp153 in the name. Anyway, I have now added the package. That only installs a dummy driver. There seems not to be any configuration that causes this driver to be used. I guess I need to make one. The question is: how will this work when there really is a display connected (which there usually won't be - but I need to know), I have seen this as a suggestion: Section "Device" Identifier "Configured Video Device" Driver "dummy" EndSection Section "Monitor" Identifier "Configured Monitor" HorizSync 31.5-48.5 VertRefresh 50-70 EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection I would imagine that the dummy driver will always be enabled. I would prefer it is only done when no real display is found. -- Roger Oberholtzer

Andrei Borzenkov

16:58

On 19.05.2022 09:26, Roger Oberholtzer wrote:

...

On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov wrote:

...
No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it:

Not a different repository. But yes, it seems to be a different RPM.

So you say that you installed from openSUSE repositories package that does not exist in these repositories? May wonders never cease ...

...

It all stems from how https://software.opensuse.org/ no longer shows packages for 15.3.

But openSUSE release manager officially declared that this problem is fixed! Wait ... yes, it is back. Guess what - distribution ID changed again. Whack-a-mole ...

...

And the repository one winds up at has these RPMs. I was perhaps fooled by the lp153 in the name.

What's in a name ... nothing prevents anyone from building newer version of Xorg (drivers) for Leap 15.3. This still does not make it part of Leap 15.3

...

Anyway, I have now added the package. That only installs a dummy driver. There seems not to be any configuration that causes this driver to be used. I guess I need to make one. The question is: how will this work when there really is a display connected (which there usually won't be - but I need to know),

It won't work. This is rather basic question from someone who claimed to be X11 expert. Each X11 program is tied to specific display. Each display is handled by specific driver selected when Xorg server starts. So if you start your program under display driven by dummy driver you can never see it on display driven by driver for your physical card and vice versa. Why do you need dummy driver if you already have Xserver running on remote system?

...

I have seen this as a suggestion:

Section "Device" Identifier "Configured Video Device" Driver "dummy" EndSection

Section "Monitor" Identifier "Configured Monitor" HorizSync 31.5-48.5 VertRefresh 50-70 EndSection

Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection

I would imagine that the dummy driver will always be enabled. I would prefer it is only done when no real display is found.

Roger Oberholtzer

20 May 20 May

06:08

I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3. On Thu, May 19, 2022 at 6:59 PM Andrei Borzenkov wrote:

...

On 19.05.2022 09:26, Roger Oberholtzer wrote:

...
On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov wrote:

...
No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it:

Not a different repository. But yes, it seems to be a different RPM.

So you say that you installed from openSUSE repositories package that does not exist in these repositories? May wonders never cease ...

I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3. If it was compatible with the other RPMs that I already have installed is of course a different question. I admit I wound up trying to use the wrong RPM. So thanks for pointing that out.

...

...
It all stems from how https://software.opensuse.org/ no longer shows packages for 15.3.

But openSUSE release manager officially declared that this problem is fixed! Wait ... yes, it is back. Guess what - distribution ID changed again. Whack-a-mole ...

Yes. The issue is back. I am glad to hear that it was being worked on. It is an extremely useful feature.

...

...
And the repository one winds up at has these RPMs. I was perhaps fooled by the lp153 in the name.

What's in a name ... nothing prevents anyone from building newer version of Xorg (drivers) for Leap 15.3. This still does not make it part of Leap 15.3

...
Anyway, I have now added the package. That only installs a dummy driver. There seems not to be any configuration that causes this driver to be used. I guess I need to make one. The question is: how will this work when there really is a display connected (which there usually won't be - but I need to know),

It won't work. This is rather basic question from someone who claimed to be X11 expert.

I am not at all confused. I use virtual displays like this in other ways. Like this to make a program that wants but does not need an X server when wanting to run that program in a Makefile: @Xvfb :1000 -screen 0 800x600x24 >/dev/null 2>&1 & @DISPLAY=:1000 $(INNO) /Q "Y:/source/Tools_GUI/tcltk/win32/installable/tcltk.iss" Access is totally defined by the port (i.e., DISPLAY) on which you connect. As a remote user, that is all I can specify. You cannot ask for remote access by referencing the hardware on which it runs. I cannot tell vncviewer to connect to the remote display that has some specific display attached. I have to know which DISPLAY instance that is and use that reference. But all this is irrelevant. After installing the dummy driver, there is still no X running because it still wants some X configuration for this. Without that, it does not even load the dummy driver.

...

Each X11 program is tied to specific display. Each display is handled by specific driver selected when Xorg server starts. So if you start your program under display driven by dummy driver you can never see it on display driven by driver for your physical card and vice versa.

But all of this is irrelevant if the X server does not start. There is no DISPLAY to connect to. That is what I am trying to make work when there is no display connected to the video card.

...

Why do you need dummy driver if you already have Xserver running on remote system?

I suspect that this is the core reason for your confusion. I thought I was clear. There is no X server running when there is no display connected. If there is a display connected, it starts just fine. In previous versions of Leap (42.3, 15.1) this was not the case. The X server still started. With a smaller display size. But it started. In 15.3 it no longer starts. That is what I am trying to change.

...

...
I have seen this as a suggestion:

Section "Device" Identifier "Configured Video Device" Driver "dummy" EndSection

Section "Monitor" Identifier "Configured Monitor" HorizSync 31.5-48.5 VertRefresh 50-70 EndSection

Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection

I would imagine that the dummy driver will always be enabled. I would prefer it is only done when no real display is found.

I do not see any reference to the dummy driver in the X log. The log just complains that there is no display defined. So, to restate my original question: How can I define that a server should start when there is no physical display attached? In such a way that this does not happen if there is a physical display? -- Roger Oberholtzer

Roger Oberholtzer

24 May 24 May

13:16

I finally have access to the X server log. This is what it prints when there is no display connected: [ 20.026] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 20.026] (--) NVIDIA(0): CRT-0 (boot) [ 20.026] (--) NVIDIA(0): CRT-1 [ 20.026] (--) NVIDIA(0): DFP-0 [ 20.026] (--) NVIDIA(0): DFP-1 [ 20.027] (II) NVIDIA(0): NVIDIA GPU GeForce GT 610 (GF119) at PCI:1:0:0 (GPU-0) [ 20.027] (--) NVIDIA(0): Memory: 1048576 kBytes [ 20.027] (--) NVIDIA(0): VideoBIOS: 75.19.55.00.02 [ 20.027] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 20.040] (--) NVIDIA(GPU-0): CRT-0: disconnected [ 20.040] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock [ 20.040] (--) NVIDIA(GPU-0): [ 20.041] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 20.041] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 20.041] (--) NVIDIA(GPU-0): [ 20.057] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 20.057] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 20.057] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 20.058] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 20.058] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0. [ 20.058] (EE) NVIDIA(0): Set AllowEmptyInitialConfiguration if you want the server [ 20.058] (EE) NVIDIA(0): to start anyway [ 20.058] (EE) NVIDIA(0): Failing initialization of X screen 0 [ 20.132] (II) UnloadModule: "nvidia" [ 20.132] (II) UnloadSubModule: "wfb" [ 20.132] (II) UnloadSubModule: "fb" [ 20.132] (EE) Screen(s) found, but none have a usable configuration. [ 20.132] (EE) Fatal server error: [ 20.132] (EE) no screens found(EE) [ 20.132] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 20.132] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 20.132] (EE) [ 20.165] (EE) Server terminated with error (1). Closing log file. On a different system, running the same X server release for Leap 15.3, but with a different NVIDIA GPU, X starts when a display is not connected. I then see this in the log: [ 1484.907] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 1484.907] (--) NVIDIA(0): DFP-0 [ 1484.907] (--) NVIDIA(0): DFP-1 [ 1484.907] (--) NVIDIA(0): DFP-2 [ 1484.907] (--) NVIDIA(0): DFP-3 [ 1484.907] (--) NVIDIA(0): DFP-4 [ 1484.907] (--) NVIDIA(0): DFP-5 [ 1484.907] (--) NVIDIA(0): DFP-6 [ 1484.908] (**) NVIDIA(0): Using ConnectedMonitor string "DFP-0". [ 1484.908] (II) NVIDIA(0): NVIDIA GPU NVIDIA GeForce GTX 1660 (TU116-A) at PCI:1:0:0 [ 1484.908] (II) NVIDIA(0): (GPU-0) [ 1484.908] (--) NVIDIA(0): Memory: 6291456 kBytes [ 1484.908] (--) NVIDIA(0): VideoBIOS: 90.16.34.00.7a [ 1484.908] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): connected [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): Internal DisplayPort [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): 2660.0 MHz maximum pixel clock [ 1484.908] (--) NVIDIA(GPU-0): Could it be that when there is no physical display connected, the second system's GPU makes it look like there is (at least on DFP-0)? There really is nothing connected. On Fri, May 20, 2022 at 8:08 AM Roger Oberholtzer wrote:

...

I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3.

On Thu, May 19, 2022 at 6:59 PM Andrei Borzenkov wrote:

...
On 19.05.2022 09:26, Roger Oberholtzer wrote:

...
On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov wrote:

...
No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it:

Not a different repository. But yes, it seems to be a different RPM.

So you say that you installed from openSUSE repositories package that does not exist in these repositories? May wonders never cease ...

I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3. If it was compatible with the other RPMs that I already have installed is of course a different question. I admit I wound up trying to use the wrong RPM. So thanks for pointing that out.

...
...
It all stems from how https://software.opensuse.org/ no longer shows packages for 15.3.

But openSUSE release manager officially declared that this problem is fixed! Wait ... yes, it is back. Guess what - distribution ID changed again. Whack-a-mole ...

Yes. The issue is back. I am glad to hear that it was being worked on. It is an extremely useful feature.

...
...
And the repository one winds up at has these RPMs. I was perhaps fooled by the lp153 in the name.

What's in a name ... nothing prevents anyone from building newer version of Xorg (drivers) for Leap 15.3. This still does not make it part of Leap 15.3

...
Anyway, I have now added the package. That only installs a dummy driver. There seems not to be any configuration that causes this driver to be used. I guess I need to make one. The question is: how will this work when there really is a display connected (which there usually won't be - but I need to know),

It won't work. This is rather basic question from someone who claimed to be X11 expert.

I am not at all confused. I use virtual displays like this in other ways. Like this to make a program that wants but does not need an X server when wanting to run that program in a Makefile:

@Xvfb :1000 -screen 0 800x600x24 >/dev/null 2>&1 & @DISPLAY=:1000 $(INNO) /Q "Y:/source/Tools_GUI/tcltk/win32/installable/tcltk.iss"

Access is totally defined by the port (i.e., DISPLAY) on which you connect. As a remote user, that is all I can specify. You cannot ask for remote access by referencing the hardware on which it runs. I cannot tell vncviewer to connect to the remote display that has some specific display attached. I have to know which DISPLAY instance that is and use that reference.

But all this is irrelevant. After installing the dummy driver, there is still no X running because it still wants some X configuration for this. Without that, it does not even load the dummy driver.

...
Each X11 program is tied to specific display. Each display is handled by specific driver selected when Xorg server starts. So if you start your program under display driven by dummy driver you can never see it on display driven by driver for your physical card and vice versa.

But all of this is irrelevant if the X server does not start. There is no DISPLAY to connect to. That is what I am trying to make work when there is no display connected to the video card.

...
Why do you need dummy driver if you already have Xserver running on remote system?

I suspect that this is the core reason for your confusion. I thought I was clear. There is no X server running when there is no display connected. If there is a display connected, it starts just fine. In previous versions of Leap (42.3, 15.1) this was not the case. The X server still started. With a smaller display size. But it started. In 15.3 it no longer starts. That is what I am trying to change.

...
...
I have seen this as a suggestion:

Section "Device" Identifier "Configured Video Device" Driver "dummy" EndSection

Section "Monitor" Identifier "Configured Monitor" HorizSync 31.5-48.5 VertRefresh 50-70 EndSection

Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection

I would imagine that the dummy driver will always be enabled. I would prefer it is only done when no real display is found.

I do not see any reference to the dummy driver in the X log. The log just complains that there is no display defined.

So, to restate my original question: How can I define that a server should start when there is no physical display attached? In such a way that this does not happen if there is a physical display?

-- Roger Oberholtzer

-- Roger Oberholtzer

Dave Howorth

14:09

On Tue, 24 May 2022 15:16:33 +0200 Roger Oberholtzer wrote:

...

I finally have access to the X server log. This is what it prints when there is no display connected:

[ 20.026] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 20.026] (--) NVIDIA(0): CRT-0 (boot) [ 20.026] (--) NVIDIA(0): CRT-1 [ 20.026] (--) NVIDIA(0): DFP-0 [ 20.026] (--) NVIDIA(0): DFP-1 [ 20.027] (II) NVIDIA(0): NVIDIA GPU GeForce GT 610 (GF119) at PCI:1:0:0 (GPU-0) [ 20.027] (--) NVIDIA(0): Memory: 1048576 kBytes [ 20.027] (--) NVIDIA(0): VideoBIOS: 75.19.55.00.02 [ 20.027] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 20.040] (--) NVIDIA(GPU-0): CRT-0: disconnected [ 20.040] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock [ 20.040] (--) NVIDIA(GPU-0): [ 20.041] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 20.041] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 20.041] (--) NVIDIA(GPU-0): [ 20.057] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 20.057] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 20.057] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 20.058] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 20.058] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0. [ 20.058] (EE) NVIDIA(0): Set AllowEmptyInitialConfiguration if you want the server [ 20.058] (EE) NVIDIA(0): to start anyway

Aren't the above three lines the important part? Just do what it says! It is described on https://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/xconfigoption... I don't use nvidia myself, so I can't speak to anything else.

...

[ 20.058] (EE) NVIDIA(0): Failing initialization of X screen 0 [ 20.132] (II) UnloadModule: "nvidia" [ 20.132] (II) UnloadSubModule: "wfb" [ 20.132] (II) UnloadSubModule: "fb" [ 20.132] (EE) Screen(s) found, but none have a usable configuration. [ 20.132] (EE) Fatal server error: [ 20.132] (EE) no screens found(EE) [ 20.132] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 20.132] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 20.132] (EE) [ 20.165] (EE) Server terminated with error (1). Closing log file.

On a different system, running the same X server release for Leap 15.3, but with a different NVIDIA GPU, X starts when a display is not connected. I then see this in the log:

[ 1484.907] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 1484.907] (--) NVIDIA(0): DFP-0 [ 1484.907] (--) NVIDIA(0): DFP-1 [ 1484.907] (--) NVIDIA(0): DFP-2 [ 1484.907] (--) NVIDIA(0): DFP-3 [ 1484.907] (--) NVIDIA(0): DFP-4 [ 1484.907] (--) NVIDIA(0): DFP-5 [ 1484.907] (--) NVIDIA(0): DFP-6 [ 1484.908] (**) NVIDIA(0): Using ConnectedMonitor string "DFP-0". [ 1484.908] (II) NVIDIA(0): NVIDIA GPU NVIDIA GeForce GTX 1660 (TU116-A) at PCI:1:0:0 [ 1484.908] (II) NVIDIA(0): (GPU-0) [ 1484.908] (--) NVIDIA(0): Memory: 6291456 kBytes [ 1484.908] (--) NVIDIA(0): VideoBIOS: 90.16.34.00.7a [ 1484.908] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): connected [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): Internal DisplayPort [ 1484.908] (--) NVIDIA(GPU-0): AU Optronics Corporation (DFP-0): 2660.0 MHz maximum pixel clock [ 1484.908] (--) NVIDIA(GPU-0):

Could it be that when there is no physical display connected, the second system's GPU makes it look like there is (at least on DFP-0)? There really is nothing connected.

On Fri, May 20, 2022 at 8:08 AM Roger Oberholtzer wrote:

...
I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3.

On Thu, May 19, 2022 at 6:59 PM Andrei Borzenkov wrote:

...
On 19.05.2022 09:26, Roger Oberholtzer wrote:

...
On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov wrote:

...
No, you are using some third party repository with drivers built against newer Xorg release. The version that comes with openSUSE Leap 15.3 is 0.3.8-4.10 and zypper has no issues installing it:

Not a different repository. But yes, it seems to be a different RPM.

So you say that you installed from openSUSE repositories package that does not exist in these repositories? May wonders never cease ...

I did not say that at all. What I said was that the software search at https://software.opensuse.org/ does not list packages for 15.3. It only has older releases and Tumbleweed. Never anything for the current leap release. So one must look around for the package in the various repositories. When looking for RPMs, it seems that the RPM name for a leap release typically contains, say, lp15.3 in the name. Ones for Tumbleweed do not contain this. So when I saw an RPM with lp153 in the name, I maintain that it was totally logical to assume that it was targeted for 15.3. If it was compatible with the other RPMs that I already have installed is of course a different question. I admit I wound up trying to use the wrong RPM. So thanks for pointing that out.

...
...
It all stems from how https://software.opensuse.org/ no longer shows packages for 15.3.

But openSUSE release manager officially declared that this problem is fixed! Wait ... yes, it is back. Guess what - distribution ID changed again. Whack-a-mole ...

Yes. The issue is back. I am glad to hear that it was being worked on. It is an extremely useful feature.

...
...
And the repository one winds up at has these RPMs. I was perhaps fooled by the lp153 in the name.

What's in a name ... nothing prevents anyone from building newer version of Xorg (drivers) for Leap 15.3. This still does not make it part of Leap 15.3

...
Anyway, I have now added the package. That only installs a dummy driver. There seems not to be any configuration that causes this driver to be used. I guess I need to make one. The question is: how will this work when there really is a display connected (which there usually won't be - but I need to know),

It won't work. This is rather basic question from someone who claimed to be X11 expert.

I am not at all confused. I use virtual displays like this in other ways. Like this to make a program that wants but does not need an X server when wanting to run that program in a Makefile:

@Xvfb :1000 -screen 0 800x600x24 >/dev/null 2>&1 & @DISPLAY=:1000 $(INNO) /Q "Y:/source/Tools_GUI/tcltk/win32/installable/tcltk.iss"

Access is totally defined by the port (i.e., DISPLAY) on which you connect. As a remote user, that is all I can specify. You cannot ask for remote access by referencing the hardware on which it runs. I cannot tell vncviewer to connect to the remote display that has some specific display attached. I have to know which DISPLAY instance that is and use that reference.

But all this is irrelevant. After installing the dummy driver, there is still no X running because it still wants some X configuration for this. Without that, it does not even load the dummy driver.

...
Each X11 program is tied to specific display. Each display is handled by specific driver selected when Xorg server starts. So if you start your program under display driven by dummy driver you can never see it on display driven by driver for your physical card and vice versa.

But all of this is irrelevant if the X server does not start. There is no DISPLAY to connect to. That is what I am trying to make work when there is no display connected to the video card.

...
Why do you need dummy driver if you already have Xserver running on remote system?

I suspect that this is the core reason for your confusion. I thought I was clear. There is no X server running when there is no display connected. If there is a display connected, it starts just fine. In previous versions of Leap (42.3, 15.1) this was not the case. The X server still started. With a smaller display size. But it started. In 15.3 it no longer starts. That is what I am trying to change.

...
...
I have seen this as a suggestion:

Section "Device" Identifier "Configured Video Device" Driver "dummy" EndSection

Section "Monitor" Identifier "Configured Monitor" HorizSync 31.5-48.5 VertRefresh 50-70 EndSection

Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection

I would imagine that the dummy driver will always be enabled. I would prefer it is only done when no real display is found.

I do not see any reference to the dummy driver in the X log. The log just complains that there is no display defined.

So, to restate my original question: How can I define that a server should start when there is no physical display attached? In such a way that this does not happen if there is a physical display?

-- Roger Oberholtzer

Roger Oberholtzer

25 May 25 May

10:29

On Tue, May 24, 2022 at 4:10 PM Dave Howorth wrote:

...

...
[ 20.026] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 20.026] (--) NVIDIA(0): CRT-0 (boot) [ 20.026] (--) NVIDIA(0): CRT-1 [ 20.026] (--) NVIDIA(0): DFP-0 [ 20.026] (--) NVIDIA(0): DFP-1 [ 20.027] (II) NVIDIA(0): NVIDIA GPU GeForce GT 610 (GF119) at PCI:1:0:0 (GPU-0) [ 20.027] (--) NVIDIA(0): Memory: 1048576 kBytes [ 20.027] (--) NVIDIA(0): VideoBIOS: 75.19.55.00.02 [ 20.027] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 20.040] (--) NVIDIA(GPU-0): CRT-0: disconnected [ 20.040] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock [ 20.040] (--) NVIDIA(GPU-0): [ 20.041] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 20.041] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 20.041] (--) NVIDIA(GPU-0): [ 20.057] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 20.057] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 20.057] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 20.058] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 20.058] (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock [ 20.058] (--) NVIDIA(GPU-0): [ 20.058] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0. [ 20.058] (EE) NVIDIA(0): Set AllowEmptyInitialConfiguration if you want the server [ 20.058] (EE) NVIDIA(0): to start anyway

Aren't the above three lines the important part? Just do what it says! It is described on https://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/xconfigoption...

I don't use nvidia myself, so I can't speak to anything else.

Sort of. If I add that option, the X server and all then start (yeah!). But the display is very small. I had better luck adding a file called /etc/X11/xorg.conf.d/10-headless.conf in which I have put this: Section "Monitor" Identifier "dummy_monitor" HorizSync 28.0-80.0 VertRefresh 48.0-75.0 Modeline "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 EndSection Section "Device" Identifier "dummy_card" VideoRam 256000 Driver "dummy" EndSection Section "Screen" Identifier "dummy_screen" Device "dummy_card" # Option "AllowEmptyInitialConfiguration" "true" Monitor "dummy_monitor" SubSection "Display" EndSubSection EndSection Note that since I wanted to set the size (otherwise it is far too small to use), this resulted in a configuration. So the NVIDIA AllowEmptyInitialConfiguration seems not to be needed. So it is commented out. I see no other way to get a decent size. So, I could consider this closed. Except that I think it would make great sense for the xf86-video-dummy package to include the file above. Perhaps not enabled, but in place so one knows how to actually use the driver it provides. Otherwise it is an incomplete thing. -- Roger Oberholtzer

700

Age (days ago)

709

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Adam Mizerski
Andrei Borzenkov
Dave Howorth
David C. Rankin
Roger Oberholtzer

X virtual frame buffer

tags

participants (5)