Date: Sun, 19 Aug 2012 23:01:19 +0200 From: Polytropon <freebsd@edvax.de> To: freebsd@dreamchaser.org Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: user specific xorg.conf? Message-ID: <20120819230119.c6030dad.freebsd@edvax.de> In-Reply-To: <50314EB5.9040900@dreamchaser.org> References: <503125EF.1020500@dreamchaser.org> <20120819195118.00427f87.freebsd@edvax.de> <50314EB5.9040900@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2012 14:38:13 -0600, Gary Aitken wrote: > Combining a couple of responses into one to cut down traffic... > > On 08/19/12 11:51, Polytropon wrote: > > On Sun, 19 Aug 2012 11:44:15 -0600, Gary Aitken wrote: > >> In attempting to zero in on my system crash problem, > >> I need to customize xorg.conf. > >> As I read the documentation, > >> there is no way for an ordinary user to provide an xorg.conf; > >> Xorg looks for files in the normal server search path, > >> which does not include any user directories -- > >> unless the user is root. > > > > What if you do (as a user) the "startx" command and try > > to hand the -config <file> to the program, like this: > > > > % Xorg -file /home/user/test/xorg.conf > > > > I haven't tried that myself, but according to "man Xorg" > > this option does exist. However, I'm not sure if xinit > > or startx honors this option if you use them (to make > > use of ~/.xinitrc). > > According to the man page: > "This option will work for any file when the server is run as root > (i.e, with real-uid 0), > or for files relative to a directory in the config search > path for all other users." > The config search path only includes system directories, not user directories. Read: "config search path". In my interpretation, this applies to _path names_ in where config files (default name: xorg.conf) will be searched. This does _not_ contradict to explicitely naming a _file_ as in: % X -config /home/someuser/test/xorg.conf It could also be possible to give the file a totally different name. However, the X server might refuse to use that file. You could easily try it. I have prefixed the example with "%" indicating that this command could be executed from a user (non-root) terminal, just the same way you would usually call % xinit or the % startx script to benefit from the ~/.xinitrc startup file. Also you could try to add the -config option to the two commands mentioned. I haven't looked into their specific implementation on if and how they will allow X parameters to be included. > Again, I think that is for security reasons, but I'm not certain. Primarily it is, but also about complexity. Imagine the X server would scan the whole (!) directory structure, beginning in /, to find a valid configuration file... > On 08/19/12 12:38, Jeff Tipton wrote: > > Gary, why do you need user-specific xorg.conf? > > By default, there's no xorg.conf file, > > so if you generate one and put it in /etc/X11/xorg.conf, > > your file will be used instead of the default options. > > And before putting the file there, you can test it, > > as suggested in the Manual: > > > > X -config /root/xorg.conf.new -retro > > I wanted a user-specific xorg.conf for test purposes. > The server already generated one when I first installed it, IIRC. No. The server can generate a file that is then typically placed as /root/xorg.conf.new which you'd have to copy to /etc/X11/ in order to have further X starts recognize and use it (in case you are _not_ explicitely calling the X server with the config file at the location in /root). If the X server does not find a xorg.conf file, it will run without one. That should be fine in 99% of all cases. Still there are reasons you intendedly want a xorg.conf file. In my opinion, the example I mentioned above should be fine for testing. If you agree with the final result, you can then install it into the server's default location mentioned at the top. > In general, I'd prefer to leave default generated stuff alone, > as it's easy to screw up and edit the wrong thing, > not save the original, not properly comment mods to the file, etc. In that case, put the file under version control. (I use CVS for that kind of stuff.) > However, in this case it looks like I'll have to tweak the global file. _Finally_ you can do this, but try (!) with the idea I mentioned at the beginning of this message. As I haven't tested it, I cannot tell you if it works, but I _assume_ that it should work. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120819230119.c6030dad.freebsd>