On Mon, Jul 21, 2014 at 06:06:30PM +0100, Russell King - ARM Linux wrote: > On Mon, Jul 21, 2014 at 03:43:13PM +0200, Boris BREZILLON wrote: > > How about using a list instead of an array ? > > This way we can add elements to this list when parsing the EDID. > > > > Or we can just define a maximum size for the bus_formats array when > > retrieving this info from EDID. If I'm correct we have at most 18 bus > > formats: > > - 3 color formats: > > * RGB 4:4:4 > > * YCbCr 4:4:4 > > * YCbCr 4:4:2 > > - 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color > > This starts to worry me. What are we trying to do here - are we trying > to encode the connection between the CRTC and the encoder, the encoder > and the connector, or the connector and the device? This is about the bus format of the panel device. That would make it the latter. > The encoder to connector and connector to device is mostly a function of > the interface spec itself (for example, many HDMI encoders take either a > RGB or YUV input and can convert it to the HDMI specified colourspaces for > transmission over the connector.) The discussion here started because we currently have no way to store information about the interface for raw RGB. That means currently all drivers need to hardcode assumptions about the mode. The idea was to make this information available via a field in drm_display_info so that drivers could reconfigure depending on what the attached panel expects. This doesn't only apply to panels, though, the issue is the same when a bridge (RGB/LVDS for example) is connected to the encoder. > If you want to do encoder to connector, what about VGA or some other > analogue signalling such as TV composite? It's easy to take this too > far... > > Surely the only one which matters is the CRTC to the encoder - that's > certainly true of all the setups I've come across so far. As for that > interface, CRTCs I've seen can produce a /wide/ range of different > representations. > > Some CRTCs (eg, AMBA CLCD) produce R, G, B signals scrunched down on to > the LSB bits of a LCD data bus (so RGB888 uses 24 bits, RGB444 would > use the LSB 12 bits of those 24 - rather than outputting the R4 bits on > a subset of the R8 bits.) > > What about RGB565 - where you have differing number of bits for the > green channel from red/blue? > > Then you have red/blue colour swapping at the CRTC (and similar for YUV) > such as on Dove / Armada. > > Then there are some encoders have the ability to almost arbitarily map > their input pins according to whatever you choose (eg, TDA998x). > > This problem isn't as quite as simple as "this is what EDID gives us" > and "these are the number of bits representing a colour". I think what we need is a way to pass information from whatever device is behind the encoder (be it a bridge or a panel) to the encoder. And likely we'll need a similar (or the same) way to pass that information from bridge to bridge or from bridge to panel. That way the encoder can ask the bridge (or panel) about the format it requires and reconfigure itself accordingly. This should be able to work with an arbitrary bridge -> [bridge... ->] panel chain where each element in the chain can reconfigure depending on what the next element requires (or fail if it can't work, which should really never happen). Thierry
Attachment:
pgpUurtGMyJ9x.pgp
Description: PGP signature
