Is there any way to avoid reading the configuration files in
/etc/X11/xorg.conf.d when Xorg is started? I have tried to start Xorg
with the switch -configdir but that only seems to make it possible to
read configuration files from yet another directory, files in
/etc/X11/xorg.conf.d are still being read.

My problem is that I maintain several machines, some with the default
xorg.conf from Slackware and some with an xorg.conf adapted to the nVidia
binary driver. To push X configurations to all these machines files in
xorg.conf.d are used, one of those files is used to set swedish keyboard
layout:

-8<-----------------------
cat /etc/X11/xorg.conf.d/90-keyboard-layout.conf

Section "InputClass"
Identifier "keyboard-all"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "fi"
Option "XkbVariant" "nodeadkeys"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

-8<-----------------------

Now some machines need to run an extra X server headless and any local
user need to be able to connect to that server. This is to run a
calculation application which should be a server application but has been
implemented as a graphical X application.

From rc.local I call a script which starts Xorg on :5 without using any
monitor and it was my intention to also not use any keyboard or mouse for
that X server. Unfortunately my 90-keyboard-layout.conf script somehow
causes the evdev driver to be loaded also for the X server on :5. The
result is that any mouse and keyboard input that is given by the user
sitting on :0 also is sent to :5 and that input might interfere on
applications running on :5. Needless to say this is also a security issue
as any local user could start an application running on :5 which logs
keyboard activity on :0.

Somehow I would need to start X with display :5 without keyboard or mouse
input. I use the switch -config when I start Xorg for :5 to point to a
special xorg.conf.headless, but I have not found any way to avoid
reading /etc/X11/xorg.conf.d/90-keyboard-layout.conf

regards Henrik

On Wed, 9 Jun 2021 21:11:44 -0000 (UTC), Henrik Carlqvist wrote:

> Somehow I would need to start X with display :5 without keyboard or
> mouse input. I use the switch -config when I start Xorg for :5 to point
> to a special xorg.conf.headless, but I have not found any way to avoid
> reading /etc/X11/xorg.conf.d/90-keyboard-layout.conf

Sounds like what you are looking for is a multiseat X setup with a single
(or multiple) X server and multiple X clients were each client, or seat,
has its own X configuration.

It's been 10+ yrs (15?) since I played with this stuff. Might be worth a
look.

https://www.x.org/wiki/Development/Documentation/Multiseat/

On 6/9/21 3:11 PM, Henrik Carlqvist wrote:
> Now some machines need to run an extra X server headless and any
> local user need to be able to connect to that server. This is to run
> a calculation application which should be a server application but
> has been implemented as a graphical X application.

I would try VNC, specifically Xvnc.

Launch a Xvnc server that would be display :5(.something) and point the
calculation application with DISPLAY=:5(.something).

Then when users need to interact with the calculation application, have
them run a VNC viewer and connect to the VNC server that is X11 server
:5(.something).

Maybe this won't work for you. I'd need to know more about your use
case. But this is what I would give the good ol' college try before
tilting at ... tweaking X11.

The Xvnc has the added advantage that it has virtual hardware and is a
virtual head, thus is physically headless.

There are a couple of other VNC like things that play in this space; No
Machine (NxM?) and X2Go come to mind.

--
Grant. . . .
unix || die

On Thu, 10 Jun 2021 05:19:50 +0000, King Beowulf wrote:
> On Wed, 9 Jun 2021 21:11:44 -0000 (UTC), Henrik Carlqvist wrote:
>
>> Somehow I would need to start X with display :5 without keyboard or
>> mouse input. I use the switch -config when I start Xorg for :5 to point
>> to a special xorg.conf.headless, but I have not found any way to avoid
>> reading /etc/X11/xorg.conf.d/90-keyboard-layout.conf
>
> Sounds like what you are looking for is a multiseat X setup with a
> single (or multiple) X server and multiple X clients were each client,
> or seat, has its own X configuration.
>
> It's been 10+ yrs (15?) since I played with this stuff. Might be worth
> a look.
>
> https://www.x.org/wiki/Development/Documentation/Multiseat/

Thanks, yes, my configuration need resembles multiseat. But in practice
it is still only singleseat as one X server is supposed to be running
headless without any monitor, keyboard or mouse. Only an X display to
connect to with some capabilities like OpenGL with some nVidia extensions.

regards Henrik

On Wed, 09 Jun 2021 23:40:05 -0600, Grant Taylor wrote:

> On 6/9/21 3:11 PM, Henrik Carlqvist wrote:
>> Now some machines need to run an extra X server headless and any local
>> user need to be able to connect to that server. This is to run a
>> calculation application which should be a server application but has
>> been implemented as a graphical X application.
>
> I would try VNC, specifically Xvnc.

Thanks, yes, VNC was our first attempt to find a solution.

> Maybe this won't work for you. I'd need to know more about your use
> case. But this is what I would give the good ol' college try before
> tilting at ... tweaking X11.

The trouble with VNC is that the X application needs OpenGL with some
nVidia extensions. So the application failed with VNC. Then I configured
an extra Xorg running on :5 without any monitor. It seemed to work fine
for some weeks, but then they found that the application was disturbed by
keyboard input. That keyboard input was traced to come from the user
sitting at :0 typing at the keyboard.

I realize that I might end up having to edit those configuration files
ending with .c and recompile a custom Xorg. But it would be more
convenient if I somehow could configure the stock Xorg to ignore the
keyboard settings intended for :0.

regards Henrik

On 6/10/21 10:31 AM, Henrik Carlqvist wrote:
> Thanks, yes, VNC was our first attempt to find a solution.

*nod*

> The trouble with VNC is that the X application needs OpenGL with some
> nVidia extensions. So the application failed with VNC.

~sigh~

Ya, that's going to be a blocker.

> Then I configured an extra Xorg running on :5 without any monitor. It
> seemed to work fine for some weeks, but then they found that the
> application was disturbed by keyboard input. That keyboard input was
> traced to come from the user sitting at :0 typing at the keyboard.

*facePALM*

> I realize that I might end up having to edit those configuration files
> ending with .c and recompile a custom Xorg. But it would be more
> convenient if I somehow could configure the stock Xorg to ignore the
> keyboard settings intended for :0.

Ew.

I think my next trick might be to configure virtualization with GPU
pass-through. Run the ornery application in virtualization -- if
performance will allow -- using an additional GPU that is passed through
to the VM. Then use regular VM console clients to connect to the VM
when needed.

Short of that, I may fall back to a dedicated physical machine. I'd do
this mostly out of support ability. How much is your and the end users
time worth? How fragile will the configuration be? Will its urvive
typical OS updates? How much care and feeding do you want to put into
this? It probably won't take much before the dedicated machine would be
more economical.

Aside: I do hate it when there are technical solutions to problems, but
line of business logic decide to go with a different solution for
economical reasons. :-/

--
Grant. . . .
unix || die

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> The trouble with VNC is that the X application needs OpenGL with some
> nVidia extensions. So the application failed with VNC.

If you are having problems with hardware related drivers I would try
running Xnest or Xephyr on top of VNC, and then run the application
inside Xnest/Xephyr.

On Thu, 10 Jun 2021 10:54:46 -0600, Grant Taylor wrote:
> I think my next trick might be to configure virtualization with GPU
> pass-through. Run the ornery application in virtualization -- if
> performance will allow -- using an additional GPU that is passed through
> to the VM. Then use regular VM console clients to connect to the VM
> when needed.

That has been considered. Part of the problem is that "just adding an
extra GPU" in this case is not very cheap as the machine in question has
no free GPU slot and the GPUs in the machine were rather expensive. The
idea was to use the machine for more stuff than just this OpenGL
application, some users should also be able to log in remotely to run
cuda applications.

The machine already has two GPUs, so it would be possible to configure
one GPU for X display :0 and the other GPU for a virtual machine. But the
idea was to have both GPUs accessable by all users for cuda applications.

Also the tricky OpenGL application needs to be able to be run by more
than one user at the same time. That would mean that different users
would not be able to start their own virtual machines, but that all users
would need to connect to the same virtual machine.
> Short of that, I may fall back to a dedicated physical machine. I'd do
> this mostly out of support ability. How much is your and the end users
> time worth? How fragile will the configuration be? Will its urvive
> typical OS updates? How much care and feeding do you want to put into
> this? It probably won't take much before the dedicated machine would be
> more economical.

Yes, one solution would be to configure this machine to not have any X
server running on :0. That would give console users text consoles only,
but it would still be usable for this OpenGL application and cuda
calculations. This machine would then have a configuration that differs
from all other machines in the network and that configuration might break
if I push some update of the startup scripts.

Thanks for your thoughts!

regards Henrik

On Thu, 10 Jun 2021 18:41:57 -0500, Javier wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> The trouble with VNC is that the X application needs OpenGL with some
>> nVidia extensions. So the application failed with VNC.
>
> If you are having problems with hardware related drivers I would try
> running Xnest or Xephyr on top of VNC, and then run the application
> inside Xnest/Xephyr.

Thanks for the suggestion!

The problem is that some GLX features listed by glxinfo on the physical
display :0 on the local machine gets lost with VNC or with X forwarded by
ssh from a remote login. At my initial search for solutions I did
experiment some with Xnest and Xephyr, but did not try to combine them
with VNC. But as the VNC display lacks those OpenGL extensions, would
really Xnest or Xephyr bring them back?

regards Henrik

On 6/10/21 11:25 PM, Henrik Carlqvist wrote:
> The problem is that some GLX features listed by glxinfo on the physical
> display :0 on the local machine gets lost with VNC or with X forwarded
> by ssh from a remote login. At my initial search for solutions I did
> experiment some with Xnest and Xephyr, but did not try to combine
> them with VNC. But as the VNC display lacks those OpenGL extensions,
> would really Xnest or Xephyr bring them back?

This does not surprise me at all.

OpenGL will be a feature of the X /server/. You will have different X
/servers/ for your physical card (with OpenGL and lots of fancy
features), Xvnc, Xnest, and Xephyr.

X forwarding causes software run via the SSH connection to process on
the remote system but talk to the X server on your client system.

You might investigate x11vnc which behaves differently than Xvnc.
x11vnc adds a VNC server (traditional client server nomenclature) to an
existing X server (X11 client server nomenclature). As such, perhaps
you can have the fancy GPU based X servers (X11...) that display a
desktop which can be remotely accessed via x11vnc server (traditional...).

It sounds like you really are tied to the X server associated with the
specific physical GPU card(s). Very little will offer the same features
as specialized cards. So your applications are almost guaranteed to
need to run against that specific X server (graphics hardware & drivers).

Perhaps the other aspects of the system could be run as alternate
displays (X server / graphics hardware & driver) which then reference
the special hardware.

I don't know how you would deal with real time sharing of the GPU based
X server / graphics hardware & driver. But you could definitely have
multiple people take turns using it through x11vnc.

P.S. I'll respond to your other longer email later as time permits.

--
Grant. . . .
unix || die

On Fri, 11 Jun 2021 10:18:13 -0600, Grant Taylor wrote:
> You might investigate x11vnc which behaves differently than Xvnc.
> x11vnc adds a VNC server (traditional client server nomenclature) to an
> existing X server (X11 client server nomenclature). As such, perhaps
> you can have the fancy GPU based X servers (X11...) that display a
> desktop which can be remotely accessed via x11vnc server
> (traditional...).

If I remember right we did also experiment with x11vnc, but then again we
depended upon an X server running on the machine and we did not want
display :0 to be that X server.

Usually display :0 is used by the user at the console, we would not want
other users on the network ssh in to the machine and start windows on
that display, neither using VNC or connecting directly to the display.
> It sounds like you really are tied to the X server associated with the
> specific physical GPU card(s). Very little will offer the same features
> as specialized cards. So your applications are almost guaranteed to
> need to run against that specific X server (graphics hardware &
> drivers).

Yes, we are tied to a specific machine not just because of its GPU, the
OpenGL application also depends upon a license USB dongle and we did
choose to put that dongle in a powerful machine with good GPU capacity.

> Perhaps the other aspects of the system could be run as alternate
> displays (X server / graphics hardware & driver) which then reference
> the special hardware.
>
> I don't know how you would deal with real time sharing of the GPU based
> X server / graphics hardware & driver. But you could definitely have
> multiple people take turns using it through x11vnc.

Yes, we would not want different users connect to a display :0 used by
some local user, but it is OK for us to have a display :5 which allows
any local user to connect and knowing that this :5 only is intended for
this specific application. It would not be a wise idea to share an X
display for random applications, anyone being able to connect to a
display is also able to do things like taking screenshots.

The time sharing works fine, both for OpenGL applications and cuda
applications. With the nVidia binary driver there is a utility called
"nvidia-smi" which shows how GPU processing power and GPU RAM are used by
different applications. If several users run the same application they
will have to share the GPU processing resources making the calculations
slower for all users. There will be a limit on the number of concurrent
users and that limit is set by the amount of GPU RAM.

In a separate post I will write about my current solution to the problem.
The problem is now solved for me, but there might be a better solution.

regards Henrik

On Wed, 09 Jun 2021 21:11:44 +0000, Henrik Carlqvist wrote:

> Is there any way to avoid reading the configuration files in
> /etc/X11/xorg.conf.d when Xorg is started?

Today I spent some hours adding trace prints to the source of Xorg to
find how to modify it for my purpose.

> I have tried to start Xorg with the switch -configdir but that only
> seems to make it possible to read configuration files from yet another
> directory, files in /etc/X11/xorg.conf.d are still being read.

My trace prints showed me that using the switch -configdir did prevent
Xorg to read the files in /etc/X11/xorg.conf.d . Unfortunately that
switch did not prevent Xorg to read the files in
/usr/share/X11/xorg.conf.d and that directory contained a
90-keyboard-layout.conf choosing us keyboard layout and causing all X
servers to read input from keyboard and mouse.

I wrote the following patch for Xorg:
-8<------------------------------------------------------------------
diff -ruN xorg-server-1.18.3.org/hw/xfree86/common/xf86Config.c \
xorg-server-1.18.3.patched/hw/xfree86/common/xf86Config.c
--- xorg-server-1.18.3.org/hw/xfree86/common/xf86Config.c
2016-03-15 17:12:14.000000000 +0100
+++ xorg-server-1.18.3.patched/hw/xfree86/common/xf86Config.c
2021-06-11 15:06:12.767107083 +0200
@@ -2412,8 +2412,11 @@
dirfrom = X_CMDLINE;
xf86initConfigFiles();
- sysdirname = xf86openConfigDirFiles(SYS_CONFIGDIRPATH, NULL,
- PROJECTROOT);
+ if (xf86ConfigDir)
+ sysdirname = NULL;
+ else
+ sysdirname = xf86openConfigDirFiles(SYS_CONFIGDIRPATH, NULL,
+ PROJECTROOT);
dirname = xf86openConfigDirFiles(dirsearch, xf86ConfigDir,
PROJECTROOT);
filename = xf86openConfigFile(filesearch, xf86ConfigFile,
PROJECTROOT);
if (filename) {
-8<------------------------------------------------------------------

The variable xf86ConfigDir is set by the switch -configdir when Xorg is
started, if that variable is set my patch avoids reading files in
/usr/share/X11/xorg.conf.d

This is not some patch that I am going to send upstream or recommend
anyone to use, I only use it to build my own
/usr/local/sbin/Xorg_patched_for_my_purpose binary which I package in a
custom Slackware package together with configuration files and startup
script modifications to start this headless for :5.

At first, when I was experimenting to get a working patch I got a little
confused. I started an extra X server on another virtual console (not
headless) and then used ctrl-alt-f7 to get back to my :0 and read my
trace prints. Once I got close to working source changes ctrl-alt-f7 no
longer worked and I had to remotely ssh into my machine to run "chvt 7".
First I thought that my changes made Xorg bug out, but then I realized
that without a keyboard connection "ctrl-alt-f7" would not work.

After writing this patch it seems to me that it would not be possible to
avoid reading /usr/share/X11/xorg.conf.d without the patch.

Thanks to everyone who has engaged in this question! Other working
solutions would still be interesting.

regards Henrik

On 6/11/21 11:10 AM, Henrik Carlqvist wrote:
> My trace prints showed me that using the switch -configdir
> did prevent Xorg to read the files in /etc/X11/xorg.conf.d
> . Unfortunately that switch did not prevent Xorg to read the
> files in /usr/share/X11/xorg.conf.d and that directory contained a
> 90-keyboard-layout.conf choosing us keyboard layout and causing all
> X servers to read input from keyboard and mouse.

This may be a silly question. But why not remove the files from the
/usr/share/X11/xorg.conf.d and leave it empty?

mv /usr/share/X11/xorg.conf.d/* /etc/X11/xorg.conf.d/.

I'd think that would allow you to use the stock X11 that's shipped with
Slackware.

Granted, you'd need to remember to keep /usr/share/X11/xorg.conf.d empty
across updates (there are hacks). But I'd think that would be easier
than caring for and feeding a custom X11 server.

--
Grant. . . .
unix || die

On Sat, 12 Jun 2021 01:06:11 -0600, Grant Taylor wrote:

> On 6/11/21 11:10 AM, Henrik Carlqvist wrote:
>> My trace prints showed me that using the switch -configdir did prevent
>> Xorg to read the files in /etc/X11/xorg.conf.d . Unfortunately that
>> switch did not prevent Xorg to read the files in
>> /usr/share/X11/xorg.conf.d and that directory contained a
>> 90-keyboard-layout.conf choosing us keyboard layout and causing all X
>> servers to read input from keyboard and mouse.
>
> This may be a silly question. But why not remove the files from the
> /usr/share/X11/xorg.conf.d and leave it empty?
>
> mv /usr/share/X11/xorg.conf.d/* /etc/X11/xorg.conf.d/.
>
> I'd think that would allow you to use the stock X11 that's shipped with
> Slackware.
>
> Granted, you'd need to remember to keep /usr/share/X11/xorg.conf.d empty
> across updates (there are hacks). But I'd think that would be easier
> than caring for and feeding a custom X11 server.

Yes, that would be an option and would still work for display :0 on all
machines. However, as I have 50+ Slackware machines to keep up to date
and only one or two of them are running the software with this special
requirement it seemed easier for me to install an extra custom Xorg on
those few machines.

If I would move around and alter stock configuration files on only a few
machines they would would differ from the other machines in the network.

If I would move around and alter the stock configuration files on all
machines I would make custom changes to a lot of machines which are not
supposed to run the software.

Whenever I do some custom software installation or custom configuration
which differs from the Slackware standard installation I package that
software or configuration in a custom Slackware package.

I have about 250 such custom packages which are installed into every
machine and about 100 such custom packages which are only installed onto
selected machines.

Examples of packages which go into every machines are software like
FreeCAD together with all its dependencies and configurations like
swedish keyboard settings and network connections to a saned server.

Examples of packages which only go into selected machines are now this
custom Xorg together with its startup scripts, nVidia binary drivers of
different versions and drivers for Hasp USB dongles.

All these custom packages might need maintenance and some of those
packages might need reinstallation if some updated Slackware patch
package is installed. However, I try to avoid making packages which alter
things that future patch installations will undo. Many patches contain
configuration files like /etc/something.new and will not overwrite your
own customization of /etc/something.

One day Slackware might come with a patch update that breaks my custom
Xorg, but that day I have the patch file saved in /usr/doc/
Xorg_customized_for_my_purposes and will hopefully be able to rebuild a
newer version of Xorg with that patch or rebuild the current version of
Xorg against newer libraries.

regards Henrik

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> But as the VNC display lacks those OpenGL extensions, would
> really Xnest or Xephyr bring them back?

Yes, you are right. I have been looking at it and Xnest does not
implement OpenGL at all.

$ Xnest :2 &
$ glxinfo -display :2
name of display: :2
Error: couldn't find RGB GLX visual or fbconfig

Xephyr impements OpenGL but it does the rendering by software instead of
talking to the graphics card. There is a fork of Xephyr that talks to the
graphics card

https://github.com/fenghaitao/xserver-with-gl-accelerated-xephyr

In any case that is not going to help in your case either because it
relies on the Open GL capabilities of the parent X server (xvnc in
your case) to talk to the graphics card.

In summary, Xephyr is not going to solve your problem.