On Fri, Sep 30, 2022 at 06:45:09PM +0300, Ville Syrjälä wrote: > On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote: > > On Fri, 30 Sep 2022 18:09:55 +0300 > > Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > > > That would actively discourage people from even attempting the > > > "just dump all the state into the ioctl" approach with async flips > > > since even the props whose value isn't even changing would be rejected. > > > > About that. > > > > To me it looks like just a classic case of broken communication. > > > > The kernel developers assume that of course userspace will minimize the > > state set to only those properties that change, because...? > > > > Userspace developers think that of course the kernel will optimize the > > state set into minimal changes, because the kernel actually has the > > authoritative knowledge of what the current state is, and the driver > > actually knows which properties are costly and need to be optimized and > > which ones don't matter. It has never even occurred to me that the > > kernel would not compare next state to current state. > > > > No-one ever documented any expectations, did they? > > Do you really want that for async flips? Async flips can't be > done atomically with anything else, so why are you even asking > the kernel to do that? Also what if you want plane 1 to do an async flip, and plane 2 to do a sync flip? With the single async flag per commit you will end up with one of the following results: plane 1 plane 2 outcome can async can async async flip on both planes (totally not what you wanted) can async can't async -EINVAL (what you actually wanted but got unfairly rejected) can't async can async -EINVAL can't async can't async -EINVAL Those last two are actually reasonable outcomes since the plane where you did want to async flip didn't support it. But the first two are just nonsense results. -- Ville Syrjälä Intel
