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 <arvidjaar@gmail.com> wrote:
On 19.05.2022 09:26, Roger Oberholtzer wrote:
On Tue, May 17, 2022 at 5:10 PM Andrei Borzenkov <arvidjaar@gmail.com> 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