Re: [Linux-fbdev-devel] [PATCH]: EDID parser

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[James Simmons]

> James,
> 
> Here's a revised patch.  I was able to receive source code from SciTech
> (c/o Kendall Bennett) which allowed me to fix bugs and complete the
> parser.  It's probably around 90-95% complete in terms of basic parsing.
> 
> It also fixes memory leaks which was present in the old patch.

Let really good. I applied it to my local tree but haven't passed it to BK 
fbdev yet. The only thing I like to see changed is get_EDID. At present it 
accepts a struct pci_dev. Now for generic support for the intel platform 
we can get this from the BIOS. You already have a patch that does this. 
It doesn't need a struct pci_dev in this case. It is possible to get this 
info from the i2c bus but I never seen any drivers do this. What data would
we have to pass in get the EDID inforamtion? So the question is how 
generic will get_EDID end up being or will we have to have driver specfic 
hooks since I don't pitcure i2c approaches being the same for each video 
card. Petr didn't you attempt this with the matrox driver at one time?

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Benjamin Herrenschmidt]

> Let really good. I applied it to my local tree but haven't passed it to BK 
> fbdev yet. The only thing I like to see changed is get_EDID. At present it 
> accepts a struct pci_dev. Now for generic support for the intel platform 
> we can get this from the BIOS. You already have a patch that does this. 
> It doesn't need a struct pci_dev in this case. It is possible to get this 
> info from the i2c bus but I never seen any drivers do this. What data would
> we have to pass in get the EDID inforamtion? So the question is how 
> generic will get_EDID end up being or will we have to have driver specfic 
> hooks since I don't pitcure i2c approaches being the same for each video 
> card. Petr didn't you attempt this with the matrox driver at one time?

get_EDID() has to be a driver specific hook

EDID via BIOS is a way to get it, BIOS emulation in userland is another,
on PPC, I can retreive it from the firmware device-tree in a different
way with some cards, and finally, I plan to implement i2c sooner or
later with some drivers...

Ben.

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Petr Vandrovec]

On  2 Apr 03 at 22:55, James Simmons wrote:

> It doesn't need a struct pci_dev in this case. It is possible to get this 
> info from the i2c bus but I never seen any drivers do this. What data would
> we have to pass in get the EDID inforamtion? So the question is how 
> generic will get_EDID end up being or will we have to have driver specfic 
> hooks since I don't pitcure i2c approaches being the same for each video 
> card. Petr didn't you attempt this with the matrox driver at one time?

Yes, matroxfb provides one i2c (DDC) bus for each output videocard has.
I ended with only this support (and userspace EDID parser) as i2c was
initialized loong after framebuffer at that time... Now when i2c is usable
when fbdev initializes, it looks much better.

Only get_EDID interface I need is one which gets i2c bus as argument. But
I have no idea how I should handle situation where you have connected
two different monitors to both crtc1 outputs... Like 50Hz PAL TV &
60+Hz VGA monitor. Currently it is user responsibility to resolve such
situation...
                                            Petr
                                            

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Benjamin Herrenschmidt]

> 3.  Some architecture specific methods, such as doing it via the BIOS. 
> This is the last choice, our fallback method. as this EDID may be static
> and represents only the display detected at boot time.
> 
> For supplementary functions, we also need some kind of control that
> allows the user to tell fbdev "I've switched monitors, please reread the
> EDID". We want to avoid doing DDC each time fbdev does an fb_set_var(),
> especially for DDC1 which can be very slow. 

That's also what Apple does indeed. It's too complicated/long to
dynamically detect hotplug, but they do have a button you can
click to force a re-detect of the displays in the GUI and this
goes via some kind of ioctl to the video driver to ask for new
connection informations (basically EDID).

> Also, a way to download the EDID from kernel to userland.

Just define an ioctl for that and let each driver that support EDID
return something seem to be the simplest way.

If we really want to make EDID a generic thing, then we can eventually
have the EDID block attached to each fb_info and then a generic
fbmem.c ioctl to read it, but then make sure that EDID block isn"t
mandatory (it has no sense to some specific HW like some embedded
stuffs) and I always prefer when drivers are the real target of
the calls like this ioctl, eventually using fbdev "tools" as helpers
instead of having fbdev do something directly as a "mid-mayer".

Ben.

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Benjamin Herrenschmidt]

> Just define an ioctl for that and let each driver that support EDID
> return something seem to be the simplest way.

Replying to myself... and definitely not the best way for 2.5
(would be ok for 2.4 but do we care at this point ?)

Instead, we'd rather add the EDID as an attribute of the fb
to sysfs.

Actually, I suggest that each fbdev driver defines ones or more
nodes in sysfs below the actual driver node, representing the
various heads. Each head would then have attributes representing
the various display properties, one beeing the EDID block.

> If we really want to make EDID a generic thing, then we can eventually
> have the EDID block attached to each fb_info and then a generic
> fbmem.c ioctl to read it, but then make sure that EDID block isn"t
> mandatory (it has no sense to some specific HW like some embedded
> stuffs) and I always prefer when drivers are the real target of
> the calls like this ioctl, eventually using fbdev "tools" as helpers
> instead of having fbdev do something directly as a "mid-mayer".
> 
> Ben.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 03:07:33AM +0100, Petr Vandrovec wrote:
> On  2 Apr 03 at 22:55, James Simmons wrote:
> 
> > It doesn't need a struct pci_dev in this case. It is possible to get this 
> > info from the i2c bus but I never seen any drivers do this. What data would
> > we have to pass in get the EDID inforamtion? So the question is how 
> > generic will get_EDID end up being or will we have to have driver specfic 
> > hooks since I don't pitcure i2c approaches being the same for each video 
> > card. Petr didn't you attempt this with the matrox driver at one time?
> 
> Yes, matroxfb provides one i2c (DDC) bus for each output videocard has.
> I ended with only this support (and userspace EDID parser) as i2c was
> initialized loong after framebuffer at that time... Now when i2c is usable
> when fbdev initializes, it looks much better.
> 
> Only get_EDID interface I need is one which gets i2c bus as argument. But
> I have no idea how I should handle situation where you have connected
> two different monitors to both crtc1 outputs... Like 50Hz PAL TV &
> 60+Hz VGA monitor. Currently it is user responsibility to resolve such
> situation...

Is the EDID reading stuff not done per head ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Petr Vandrovec]

On  3 Apr 03 at 9:40, Sven Luther wrote:
> On Thu, Apr 03, 2003 at 03:07:33AM +0100, Petr Vandrovec wrote:
> > On  2 Apr 03 at 22:55, James Simmons wrote:
> > 
> > > It doesn't need a struct pci_dev in this case. It is possible to get this 
> > > info from the i2c bus but I never seen any drivers do this. What data would
> > > we have to pass in get the EDID inforamtion? So the question is how 
> > > generic will get_EDID end up being or will we have to have driver specfic 
> > > hooks since I don't pitcure i2c approaches being the same for each video 
> > > card. Petr didn't you attempt this with the matrox driver at one time?
> > 
> > Yes, matroxfb provides one i2c (DDC) bus for each output videocard has.
> > I ended with only this support (and userspace EDID parser) as i2c was
> > initialized loong after framebuffer at that time... Now when i2c is usable
> > when fbdev initializes, it looks much better.
> > 
> > Only get_EDID interface I need is one which gets i2c bus as argument. But
> > I have no idea how I should handle situation where you have connected
> > two different monitors to both crtc1 outputs... Like 50Hz PAL TV &
> > 60+Hz VGA monitor. Currently it is user responsibility to resolve such
> > situation...
> 
> Is the EDID reading stuff not done per head ?

No. With matroxfb, you have two framebuffer devices, /dev/fb0 & /dev/fb1,
which can be connected to any of three outputs: analog primary, analog
secondary and DVI. Analog primary & DVI share same pair of DDC cables,
and analog secondary has its own... And user can interconnect fb* with
outputs in almost any way he wants, as long as hardware supports it.
                                                        Petr Vandrovec
                                                        

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Benjamin Herrenschmidt]

> No. With matroxfb, you have two framebuffer devices, /dev/fb0 & /dev/fb1,
> which can be connected to any of three outputs: analog primary, analog
> secondary and DVI. Analog primary & DVI share same pair of DDC cables,
> and analog secondary has its own... And user can interconnect fb* with
> outputs in almost any way he wants, as long as hardware supports it.
>                                                         Petr Vandrovec

It's +/- similar on radeon's and r128's...

I think at this point, we really need to add a structure defining
an "output" along with a few calls so the driver can tell us about
the "default" output/head mapping and can be changed from userland.

That way, the "struct fb_connection" would then be the parameter
passed to those EDID routines...

The driver would setup a default policy at boot based on what
have been probed. But userland would be able to

 - Request connection info from all outputs. Note that these contains
more than just EDID. Some drivers can "probe" for the presence of
something in the VGA or S-Video connectors by sensing the load on
the signals, even if that "thing" cannot provide an EDID. So we need
a bit more than just the EDID, something like

  struct fb_connection_info {
	int	index;	/* Absolute index of output on this card */
	int	type;	/* FB_VGA, FB_DVI, FB_ADC, FB_LVDS, ... */
 	int	flags;	/* FB_CONN_PRESENCE, FB_VALID_EDID, ... */
	u8	edid[128];
  }

 - Ask/Set output<->head mapping. Possibly by an ioctl to the head
that sets the connection index. Of course, the driver may fail if
the combo isn't supported. Also, the policy isn't defined on what
happens to the head's current mode. I beleive the head should try to
keep it's current mode unless it's not suitable to whatever have been
detected on that connection.

What do you think ?

Ben.

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 12:05:13PM +0100, Petr Vandrovec wrote:
> On  3 Apr 03 at 9:40, Sven Luther wrote:
> > On Thu, Apr 03, 2003 at 03:07:33AM +0100, Petr Vandrovec wrote:
> > > On  2 Apr 03 at 22:55, James Simmons wrote:
> > > 
> > > > It doesn't need a struct pci_dev in this case. It is possible to get this 
> > > > info from the i2c bus but I never seen any drivers do this. What data would
> > > > we have to pass in get the EDID inforamtion? So the question is how 
> > > > generic will get_EDID end up being or will we have to have driver specfic 
> > > > hooks since I don't pitcure i2c approaches being the same for each video 
> > > > card. Petr didn't you attempt this with the matrox driver at one time?
> > > 
> > > Yes, matroxfb provides one i2c (DDC) bus for each output videocard has.
> > > I ended with only this support (and userspace EDID parser) as i2c was
> > > initialized loong after framebuffer at that time... Now when i2c is usable
> > > when fbdev initializes, it looks much better.
> > > 
> > > Only get_EDID interface I need is one which gets i2c bus as argument. But
> > > I have no idea how I should handle situation where you have connected
> > > two different monitors to both crtc1 outputs... Like 50Hz PAL TV &
> > > 60+Hz VGA monitor. Currently it is user responsibility to resolve such
> > > situation...
> > 
> > Is the EDID reading stuff not done per head ?
> 
> No. With matroxfb, you have two framebuffer devices, /dev/fb0 & /dev/fb1,
> which can be connected to any of three outputs: analog primary, analog
> secondary and DVI. Analog primary & DVI share same pair of DDC cables,
> and analog secondary has its own... And user can interconnect fb* with
> outputs in almost any way he wants, as long as hardware supports it.

Mmm, i have not been into fbdev much lately, but for my X devel work, i
believe thta it is a good thing to separate the framebuffer issues from
the output issues, and thus, for the card i have at least, have one
function where the per chip things are done (memory detection, bypass
unit handling, framebuffer and memory management) and another set of
functions which would be head, that is output, specific. This way, you
would configure the /dev/fbx and when the user which to use this or that
output, the DDC will be connected to the output, not the framebuffer.
This seems a reasonable way of doing this and should solve your problem,
no ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 03:05:54PM +0100, Petr Vandrovec wrote:
> On  3 Apr 03 at 14:38, Sven Luther wrote:
> > On Thu, Apr 03, 2003 at 12:05:13PM +0100, Petr Vandrovec wrote:
> > > No. With matroxfb, you have two framebuffer devices, /dev/fb0 & /dev/fb1,
> > > which can be connected to any of three outputs: analog primary, analog
> > > secondary and DVI. Analog primary & DVI share same pair of DDC cables,
> > > and analog secondary has its own... And user can interconnect fb* with
> > > outputs in almost any way he wants, as long as hardware supports it.
> > 
> > Mmm, i have not been into fbdev much lately, but for my X devel work, i
> > believe thta it is a good thing to separate the framebuffer issues from
> > the output issues, and thus, for the card i have at least, have one
> > function where the per chip things are done (memory detection, bypass
> > unit handling, framebuffer and memory management) and another set of
> > functions which would be head, that is output, specific. This way, you
> > would configure the /dev/fbx and when the user which to use this or that
> > output, the DDC will be connected to the output, not the framebuffer.
> > This seems a reasonable way of doing this and should solve your problem,
> > no ?
> 
> Of course. But because of James decided that fbdev layer will automatically
> choose appropriate resolution only from xres/yres, I need to have monitor
> capabilities at the time upper layer asks to set videomode on /dev/fbx...
> And it just sets it on /dev/fbx, leaving out both VTs (so I cannot remember
> what mode was probed on each VT anymore) and outputs.

Mmm, and at what time is the fbdev->output mapping done ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 03:38:43PM +0100, Petr Vandrovec wrote:
> On  3 Apr 03 at 15:11, Sven Luther wrote:
> > On Thu, Apr 03, 2003 at 03:05:54PM +0100, Petr Vandrovec wrote:
> > > On  3 Apr 03 at 14:38, Sven Luther wrote:
> > > > On Thu, Apr 03, 2003 at 12:05:13PM +0100, Petr Vandrovec wrote:
> > > > > No. With matroxfb, you have two framebuffer devices, /dev/fb0 &
> > > > > /dev/fb1, which can be connected to any of three outputs: analog
> > > > > primary, analog secondary and DVI. Analog primary & DVI share same
> > > > > pair of DDC cables, and analog secondary has its own... And user can
> > > > > interconnect fb* with outputs in almost any way he wants, as long as
> > > > > hardware supports it.
> > > > 
> > > > Mmm, i have not been into fbdev much lately, but for my X devel work, i
> > > > believe thta it is a good thing to separate the framebuffer issues from
> > > > the output issues, and thus, for the card i have at least, have one
> > > > function where the per chip things are done (memory detection, bypass
> > > > unit handling, framebuffer and memory management) and another set of
> > > > functions which would be head, that is output, specific. This way, you
> > > > would configure the /dev/fbx and when the user which to use this or that
> > > > output, the DDC will be connected to the output, not the framebuffer.
> > > > This seems a reasonable way of doing this and should solve your problem,
> > > > no ?
> > > 
> > > Of course. But because of James decided that fbdev layer will
> > > automatically choose appropriate resolution only from xres/yres, I need to
> > > have monitor capabilities at the time upper layer asks to set videomode on
> > > /dev/fbx... And it just sets it on /dev/fbx, leaving out both VTs (so I
> > > cannot remember what mode was probed on each VT anymore) and outputs.
> > 
> > Mmm, and at what time is the fbdev->output mapping done ?
> 
> At random time, when user asks to change fbdev->output mapping... And it 
> still means that I have to create new EDID based on all EDIDs I read from 
> each output - this is biggest problem, and that currently used videomode
> can become invalid - and this is even worse problem.

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.

I have not read James response to you, but had the impression he did
propose something such, did he not ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Petr Vandrovec]

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
                                                                

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Petr Vandrovec]

On  3 Apr 03 at 14:38, Sven Luther wrote:
> On Thu, Apr 03, 2003 at 12:05:13PM +0100, Petr Vandrovec wrote:
> > No. With matroxfb, you have two framebuffer devices, /dev/fb0 & /dev/fb1,
> > which can be connected to any of three outputs: analog primary, analog
> > secondary and DVI. Analog primary & DVI share same pair of DDC cables,
> > and analog secondary has its own... And user can interconnect fb* with
> > outputs in almost any way he wants, as long as hardware supports it.
> 
> Mmm, i have not been into fbdev much lately, but for my X devel work, i
> believe thta it is a good thing to separate the framebuffer issues from
> the output issues, and thus, for the card i have at least, have one
> function where the per chip things are done (memory detection, bypass
> unit handling, framebuffer and memory management) and another set of
> functions which would be head, that is output, specific. This way, you
> would configure the /dev/fbx and when the user which to use this or that
> output, the DDC will be connected to the output, not the framebuffer.
> This seems a reasonable way of doing this and should solve your problem,
> no ?

Of course. But because of James decided that fbdev layer will automatically
choose appropriate resolution only from xres/yres, I need to have monitor
capabilities at the time upper layer asks to set videomode on /dev/fbx...
And it just sets it on /dev/fbx, leaving out both VTs (so I cannot remember
what mode was probed on each VT anymore) and outputs.
                                                                Petr
                                                                

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 03:55:48PM +0200, Petr Vandrovec wrote:
> 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.

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

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Petr Vandrovec]

On  3 Apr 03 at 15:11, Sven Luther wrote:
> On Thu, Apr 03, 2003 at 03:05:54PM +0100, Petr Vandrovec wrote:
> > On  3 Apr 03 at 14:38, Sven Luther wrote:
> > > On Thu, Apr 03, 2003 at 12:05:13PM +0100, Petr Vandrovec wrote:
> > > > No. With matroxfb, you have two framebuffer devices, /dev/fb0 &
> > > > /dev/fb1, which can be connected to any of three outputs: analog
> > > > primary, analog secondary and DVI. Analog primary & DVI share same
> > > > pair of DDC cables, and analog secondary has its own... And user can
> > > > interconnect fb* with outputs in almost any way he wants, as long as
> > > > hardware supports it.
> > > 
> > > Mmm, i have not been into fbdev much lately, but for my X devel work, i
> > > believe thta it is a good thing to separate the framebuffer issues from
> > > the output issues, and thus, for the card i have at least, have one
> > > function where the per chip things are done (memory detection, bypass
> > > unit handling, framebuffer and memory management) and another set of
> > > functions which would be head, that is output, specific. This way, you
> > > would configure the /dev/fbx and when the user which to use this or that
> > > output, the DDC will be connected to the output, not the framebuffer.
> > > This seems a reasonable way of doing this and should solve your problem,
> > > no ?
> > 
> > Of course. But because of James decided that fbdev layer will
> > automatically choose appropriate resolution only from xres/yres, I need to
> > have monitor capabilities at the time upper layer asks to set videomode on
> > /dev/fbx... And it just sets it on /dev/fbx, leaving out both VTs (so I
> > cannot remember what mode was probed on each VT anymore) and outputs.
> 
> Mmm, and at what time is the fbdev->output mapping done ?

At random time, when user asks to change fbdev->output mapping... And it 
still means that I have to create new EDID based on all EDIDs I read from 
each output - this is biggest problem, and that currently used videomode
can become invalid - and this is even worse problem.

In the past life was sweet, user apps showed windows that currently used
setting is unavailable, and offered some changes. Now when we are moving
more and more policy to the kernel...
                                                    Petr Vandrovec
                                                    

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Alan Cox]

On Iau, 2003-04-03 at 15:15, Sven Luther wrote:
> > 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.

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Alan Cox]

On Iau, 2003-04-03 at 17:21, Sven Luther wrote:
> > 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 ?

Yes

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 04:21:14PM +0100, Alan Cox wrote:
> On Iau, 2003-04-03 at 15:15, Sven Luther wrote:
> > > 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.

You mean, driving both display with the same ramdac ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Alan Cox]

On Iau, 2003-04-03 at 18:18, Sven Luther wrote:
> 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.

Re: [Linux-fbdev-devel] [PATCH]: EDID parser

[Sven Luther]

On Thu, Apr 03, 2003 at 06:33:17PM +0200, Geert Uytterhoeven wrote:
> On 3 Apr 2003, Alan Cox wrote:
> > On Iau, 2003-04-03 at 15:15, Sven Luther wrote:
> > > > 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.
> 
> 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