On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > > On 2/3/23 07:59, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä > > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > >> On Fri, Feb 03, 2023 at 02:07:44AM +0000, Joshua Ashton wrote: > >>> Userspace has no way of controlling or knowing the pixel encoding > >>> currently, so there is no way for it to ever get the right values here. > >> > >> That applies to a lot of the other values as well (they are > >> explicitly RGB or YCC). The idea was that this property sets the > >> infoframe/MSA/SDP value exactly, and other properties should be > >> added to for use userspace to control the pixel encoding/colorspace > >> conversion(if desired, or userspace just makes sure to > >> directly feed in correct kind of data). > > > > I'm all for getting userspace control over pixel encoding but even > > then the kernel always knows which pixel encoding is selected and > > which InfoFrame has to be sent. Is there a reason why userspace would > > want to control the variant explicitly to the wrong value? > > > > I've asked this before but haven't seen an answer: Is there an existing > upstream userspace project that makes use of this property (other than > what Joshua is working on in gamescope right now)? That would help us > understand the intent better. The intent was to control the infoframe colorimetry bits, nothing more. No idea what real userspace there was, if any. > > I don't think giving userspace explicit control over the exact infoframe > values is the right thing to do. Only userspace knows what kind of data it's stuffing into the pixels (and/or how it configures the csc units/etc.) to generate them. I really don't want a repeat of the disaster of the 'Broadcast RGB' which has coupled together the infoframe and automagic conversion stuff. And I think this one would be about 100x worse given this property has something to do with actual colorspaces as well. -- Ville Syrjälä Intel
