Dynamic selection of operating system and display server combination

I am looking for ways to execute the desired display server depending on system settings.

  • Is is possible the adjust the configuration for the X server on the detail by which operating system variant it is run?
  • Would you like to try out the execution of optimised (and eventually proprietary) graphic drivers for self built (Linux) kernels while comparing their run time behaviour to other approaches from free software?

Selection of OS … function of bootloader. e.g. edit Grub2 accordingly

Selection of Display server … function of Display Manager e.g. edit display server configurations accordingly.

If this testing is just to be done with X, just use multiple xorg configuration files (tailored to specific configs) and call them accordingly.

I fiddle with my configurations for old GRUB and newer GRUB 2 as usual.

Selection of Display server … function of Display Manager e.g. edit display server configurations accordingly.

I find this area a software development challenge because specific Linux modules might also be needed.

If this testing is just to be done with X, just use multiple xorg configuration files (tailored to specific configs) and call them accordingly.

I imagine that alternatives would be already needed before a graphical login will be tried. Would you like to share any more ideas here?

You’ll have to elaborate.

I imagine that alternatives would be already needed before a graphical login will be tried.
mmm, yes, you’re right – the DM calls the server and THEN the greeter comes up. But there are ways you could work around that:

Would you like to share any more ideas here?
boot to non-graphical target. Write yourself a script that manages/preconfigures the graphical target settings (modprobe settings, DM conf settings, Xorg settings, whatever else you need to tailor specifically for that test). Then launch DM.

Example: The proprietary NVIDIA graphic driver software contains also a Linux kernel module.

Current X servers support auto-configuration to some degree (Plug & Play). I imagine that there are challenges in the fine-tuning of involved constraints.

How do you think about to pass a system preference by dedicated parameters on the boot command line?

Example: you want to compare nvidia vs. nouveau

  • Install nvidia drivers.
  • configure grub with two OS entries. One that uses “nomodeset” boot parm (for when testing the nvidia stack) and the other that doesn’t (for when you want to test the OSS stack. Both entries use “3” to boot to console.
  • When you boot, select appropriate selection that you want to use
  • at console you run your script that you have previously created. Script presents you options — option A: set up nvidia environment … option B: set up nouveau environment … and so forth …Each these options has coded logic to accomplish its task. Eg. to set up nouveau enviro, you don’t want the nvidia drivers trying to load, so you will have prevent that from occurring (one simple way – mv ) … the entirety of the script logic will have to take into account the various changes to configuration files, naming and moving of modules and libs that has to take place when switching from one state to another.
    As for X tuning, its pretty good at autoconfiging. If you need to fine tune/tailor, use xorg.conf files, but keep them simple – let X do as much of the tuning as possible
  • After your environment setup script is run (undoubtedly you’ll have to run it via sudo in order to evoke some of the changes it must make), you then launch the DM ( e.g. systemctl start xdm), and then log in as per usual … the environment you’ve logged into should be (if all went swimmingly as planned) set/configured to your necessary liking
  • run your tests
  • wash, rinse, repeat

I find this parameter alone not enough to specify the desired display server preferences for this use case. I hope that further options can be passed besides the ones which are already documented.

… the entirety of the script logic will have to take into account the various changes to configuration files, naming and moving of modules and libs that has to take place when switching from one state to another.

Do such considerations lead to a software development adventure? :wink:

the boot parameters will never specify display server preferences. The boot parms are kernel parms. Whereas the display server is strictly related to user space. You will have to configure/tailor your display server preferences later on in the process

Do such considerations lead to a software development adventure? :wink:
Ahh, I see what you meant by that earlier comment now. Yes, unfortunately, you’ll have to roll up your sleeves a bit. It’s not difficult to write the script logic (per se), but it is indeed tedious/boring/annoying admin work at its basest.

Another random thought – maybe check out the Phoronix Test Suite. I’m not sure of its configurable options, but it might do something like what your after – I don’t know, because I’ve never looked at it, but it might, so it might be worth the time to investigate whether something that does the heavy lifting already exists. Either way, best of luck with your adventure. :wink:

Did anybody try that before eventually?

The boot parms are kernel parms.

I hope that parameters are also possible which are not so interesting for the kernel but can be forwarded to environment variables.

You will have to configure/tailor your display server preferences later on in the process

This selection process needs corresponding input from the boot command line, doesn’t it?
(How do you specify the aspect to give a display server implementation priority over others which are installed in parallel on a powerful system?)

I don’t understand

I hope that parameters are also possible which are not so interesting for the kernel but can be forwarded to environment variables.
Why not just place them in /etc/environment and change them accordingly via script?

This selection process needs corresponding input from the boot command line, doesn’t it?
(How do you specify the aspect to give a display server implementation priority over others which are installed in parallel on a powerful system?)
I’m not sure I understand your question. But if it is along the lines that I believe, then I will answer:

  • No (to the former).
  • (And for the later part) Through the DM’s config. i.e. lightdm.conf:
xserver-command=/usr/bin/X
#xserver-layout=
xserver-config=/etc/X11/xorg_multiseat.conf

Something similar would apply to KDM, GDM…
Simply change those via script to whatever environment you require.

I imagine that there are two possibilities to pass additional data for the desired use case on the boot-command line.

Why not just place them in /etc/environment and change them accordingly via script?

Further data processing can be applied as the next steps after priorities were specified for display server implementations by an appropriate boot configuration.

Can any information from a chapter like “Kernel Boot Command-Line Parameter Reference” help to find better solutions?

Do you know any more applications (besides the popular software “systemd”) which use configuration options on the boot command-line already?

can’t say that I do … (nor expect any to, as explained in this, the other thread, and the LKML one)

You mentioned in one of the others about a kernel module that doesn’t control any hardware – have you looked into modules for virtual devices ? (or would you consider something such as that to still fall under the category of being “a module for hardware”?)

Not so far.

Would you like to point me to any specific ones?

Linuxtv.org - Git Repository - media_tree.git/blob - drivers/media/platform/vivi.c

off hand I can’t think of anything else specifically right now, but grep your kernel source for “virtual” (or maybe “emulate” … or both) and see what else comes up.

Thanks for the link to an interesting example. I would put such a video device emulation software also into the category “a module for hardware”.