I want users to be able to edit /etc/X11/xorg.conf for screen res.
 

We are deploying several RHEL 4 workstations that use NVidia 5600 graphic cards and dual monitors. On occasions the user needs to change the resolution of the monitors and while this works, once they reboot the workstation reverts back to the original resolution. It appears as though this has something to do with their desktop load not allowing them to write to /etc/X11. BTW, We're using KDE.

Is this a common problem or is there some clean/eloquent way for us to allow users to change their resolution?

I've seen references to opening up /etc/X11/xorg.conf as well as setting the permissions to 777 on /etc/X11. I was hoping for a solution a little less blunt than opening up system level files.

Any help would be appreciated.

Thanks -- Donnie

I am a little confused by the situation. First you say that on occasion they need to change the resolution, but then say it is a problem when the system reverts back to the original resolution. If the change is only occasional, why would you want it to be persistent between reboots?

What exactly is your preferred behavior for these systems?

Well that's a fair question. You'd think that under normal circumstances the workstation would be configured with the native resolution and only changed on rare occasions.

We do however use these workstations for large visualization rooms consisting of three projectors so the use use of dual-view and xinerama come in to play. Regardless, it's common to change the video settings on these workstations to switch between dual-view and xinerama which consequently allows us to show 3D stereo images on two screens and then use the full three screens for large high-resolution detail. Unfortunately we've been unable to get to a point where we can "set and forget" the video settings so there is some "change video settings - reset X - display - change video again - reset X - blah blah blah".

I said that the video reverts after a reboot but it actually reverts back to the original settings after X11 is restarted (e.g., logout). Switching from Xinerama to Dual View is even worse since you *must* restart X ... this of course does not allow a user to switch from Xinerama to Dual View since the video settings continually revert back to the original settings. The user has to contact a system administrator with root privileges to reset the video from Xinerama to Dual View. <whew>

Hope this makes since and again ... thanks for the help.

I think the best way is to set up sudo to give regular users access to that folder or file only. That way you have a log of what's been done and when and they get to access the file without trashing the system.

I think this, depending on the deployment and environment, may be wholly unnecessary. Leave a standard failsafe config if you can.

Three things: xinit, xdm/gdm/kdm/other dm, alternate X config

xinit config files allow you to determine the order of the whole chain of events. Quite overwhelming and not as to the point. Also, how much crap you need to go through to simply change your screen setup seems too much.

Alternate X config, referencing X.org's horribly laid-out site, I found http://www.x.org/archive/X11R7.0/doc/html/Xorg.1.html
Scroll down to the Options section, and to the very last option "-config". That's your simple answer, multiple configs, select one per layout, making sure it's within the users ability to modify. Changes should then be saved on logout, and you can have a layout(config file) for each setup: Dual-head mirror, Dual-head seperate screens, Xinerama, and so on.

Display manager... loads and loads of options to manage it all. Take a look at this manual I found on gdm, particularly the section on the X-server setup tab, http://fts.ifac.cnr.it/cgi-bin/dwww?.../C/expert.html
You can setup sessions in great detail if you're using a display manager. Flexible servers means you can have individual servers started on demand with the options you specify.

Lenard

Okay DoomOr ... it's late but I read through a little bit of the Display Manager "expert.html" file. This one may actually be able to help. I like the idea of defining a variety of "sessions" with different video settings and then allowing the user to switch between sessions ... it just seems logical although the documentation is a bit heavy .... that's life. I'll go through more of this in the morning.

I'm tempted to stay away from the Alternate X Config solution since this would require a change to the current OS load. In our organization a change like this would likely take months of work (i.e., change management, documentation updates, reviews etc.). It could be a longer term solution though.

XavierP's recommendation to use sudo seems logical as well but in our environment, muck like Alternate X Config, the burden of implementing a process that allows anyone other than admins to use sudo would be overwhelming. Our "Privileged ID" system is thorough to say the least ... and limiting sudo activities to administrators helps reduce the overhead with managing those privileges. If we were to allow any user to sudo, even for just editing X configuration files, it would generate additional reviews/processes and would likely increase log file entries that would also need to be reviewed monthly.

The situation is somewhat odd ... we don't have the same issue with changing video settings on Windows workstations. This is actually one of the first scenarios where I've seen a security concern on a Windows box be a non-issue (users change Nvidia settings on Windows without any problems) and the Linux box needing a solution.

Thanks

I think you may have misinterpreted or missed the full ability of what the man page says. The config file should be able to be anywhere and does not alter the default config file. It's simply a text file somewhere. With that, the following.

For all intents and purposes, allowing a user to modify a presumably local X.org.conf file would be far more permissive than having an alternate config file located somewhere, perhaps in the user's home directory, which stays out of the system paths.


To be more to the point: If you allowed a user to start X from a prompt, then there would be no point in not allowing them to use an alternate config file, because if they were to be able to start X, they would be able to pass the arguement for the alternate config file which could be located anywhere, even a user specific directory, or a shared directory.

Theory here, please follow for a moment: If say a user has X and any associated display manager crash, does your user have the ability to restart X from a terminal? If you could put this theory to truth, or already run a terminal based login system that doesn't drop you directly to a display manager as your login device, THEN you already give them the ability to load an alternate config.

Now, I'm not advocating this as the best solution. I'm simply expressing that until you have a display manager properly configured to allow for all necessary requirements, you may be able to just notify your users of the appropriate syntax and even provide them with temporary config files for their needs.

Doom0r ... thanks for helping me understand this ... I think I get it. There may still be some things we have to work out around the "location" of an alternate config file but hopefully nothing major. I'm thinking of a situation where the xorg.conf lives in the user's home directory and then the user walks down the hallway one day and uses a conference room workstation that will likely need different video settings than his desktop system. We tossed around ideas such has a hostname.username.xorg.conf file ... seems a bit complex but we'll keeping looking around.

Again, thanks for the help.

Have you tried with xrandr? I think it is meant for those things.

Intel chipset Mandriva and resolution problems besides gamma
 

Mandriva with Intel chipset just lost the lusture when upgraded to spring. 2007 it all went fine a breeze. I have intel i810. First I lost the resolution and it wont understand anything other than 640X480 when logs into desktop, greeter is still the same while desktop was corrected by krandr. That was a very handy tool indeed. KDE desktop had another advantage of having display settings via right click on the desktop. There I would change the resolution and the gamma too with the root authentication required and the X86 related both config files. Still when rebooted all went lost and had to do the settings once again. but now I have managed enough after surfing through the web and neural networks too.

The problem is almost solved. xgamma came in timely help. 915resolution was handy too.

In the end... KDE4 now wont understand some resolutions and still buggy... get to look into it...

Any suggestions welcome.

Thanks for bringing up Xrandr, I never gave it consideration before when I skimmed over it as it was designed for resolution change. It seems it has matured to handle most things, although, there are some performance drawbacks for some things like rotation and reflection, but you would have those most everywhere anyways. It seems if you can make it possible in a normal xorg.conf you can achieve it with Xrandr. The man page seems a little draconic, but there seems to be plenty of people discussing multiple monitors with it in a clean fashion all over.

A couple people's experiences on LQ: http://www.linuxquestions.org/questi...+multi+monitor and a better explanation than the man page here: http://www.thinkwiki.org/wiki/Xorg_RandR_1.2

Create a group that describes what you want your users to do: groupadd displays. Add applicable users to new group: usermod –G displays linux.user.

Now as root, modify sudousers file by executing visudo. Add the below lines:

Now users in the displays group can issue sudo system-config-display from within a terminal to set persistent video settings.