Hi, Sounds OK to me too.
Cheers, Shengyu 在 2025/8/27 19:36, Daniel Stone 写道:
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? Cheers, Daniel
OpenPGP_0xE3520CC91929C8E7.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
