On Thu, Aug 03, 2023 at 02:34:58PM +0200, Neil Armstrong wrote: > > > > > > I think I'll still like to have something clarified before we merge it: > > > > > > if userspace forces a mode, does it contain the margins or not? I don't > > > > > > have an opinion there, I just think it should be documented. > > > > > > > > > > The mode comes with the margins, so if userspace does something really > > > > > funny then either it gets garbage (as in, part of it's crtc area isn't > > > > > visible, or maybe black bars on the screen), or the driver rejects it > > > > > (which I think is the case for panels, they only take their mode and > > > > > nothing else). > > > > > > > > Panels can usually be quite flexible when it comes to the timings they > > > > accept, and we could actually use that to our advantage, but even if we > > > > assume that they have a single mode, I don't think we have anything that > > > > enforces that, either at the framework or documentation levels? > > > > > > Maybe more bugs? We've been slowly filling out all kinds of atomic kms > > > validation bugs in core/helper code because as a rule of thumb, > > > drivers get it wrong. Developers test until things work, then call it > > > good enough, and very few driver teams make a serious effort in trying > > > to really validate all invalid input. Because doing that is an > > > enormous amount of work. > > > > > > I think for clear-cut cases like drm_panel the fix is to just put more > > > stricter validation into shared code (and then if we break something, > > > figure out how we can be sufficiently lenient again). > > > > Panels are kind of weird, since they essentially don't exist at all in > > the framework so it's difficult to make it handle them or their state. > > > > It's typically handled by encoders directly, so each and every driver > > would need to make that check, and from a quick grep, none of them are > > (for the reasons you said). > > > > Just like for HDMI, even though we can commit to changing those facts, > > it won't happen overnight, so to circle back to that series, I'd like a > > comment in the driver when the partial mode is enabled that if userspace > > ever pushes a mode different from the expected one, we'll add the margins. > > To be fair, a majority of the panel drivers would do the wrong > init of the controller with a different mode because: > - mainly the controller model is unknown > - when it's known the datasheet is missing > - when the datasheet is here, most of the registers are missing > - and most of the time the timings are buried in the init sequence > > It's sad but it's the real situation. Again, I agree. As far as I'm aware, none of them add arbitrary numbers to timings though, so it's easy enough to figure out what the mode is meant to be: it's the mode. Here, we add some numbers to the mode, so the interaction with the userspace forcing a mode is less clear. > Only a few drivers can handle a different mode, and we should perhaps > add a flag when not set rejecting a different mode for those controllers and > mark the few ones who can handle that... > And this should be a first step before adding an atomic Panel API. I'm really just asking for a comment in the code here. Everything that you mentioned are improvements that we should have on our todo list, but I don't see them as pre-requisite for this series and we get to it later on. Maxime
Attachment:
signature.asc
Description: PGP signature
