Multimonitors Config Problems .Hello everyone, could someone here explain to me how the Igel OS behaves technically when, for example, screen settings are set locally on the Igel and one wants to override them through a policy? Does the OS differentiate between local and pushed settings? Can the settings be traced in the registry? We are having huge problems with multi-monitor configurations in combination with a laptop and two monitors. Is there a way to provide the user with a preset of a screen configuration as a link on the desktop and, if necessary, have the user execute it in case of an error?
We implemented something like this using the “xrandr” command, publishing it as a custom application (icon in the Igel start menu).
This command sets both monitors to be in mirror mode for example:
xrandr –output DisplayPort-1 –same-as DisplayPort-0
You create a new “custom application” inside UMS and put the command into the “Command” textbox.I would suggest you enable Bash shell as a new session for debugging. That way you can test commands on the fly / write shell scripts. A lot of the usual Linux commands used for managing desktop stuff are available inside IgelOS. The window manager used in IgelOS 11 is “xfce” as far as I know. Try running “xfce4-settings-editor” for example.
Side note: you can run those published custom applications on every reboot by setting the “autorun” checkbox. So you basically can configure every display parameter via commandline and manually load the desired settings via icon or let a certain custom application run automatically. Igel UMS does not expose every possible setting you could set on a regular Linux desktop. Mouse acceleration for example is not implemented in the GUI to this day.
@member Vielen lieben Dank ich probiere es mal, dürfte ich zur Not noch mal auf die zukommen ?
As far as I understand, each IgelOS instance has its own registry, which can be modified by running “Setup” locally or using commandline tools. When you run Setup, you will get a GUI similar to UMS. Settings published by the UMS will override the local settings and will be marked by a padlock icon. If you want to understand what is going on behind the scenes, try looking at the naked parameters in the “Registry” part of UMS. There you will find every parameter that can be set in the more structured looking parts of the UMS – and parameters that can be set only here.
Annoyingly, it is not possible to publish reasonable defaults via UMS that can then be overwritten by the thinclient / the user. If you set a parameter in UMS to a value, this value will be enforced. We worked around this by not setting the parameter in UMS at all, and instead setting the parameter via script on the thinclients once. You can set every registry parameter on the thinclient with the commandline tool
“setparam”
setparam userinterface.mouse.speed 10
(Example for setting the mouse speed to value 10)
@member very good details. ☝️ 👍
“setparam” (and its variants) can be used to read effective settings that have been set by either UMS profile, or local device settings. In the case of local device settings, it can also be used to change or delete them. However, if I’m not mistaken, it must be run in root context?
If thinking of it from “Windows” context:
1. UMS profiles, when applied to a device are much like Windows Group Policy settings, and take precedence over local settings. On endpoint, they can be seen in /wfs/group.ini file
2. Settings set at device level (from within UMS device edit, or local on device from Setup), are much like Windows Local Computer Policy. On endpoint, these settings can be seen in /wfs/setup.ini
In this way, if you start managing a setting via “profile”, then the profile settings win. The “local settings” are still there, but not being used. If you take away the “profile”, then suddenly the local settings are effective once again.
For something like display settings, since they can be so individualized, a profile might not be a good approach, since this would prevent user from adjusting.
How bad is the problem? I know the display switch is not a very nice tool to use.
So far, the CustomApp works with screen settings, but unfortunately, they are not persistent. Is there a way to save these settings? The “xcf4-display-settings” command does not exist in the current OS11. Is there a new command or a way to achieve this? Thank you.
Which command are you using as CustomApp?
The command that doesn’t exist is probably a typo…should start with xfce4
Hi Milan, unfortunately there is no typo error. I made a mistake in my previous message.
I’ve never played with the “xfce4-settings-manager” or “xfce4-settings-editor” (can be opened from the former), but those do exist.
What’s the customapp commands you are trying to run? Can you go into some more detail around the “huge problem” and what approach you are looking at to solve it?
Hi Milan, only these commands a avaible, but not the xfce4-display-settings.
We are experiencing significant issues with screen settings involving a laptop, docking station, and 2 or 3 monitors. When the user sets them using the display switcher, they can work with them, but it frequently happens that the settings get misaligned. This forces the user to start adjusting them again from scratch, which is truly frustrating. Therefore, I’m looking for a method where the user can have different preset screen settings as a CustomApp and easily select them in case of errors. Setting the presets is not an issue; they can be configured using the “xrandr” command and function as intended. The problem lies in making these settings persistent. This can only be achieved if the user opens the display switcher after the CustomApp and applies the settings. Hence, I’m seeking a way to replicate the “apply” action from the display switcher GUI using the command-line interface (CLI).
Understood. From looking, the display switcher takes care of writing the specific settings to a persistent setting file. The OS will then use these stored settings to restore the display settings on next boot. Sometimes there might also be a sync issue, where the local settings do not get synced to the UMS properly, and you may end up getting different settings then you had previously set.
Until now I haven’t tried this, but if you run “igel_display_switcher” from the command line, you’ll see it spit out the configuration changes, and sometimes some humorous text, as you toggle and apply changes.
If you compare the pre and post versions of the /wfs/setup.ini, specifically “x” section, you’ll start to see what changes are being made to allow the changes to persist after reboot.
So it seems there is quite a bit going on, and may not be trivial, unless I’ve overlooked something obvious.
thx Milan i will try
Continue reading and comment on the thread ‘Multimonitors Config Problems and explain to me how the Igel OS behaves’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!