On Sat, Dec 4, 2010 at 12:57 PM, Felix Miata <mrma...@earthlink.net> wrote: > On 2010/12/04 12:23 (GMT-0800) Alan Coopersmith composed: > >> Robert wrote: > >>> I upgraded xorg-server and I noticed it didn't read my settings. I >>> figured that the new xorg probably must have deprecated the xorg.conf >>> file, and that I would have to configure it in the new way of using >>> /etc/X11/xorg.conf.d instead. > >> /etc/X11/xorg.conf is not deprecated, and is still read by the upstream >> code. >> Some input device entries there are ignored since the advent of input >> hotplug, >> but that's been true since Xorg 1.4 or so. > >> /etc/X11/xorg.conf.d extends /etc/X11/xorg.conf, but does not replace it. >> /etc/X11/xorg.conf.d is intended to replace .fdi files for input device >> configuration that were used by HAL for platforms which have moved off >> HAL. > >>> And sure enough, the arch linux wiki said >>> that 10-monitor.conf is the new config file for monitor settings. > >> That's a file created by your distro and a choice they've made to put >> monitor settings there. > >> (Sorry, I don't know why your driver isn't honoring your modeline, but >> it shouldn't be because of the file you put it in. I would bet it has >> a lot more to do with the Intel driver doing modesetting in the kernel >> instead of Xorg since the advent of KMS.) > > In testing *buntu*, Factory, Cooker & Rawhide I've been seeing more than > just modelines being ignored in xorg.conf but not in xorg.conf.d/, and as > yet have not found a pattern to help find out what is causing it. Could this > really be some KMS kernel fault? see e.g. > http://lists.x.org/archives/xorg-driver-ati/2010-November/018097.html > > What are those wanting custom user config and exporting XORGCONFIG to do it > supposed to do when their alternate xorg.conf files are not obeyed like they > used to be?
I think I know what the reason might be (since I wrote the xorg.conf.d code). In order to maintain the input option semantics where each subsequent InputClass takes precedence over the previous, xorg.conf is the last .conf file read. However, this might conflict with the output option semantics where the first match found is used. So, my guess is that the modeline is being found in xorg.conf.d and doesn't continue to look for options. I haven't looked at it, but it wouldn't be hard to make the server keep looking for output sections to use instead of stopping at the first. My intention wasn't to allow multiple Device/Monitor/Screen sections in xorg.conf.d installed by the distro. It seems like 10-monitor.conf is being generated on the fly and these aren't generic settings. Device/Monitor/Screen aren't really built to have multiple sections like InputClass. -- Dan _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
