Stuart Kreitman wrote:
> Hi,
>
> I'm interested in finding any examples of configuration that require or
> are helped by
> putting an xorg.conf file in place. In my experience over the past few
> years, the drivers
> have been fully competent with reading EDID, even through KVM switches.
>
Even through KVM switches? Is there something software can do to improve
interaction with KVM's that are poorly designed?
I have several IBM x346 servers (running sNV builds as late as 91) that
have ATI video cards (some special remote managment [rage based?] chip)
in them. They are all connected to a 1U Tripp-lite KVM/LCD/Keyboard
unit. By default, if I don't configure them explicitly, if they aren't
selected on the KVM when X starts, they pick a resolution and frequency
that is out of range for the LCD. When this happens, if I switch to them
later on, the LCD and KVM putup a message about being out of range, and
not only that, the LCD and KVM hang up solid, requiring a power cycle to
get them back.
On the otherhand, if the machine is selected on the KVM when X starts,
the right settings are selected, and I can move away from and back to
that machine at will. My solution so far was to save off the
automatically generated config file from a machine that started X while
selected on the KVM, and put it in place on all the machines like this.
-Kyle
> In the cases
> where autoconfiguration is misbehaved, no amount of xorg.conf magic will
> help. I'd like to
> flesh out categories of configuration experience, e.g.:
>
> 1) autoconfig is fully satisfactory, plug and play.
>
> 2) xrandr poking is necessary for primary or secondary display, user
> wishes to make live adjustments permanent.
>
> 3) Physical hot plugging 2nd monitor is necessary for correct config
> (saw this yesterday, albeit nv_87)
>
> 4) User needs to turn on/off some particular feature or extension.
> How often does this happen?
>
>
> any others...?
>
> If this topic is big, we can create another mailing list alias, but for
> now, lets start here.
>
> Thanks,
>
> Stuart K.
> _______________________________________________
> xwin-discuss mailing list
> xwin-discuss at opensolaris.org
>
