From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Description of problem: Changes made via editing x11 setup file (/etc/X11/xorg.conf) inconsistently require logout sometimes, reboot other times. In my specific case, I am hand-editing my file to change "LeftOf" to "RightOf" (since s-c-d doesn't do this yet). Usually, I simply logout/login to affect this change, but sometimes it forces me to reboot the machine just to accept this change. Why isn't the file being consistently re-read on the logout / login sequence? Version-Release number of selected component (if applicable): xorg-x11-6.7.0-9 How reproducible: Sometimes Steps to Reproduce: 1. Use s-c-d to configure dual head w/Xinerama 2. Closing s-c-d, you get a note that you'll need to logout login to see the changes 3. Logout, login 4. Oops, you forgot to change LeftOf to RightOf so you edit /etc/X11/xorg.conf, make the change, : w q 5. Logout, login Actual Results: Usually, the logout/login has the desired affect, but about 10-20% of the time, no amount of logout/login will do it, and you are forced to restart the entire PC to see the change. Expected Results: Screens swap sides to correct orientation Additional info:
This is indeed something we would like to clear up. Ideally you should never have to restart the X server, and your changes should take effect immediately. However it is a significant amount of work to realize this, which will have to take place upstream in the X.org forum (http://xorg.freedesktop.org). The current behaviour is not a bug as such, more a limitation of the X.org server architechture. I'm changing the severity of the bug to "enhancement".
Just to clarify: The problem I was seeing is that sometimes even a logout-login (which does appear to restart X) was picking up the changes, and sometimes it wasn't. The problem I'm reporting here is that there's some sort of weird inconsistency in the way it picks up new values. (e.g. hidden caching? not always restarting?) So I would claim that this is not an enhancement but a real bug. Meanwhile,I would be happy to file a separate enhancement request for dynamic changes (although I would imagine you already have one in the system) - let me know if you would like such a request entered as well.
The X server reads the config file exactly once during server startup. It parses the entire file, and sets internal variables, etc. Once that is done, the X server never looks at the config file again during runtime ever. If you make changes to the X server config file, you absolutely must restart the X server in order for them to take effect, as that is the only time that the X server looks at the config file. Wether you reboot the entire system, or just restart the X server itself, doesn't matter. The important thing is that the running X server process must terminate, and then a new X server process must be restarted. That can be done by quitting out of a startx initiated session, and then re-running startx, or it can be done by hitting CTRL-ALT-BACKSPACE to kill the server and then restart it manually if you're not using gdm or something else that restarts it automatically. This is not a bug in the X server. It is designed to read the config file exactly once when the server starts, and never to look at it again. Having explained that however, I will agree with you completely that it would be an excellent feature enhancement for the X server to be able to re-read the config file at runtime on the fly some day, and I believe that is an eventual goal of the X.Org project to some day make the server capable of doing that. It is not a simple hack to make the server re-read the config file at runtime however, and so it will only occur once it has been implemented by X.Org developers in the upstream official X.Org source code repository and is an official feature in a new X.Org release. Any perceived inconsistency you appear to be seeing is not an X server bug, but may perhaps be a misunderstanding for how the system starts up and manages the X server. If you make changes to the X server config file and they do not take effect, then the X server did not get killed and restarted. You must kill the X server first. I'm not entirely sure, but I think the display manager just reuses the same X server for multiple logins and does not restart it by default. I think that might be a configureable option in gdm however. Setting status to "NOTABUG" as per explanation above on how the server reads the config file. For the feature enhancement of making the server read the config file at runtime, that will happen upstream by X.org eventually, so I don't think there is any real value in filing a separate bug report for it, as it isn't that beneficial to track it in bugzilla IMHO.