From: Petr Vandrovec <hidden> Date: 2003-04-03 13:45:01
On 3 Apr 03 at 15:48, Sven Luther wrote:
Ideally, the EDID reading would be done just after the user request an
output mapping change for the first time, and then stored privately to
each output. mode changes and such would be done after the output has
been assigned only, and you would have the EDID by then. You could even
reread it regularly, in case the monitor is hot swapped or something such.
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Petr
From: Sven Luther <hidden> Date: 2003-04-03 14:04:11
On Thu, Apr 03, 2003 at 03:55:48PM +0200, Petr Vandrovec wrote:
On 3 Apr 03 at 15:48, Sven Luther wrote:
quoted
Ideally, the EDID reading would be done just after the user request an
output mapping change for the first time, and then stored privately to
each output. mode changes and such would be done after the output has
been assigned only, and you would have the EDID by then. You could even
reread it regularly, in case the monitor is hot swapped or something such.
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Err, i don't understand this ? Do you mean you are outputing to two
monitors at the same time ?
If that is so maybe you mean, speaking in graphic card terminology, and
not in fbdev one, that you are sharing one common framebuffer between
two outputs, right, possibly doing mirroring tricks or something such ?
If that is so, then it is ok still, since you would do the EDID read and
the mode setting at the moment you activate the video output. At this
time, you know what monitor is attached (since you can probe it) and can
check the mode with respect of what you know is possible. The main point
here is to do the mode setting based on what the ouptu can support, not
on what the fbdev thinks is right.
Friendly,
Sven Luther
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Err, i don't understand this ? Do you mean you are outputing to two
monitors at the same time ?
I think you mean lowest common denominator.
If that is so maybe you mean, speaking in graphic card terminology, and
not in fbdev one, that you are sharing one common framebuffer between
two outputs, right, possibly doing mirroring tricks or something such ?
Classic example is a SiS 6326 driving monitor and TV. You need to keep
the display to TV acceptable ranges.
From: Sven Luther <hidden> Date: 2003-04-03 16:10:05
On Thu, Apr 03, 2003 at 04:21:14PM +0100, Alan Cox wrote:
On Iau, 2003-04-03 at 15:15, Sven Luther wrote:
quoted
quoted
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Err, i don't understand this ? Do you mean you are outputing to two
monitors at the same time ?
I think you mean lowest common denominator.
quoted
If that is so maybe you mean, speaking in graphic card terminology, and
not in fbdev one, that you are sharing one common framebuffer between
two outputs, right, possibly doing mirroring tricks or something such ?
Classic example is a SiS 6326 driving monitor and TV. You need to keep
the display to TV acceptable ranges.
You mean, driving both display with the same ramdac ?
Friendly,
Sven Luther
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Err, i don't understand this ? Do you mean you are outputing to two
monitors at the same time ?
I think you mean lowest common denominator.
quoted
If that is so maybe you mean, speaking in graphic card terminology, and
not in fbdev one, that you are sharing one common framebuffer between
two outputs, right, possibly doing mirroring tricks or something such ?
Classic example is a SiS 6326 driving monitor and TV. You need to keep
the display to TV acceptable ranges.
I don't know whether that's a good example...
I assume the signal for the TV is different from the signal for the monitor
(these days you don't find many monitors that do 15.6 kHz / 50 Hz)? In that
case it's just the resolution that has to be more or less compatible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
From: Sven Luther <hidden> Date: 2003-04-03 16:58:50
On Thu, Apr 03, 2003 at 06:33:17PM +0200, Geert Uytterhoeven wrote:
On 3 Apr 2003, Alan Cox wrote:
quoted
On Iau, 2003-04-03 at 15:15, Sven Luther wrote:
quoted
quoted
Read is not enough. If you have connected one /dev/fbx to two monitors,
you must find highest common denominator for them, and use this one.
Err, i don't understand this ? Do you mean you are outputing to two
monitors at the same time ?
I think you mean lowest common denominator.
quoted
If that is so maybe you mean, speaking in graphic card terminology, and
not in fbdev one, that you are sharing one common framebuffer between
two outputs, right, possibly doing mirroring tricks or something such ?
Classic example is a SiS 6326 driving monitor and TV. You need to keep
the display to TV acceptable ranges.
I don't know whether that's a good example...
Ok, i will take the card i am currently working on for XFree86 as an
example, and you (Alan and Petr mostly) will tell me if this is a common
case, or if i miss something.
It has two outputs, where i can hook either a DVI or a VGA monitor. Each
of these video outputs correspond to a viewport, and there is hardware
which will let you set the output timings and the dot clock. You also
have to configure which part of the framebuffer you are reading, and
eventually setup a scaller to scale the pixels you read to the correct
output buffer. You also have for each head a DDC/I2C bus you can use to
speak with the monitor.
On the other side, you have the framebuffer area, which you can split in
two or not, and is fully independent from the above head issues.
So you could either have one fbdev and two viewports inside it, or have
two separate viewports each with only one viewport.
What i am trying to implement for the XFree86 driver is to have a common
framebuffer, so the graphic engine can be shared between them without
further changes, enabling dual head DRI suppport for example. Sure i
have a 8K coordinates range which makes this easy, but maybe other cards
have more strenous limits there.
Now, the plan is to separate the setup stuff that is common to the
_chip_ from the setup stuff that is specific to each _head_ or output.
In this case, it becomes easy to have the DDC port being specific to
each head, and this would sole all problems, since you would read all
the monitors attached to all the DDC buses, store them somewhere (and
ask again at the user demand, like Benjamin suggested), and when the
user changes the head mapping, or at head mapping initialization, have
the mode being validated against the monitors we _know_ are attached to
each DDC bus.
Now, i know that some boards have more DDC buses than heads or maybe
ramdacs, and things can be a bit more complicated. What do you say Petr ?
Could you yell us more about the matrox internal design with regard to
this ?
Friendly,
Sven Luther
It has two outputs, where i can hook either a DVI or a VGA monitor. Each
of these video outputs correspond to a viewport, and there is hardware
which will let you set the output timings and the dot clock. You also
have to configure which part of the framebuffer you are reading, and
eventually setup a scaller to scale the pixels you read to the correct
output buffer. You also have for each head a DDC/I2C bus you can use to
speak with the monitor.
Very common except lower end stuff generally has a single frame buffer
that both show and cannot be split or scanned by multiple outputs at
different rates.
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
From: Sven Luther <hidden> Date: 2003-04-03 17:07:59
On Thu, Apr 03, 2003 at 05:15:32PM +0100, Alan Cox wrote:
On Iau, 2003-04-03 at 18:10, Sven Luther wrote:
quoted
It has two outputs, where i can hook either a DVI or a VGA monitor. Each
of these video outputs correspond to a viewport, and there is hardware
which will let you set the output timings and the dot clock. You also
have to configure which part of the framebuffer you are reading, and
eventually setup a scaller to scale the pixels you read to the correct
output buffer. You also have for each head a DDC/I2C bus you can use to
speak with the monitor.
Very common except lower end stuff generally has a single frame buffer
that both show and cannot be split or scanned by multiple outputs at
different rates.
So, using the terminology of Petr's graph, you have only one CRTC, with
two possible outputs, or maybe you have two CRTC but which needs to be
synchronized between them ?
Friendly,
Sven Luther
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
So, using the terminology of Petr's graph, you have only one CRTC, with
two possible outputs, or maybe you have two CRTC but which needs to be
synchronized between them ?
The EPIA seems to support both outputs at once so I would assume it has
two CRTC's while the old SIS can do only one at a time so it may be a
switch.