On Wed, 1 Apr 2026 09:46:08 +0200 Michel Dänzer <[email protected]> wrote:
> On 3/31/26 16:21, Pekka Paalanen wrote: > > On Tue, 31 Mar 2026 14:56:22 +0200 > > Michel Dänzer <[email protected]> wrote: > >> On 3/31/26 14:38, Pekka Paalanen wrote: > >>> On Tue, 31 Mar 2026 10:01:59 +0200 > >>> Michel Dänzer <[email protected]> wrote: > >>>> On 3/26/26 14:53, Pekka Paalanen wrote: > >>>>> On Tue, 24 Mar 2026 17:44:21 +0100 > >>>>> Michel Dänzer <[email protected]> wrote: > >>>>> > >>>>>> * There's no clear use case. > >>>>>> > >>>>>> This is generally a requirement for new KMS UAPI. > >>>>>> > >>>>>> The practical usefulness of the corresponding weston MR is dubious > >>>>>> per the concern above. > >>>>> > >>>>> I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc > >>>>> rather than RGB 8 bpc is an excellent use case. > >>>> > >>>> This series and the corresponding Weston MR aren't enough to address > >>>> that use case though, are they? All they achieve is logging a > >>>> potentially misleading warning. > >>>> > >>>> It might make sense to combine this series and the Weston MR with > >>>> whatever else is needed for that use case. > >>> > >>> What do you believe is missing? > >> > >> For the stated use case, e.g. a mechanism to control RGB vs YCbCr? > > > > There is no need for that. Currently the driver chooses the color model > > and depth on its own. We just want to make sure it's not too low. > > What can be done when it's too low though? Notify the end user that their system is not performing up to their parameters. They may need to consider changing hardware. Thanks, pq > The only thing I can see is setting a higher "max bpc" value. If > that's acceptable and helps though, why was the lower value set in > the first place? (Otherwise the weston MR doesn't log the warning) > > > I feel like I'm still missing a piece of the picture for the > practical use. >
pgpgKIcsm5Uvl.pgp
Description: OpenPGP digital signature
