Custom modeline in 10-monitor.conf?

[Dan Nicholson]

On Sat, Dec 4, 2010 at 12:57 PM, Felix Miata <mrmazda at 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