Hey

On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter [off-list ref] wrote:

quoted

quoted

So it is possible, only reason vram dumb buffers look worse is that there's
only 3 and no one cares about them, vs about 20 and a very active community
of contributors (also for core drm improvements) for the other case.

Well, we could move offb to drm while at it I suppose that would be another
one (offb is the "dumb driver based on pre-programmed output by firmware).

One of the still in-flight drm drivers is the simpledrm thing meant for
all kinds of firmware drivers like efifb and similar things on arm for
pre-programmed output set up by firmware. I.e. no modeset support and
otherwise a lot of fake to make it work as drm driver, but the idea that
it's good enough until your real drm driver takes over.

The x86 platform device fixups for SimpleDRM went in some weeks ago,
so maybe I should resend the patches. The driver could easily do
'offb'-like devices as well. Trivial to add.

Anyway, Benjamin is right, we always do shadow buffering for trivial
drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or
dirty-ioctl. Reason is that we cannot easily expose the real
framebuffer in DRM via FB-objects. But I also never saw a use-case for
it, since all trivial devices I worked with were only either used as
fallback or nobody cared for performance.

The generic DRM API is designed for dynamic FB allocation. If your
hardware does not allow you to change the scanout source, you will
have a hard time trying to expose the static buffers via the dynamic
FB-object API. Furthermore, all DRM user-space expects dynamic FB
management to work, preferably without a ridiculously low memory
limit. That's also why I never bothered changing the drivers.

Despite all of this I still see no reason why a driver could not
expose the static, real frambuffers via private ioctls. You can get
all your fancy acceleration that way. Then fix user-space to use this
API. If enough drivers end up with something similar, move it into the
core. Just like we always do in DRM.

Thanks
David