Question about xorg.conf.d's searching path

[Zhigang Gong]

> -----Original Message-----
> From: Dan Nicholson [mailto:dbn.lists at gmail.com]
> Sent: Tuesday, March 27, 2012 9:11 PM
> To: Zhigang Gong
> Cc: alan.coopersmith at oracle.com; xorg-devel at lists.x.org
> Subject: Re: Question about xorg.conf.d's searching path
> 
> On Tue, Mar 27, 2012 at 2:38 AM, Zhigang Gong
> <zhigang.gong at linux.intel.com> wrote:
> > Hi,
> >
> >
> >
> > I’m building xorg in a local directory $HOME/xorg, then all libraries
> > will go to $HOME/xorg/lib,
> >
> > And all the configure files will go to
> > $HOME/xorg/share/X11/xorg.conf.d/,
> > such as the 10-evdev.conf.
> >
> >
> >
> > My question is, when I run this local Xorg it will not search the
> > configure file at the local configure directory:
> >
> > $HOME/xorg/share/X11/xorg.conf.d/
> >
> > Instead, it searches the system’s xorg configuration file at:
> >
> > /etc/X11/xorg.conf.d
> >
> > /usr/share/X11/xorg.conf.d
> >
> >
> >
> > So you can see, when I run the new Xserver, it will load the old
> > configuration files rather than the correct files
> >
> > Installed at local configuration directory.
> >
> >
> >
> > I traced into the source code, and found the reason is as below:
> >
> >
> >
> > the macro SYS_CONFIGDIRPATH’s defined as "/usr/share/X11/%X,"
> > "%D/X11/%X",
> >
> > And it will be used to find the system config path. And the finding
> > process is at function OpenConfigDir(), the finding mechanism
> >
> > is to scan the SYS_CONFIGDIRPATH from left to right, and if it
> > successfully find a directory, then it stop finding next. As my system
> > has
> >
> > a /usr/share/X11/xorg.conf.d, it stop to find the next path which is
> > pointing to my local directory and which is the one should be
> >
> > used here IMHO. As all the building process in my local building
> > repository will install configuration files into local files rather
> > than
> >
> > the /usr/share/X11/xorg.conf.d.
> >
> >
> >
> > I know there may be many duplicate config files in these two
> > directories, so we have to pick one and discard the other one. In my
> >
> > opinion, the local directory should be higher priority. Otherwise, how
> > can we ensure we use the correct file when we build a new
> >
> > xserver which has difference config files？
> >
> >
> >
> > Any suggestion?
> 
> I had to remind myself how this works, but I think I get it looking through
> the code again.
> 
> I believe the idea is that since the xserver is running with high privileges
> and making non-trivial access to hardware that the configuration specified
> by the vendor/administrator takes precedence.

So the key point here is privilege issue?
The policy is using system directory's configuration files by default. And if
no system directory then using local configuration files. It's the user's 
responsibility to make sure the needed new configuration file is at correct
directory. Right?


> Looking through the oddball code in hw/xfree86/common/xf86Config.c
> and hw/xfree86/parser/scan.c, the code will look under $sysconfdir and
> $datadir if the equivalent directories are not found under /etc/X11 or
> /usr/share/X11, respectively.
> 
> You can define some macros during the build if you want to change the
> order a bit.
> 
> export
> CPPFLAGS="-DSYS_CONFIGDIRPATH=\"%D/X11/%X,/usr/share/X11/%X\""
> 
> That would reverse the order from the default since %D expands to
> $datadir. Arguably this should be available as a configure option, but no
> one did that work and I worry that trying to expose the % tokens would be
> difficult to explain.

Export CFLAGS should work. I still think this is a confused thing when
developing X related modules locally with introducing new configuration
file. As usually people think that a "make install"  install all the new
files incuding configuration files to correct place. But this is not true
here.

I'd like to see a hint at the developer wiki page to mention about this issue.
And the developer can choose to define CFLAGS to swap the order or just
copy the required configuration file to system dir if needed..

Anyway, thanks for the explanation.
> 
> --
> Dan