On Wed, Aug 27, 2025 at 12:36:53PM +0100, Daniel Stone wrote: > Hey, > > On Wed, 27 Aug 2025 at 12:21, Maxime Ripard <mrip...@kernel.org> wrote: > > On Wed, Aug 27, 2025 at 11:39:25AM +0100, Daniel Stone wrote: > > > There are other reasons to have uAPI though ... > > > > > > One is because you really care about the colour properties, and you'd > > > rather have better fidelity than anything else, even if it means some > > > modes are unusable. > > > > > > Another is for situations which static quirks can't handle. If you > > > want to keep headroom on the link (either to free up bandwidth for > > > other uses), or you accidentally bought a super-long cable so have a > > > flaky link, you might well want to force it to use lower fidelity so > > > you can negotiate a lower link rate. > > > > > > I'm all for just dtrt automatically, but there are definitely reasons > > > to expose it to userspace regardless. > > > > Oh, yeah, definitely. > > > > But bringing the big guns and the requirements we have for those to > > address the point initially discussed by the gitlab issues seems like > > biting off more than they can chew. > > > > Even more so since whatever uapi we come up with would still depend on > > the EDIDs, and they would still be broken for these monitors. > > Sounds like we're agreeing with each other then. > > Shengyu's 'I want these broken panels to work' usecase is probably > best served with an EDID quirk, yeah. > > The reason Marius is working on it is the reasons I said above though > - some for uses where we'd rather clearly fail out and push an error > to userspace than continue with visually-degraded output, and some for > uses where people have bought a too-long cable (or bought a too-short > one which is now at tension through a 180° bend) so we want to force > the lowest link rate possible, without dropping to a ridiculously low > resolution. > > So I don't think these are in tension, and Marius should proceed with > his work (complete with the proper userspace to back it up), and > Shengyu should proceed with new in-kernel quirks, which will be > effective when the properties are set to auto, but hard overridden by > userspace if it decides otherwise. > > How does that sound?
Like a great plan :) Maxime
signature.asc
Description: PGP signature
