On Thu, Mar 20, 2008 at 1:38 PM, Kevin Burtch <[EMAIL PROTECTED]> wrote:
> On 3/19/08, ottomeister <[EMAIL PROTECTED]> wrote:
> Two more questions... since the format for input is undocumented, we
> are using the data found here:
> http://www.filibeto.org/pipermail/sunray-users/2005-August/001465.html
>
> With that in mind, we see that the new resolution has a flag of "-",
> while all of the others have "B". Any chance you can share what the
> "flag" means? :)
The description is buried in the utresdef man page. It says:
... a flag indicating whether this resolution is
built in (B) to SRSS or has been locally defined (-), ...
> Also, and likely more important... is there any intelligence in the
> software as to the name in the "Resolution" column?
There's no intelligence. The name in the Resolution column is
just a label. The software does not attempt to interpret it as
anything more than that. You could call your locally-defined
timings "John" or "Paul" or "Ringo" and the software wouldn't
behave any differently.
The only time the name is important is if you have a
locally-defined timing whose name is the same as a built-in
timing. In that case the locally-defined timing has higher
precedence and will be applied to the DTU if utresadm has been
used to force that timing onto the DTU. (The rationale here is
that this lets you override the built-in definition with a
server-side definition. You'd only do this as a workaround for a
bug in the built-in timing.) This is a good reason for giving your
locally-defined timings names like "Ringo", so that they won't
collide with the names of built-in timings that are added in
future releases of SRSS.
> For example:
> # utresdef | grep [EMAIL PROTECTED]
> [EMAIL PROTECTED] 1600x1200 B [EMAIL PROTECTED] built-in
> timing
> [EMAIL PROTECTED] 1600x1200 B [EMAIL PROTECTED] built-in
> timing (digital-only)
>
> There are two definitions for the same resolution, one with a "d"
> suffix added to indicate digital output.
> The reason this may be important is, some of the monitors are using
> DVI, and some DB15 (I have no clue why).
> Do we need to create 2 definitions for each resolution we add?
The timings don't necessarily come in pairs (it's unusual for them
to do that) and you don't have to create local definitions in pairs.
The [EMAIL PROTECTED] timings have short blanking intervals that are likely
to be acceptable to monitors that capture the video signal digitally
and reclock it locally to the display driver circuitry (as in basically
any modern panel and perhaps some CRTs) but will likely not be
acceptable to monitors that use the signal to control analogue driver
circuitry (as in a traditional CRT) directly. This is why the comment
in the utresdef output says "(digital-only)".
Usually there's no non-d counterpart for an [EMAIL PROTECTED] timing
because those timings are outside the realm where you can
construct an [EMAIL PROTECTED] timing with blanking intervals large enough
for analogue circuitry to have a chance of keeping sync.
[EMAIL PROTECTED] is right on the edge, and some time after we'd
come up with the [EMAIL PROTECTED] timing Sun's monitor guys
convinced us that we could reasonably support [EMAIL PROTECTED]
for analogue too. We didn't want to withdraw or change the 'd'
timing so now we have two ways of driving [EMAIL PROTECTED]
If you're driving a panel then it shouldn't matter whether you
talk to it over VGA or DVI, it'll still use circuitry to capture the
signal and it should be able to deal with either the 'd' or the
non-d timing. If you're driving a CRT then the non-d timing has
a much better chance of being acceptable to the monitor.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
