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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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.