On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote: > Hi Thierry, > > On Monday 21 July 2014 14:55:23 Thierry Reding wrote: > > On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote: > > > On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote: > > >> On Monday 21 July 2014 14:12:47 Thierry Reding wrote: > > >>> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote: > > [snip] > > > >>>> The new drm_display_info structure should look like this [2] (except > > >>>> that color_formats and bpc have not be removed yet), and [1] is just > > >>>> here to show how the video_bus_format enum would look like. > > >>>> > > >>>> [1] http://code.bulix.org/rfd0yx-86557 > > >>>> [2] http://code.bulix.org/7n03b4-86556 > > >>> > > >>> Quoting from your paste: > > >>> + const enum video_bus_format *bus_formats; > > >>> + int nbus_formats; > > >>> > > >>> Do we really need more than one? > > >> > > >> We do if we want to replace the color_formats and bpc fields. > > > > > > Yes, that's what I was about to answer :-). > > > > Maybe we don't need to replace color_formats and bpc field immediately. > > That could be done in a follow-up patch. > > We don't need to replace them right now, but we should at least agree on how > to replace them. Introducing a new field that would need to be replaced in the > near future when removing color_formats and bpc would be a waste of time. Sure. One of the problems I see with replacing color_formats and bpc with the above is that some of the bits within color_formats are set when the EDID is parsed. That implies that if they are replaced with an array of formats, the array would need to be reallocated during EDID parsing. That sounds like ugliness. But if you can find a nice way to make it work that'd be great. Thierry
Attachment:
pgpPedEqg2NHh.pgp
Description: PGP signature
