On Mon, Sep 2, 2019 at 4:40 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > Hm... my recollection is that command mode is only supported on "smart" > panels that have an internal framebuffer. So the commands actually > instruct the panel to update their internal framebuffer, which means you > can technically switch off the display engine when there are no updates. That is my understanding as well. > Under those circumstances I think it'd make sense to default to command > mode if both the panel and the host support it and stick with video mode > if for example the host can't do command mode. Makes sense to me. Maybe we should rather have a generic setting like: dsi-enforce-video-mode; and the default always being command mode, if we have consensus that command mode should always be preferred. > Or perhaps this is something that could be set from some userspace > policy maker via a connector property? A compositor for instance would > have a pretty good idea of what kind of activity is going on, so it > could at some point decide to switch between video mode and command mode > if one of them is more appropriate for the given workload. It's probably more that userspace should be made aware of the fact that we have partial updates, and if I understand correctly that is done by dirtyrect/damage API in drm_damage_helper.c (Very nice overview doc at the top of the file!) The driver enables damage by calling drm_plane_enable_fb_damage_clips() then in the .update() callback uses drm_atomic_helper_damage_merged() to figure out damaged rectangles and update those with special commands. tinydrm/ili9225.c is a pretty clean example of a driver actually doing this. There are not many of them. > Command mode can also be used to do partial updates, if I remember > correctly, which again would make it possible for a compositor to send > only a subset of a screen update. Indeed, who needs a blitter when you can just update the dirtyrects. It is a bit terse but intuitively I feel that the damage interface is what userspace should use, then DRM should be able to infer that a damaged rectangle can be updated on the display, and the display controller need to announce that it can handle these partial updates. This requires that the display controller can generate such complex command streams in response to drm_atomic_helper_damage_merged() of course, from a DSI protocol level it is supported, but we are not writing these command sequences with software, they are generated by hardware. So the display controller DSI portions must be able to send individual rectangles as well. But this is all science fiction. What all DSI display controllers in mailine do today (I think) is to simply scan out the whole framebuffer continously with a vblank TE IRQ to avoid tearing. Andrzej knows for sure what is out there I think. Yours, Linus Walleij
