Date: Mon, 20 Aug 2012 02:11:36 +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: <20120820021136.20722408.freebsd@edvax.de> In-Reply-To: <50315E78.6090603@dreamchaser.org> References: <503125EF.1020500@dreamchaser.org> <20120819195118.00427f87.freebsd@edvax.de> <50314EB5.9040900@dreamchaser.org> <20120819230119.c6030dad.freebsd@edvax.de> <50315E78.6090603@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Aug 2012 15:45:28 -0600, Gary Aitken wrote: > On 08/19/12 15:01, Polytropon wrote: > > 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. > > I thought about that path vs file distinction; > looks like my original interpretation was correct: > > %startx -- -config ~/xorg.conf > Fatal server error: > > Invalid argument for -config > For non-root users, the file specified with -config must be > a relative path and must not contain any ".." elements. > Using default xorg.conf search path. > > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error Interesting. Your path ~/xorg.conf does not contain ".." elements. Have you tried specifying a full path (e. g. one containing your username, just in case ~ could not be properly resolved)? > >> 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... > > I assumed if no user directories were in the search path, > you would have to specify a complete path, not a relative one. > I never expected it to search all possible paths. > I was surprised to see that no user directories are in the default path, > but upon reflection decided it was probably because of security concerns. How could it be possible to have user directories in the _default_ search path when X doesn't know which users actually have an account on the system, and where their home directories are located? However, when we can assume that # X -config /root/xorg.conf.new works, we could assume that # X -config /home/foo/xorg.conf could also work. This example shows running X directly as root. The next step would be to login as "foo" and then performing % X -config /home/foo/xorg.conf from the "foo" user account. Again to take the error message > For non-root users, the file specified with -config must be > a relative path and must not contain any ".." elements. > Using default xorg.conf search path. into account: If ~/xorg.conf (where ~ equals /home/foo) is considered _not_ being a relative path, how about % X -config ./xorg.conf or even % X -config xorg.conf bein executed when the current directory is /home/foo - here the requirements "relative directory" and "no .." are met by omitting any path elements. Finally, if you're going to experiment with X, do it with using /etc/X11/xorg.conf. You can easily maintain different versions of the file and then using a symlink to indicate which one you want to try. So you can "switch back" to previous versions. For example, you have xorg.conf;1 xorg.conf;2 xorg.conf;3 xorg.conf;4 xorg.conf;5 xorg.conf;6 xorg.conf;7 and a symlink xorg.conf@ -> xorg.conf;6 points to the version you want to use. I know this looks stupid, but it works. :-) -- 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?20120820021136.20722408.freebsd>