Hi

Am 21.06.21 um 08:27 schrieb Tomohito Esaki:
> Virtual DRM splits the overlay planes of a display controller into multiple
> virtual devices to allow each plane to be accessed by each process.
> 
> This makes it possible to overlay images output from multiple processes on a
> display. For example, one process displays the camera image without compositor
> while another process overlays the UI.

I briefly looked over your patches. I didn't understand how this is 
different to the functionality of a compositor? Shouldn't this be solved 
in userspace?

Best regards
Thomas

> 
> Virtual DRM driver doesn’t directly control the display hardware and has no
> access to the physical bus. Instead, the virtual DRM driver issues requests to
> the standard DRM device driver (parent) when the hardware needs to be
> controlled. The parent is modified to notify the virtual DRM driver of
> interruptevents from the display hardware. Therefore, in order to use virtual
> DRM, each DRM device driver needs to add code to support virutal DRM.
> 
> The only driver supported in this patch series is rcar-du. This patch series
> is divided into multiple. The first patch adds vDRM feature to DRM, and the
> second patch support vDRM for the rcar-du driver. The other patches add
> documentation.
> 
> In particular, I would appreciate your advice on the following points:
> * virtual DRM generalization
>    I've only tested with rcar-du, is there anything I should consider to make
>    virtual DRM work with other drivers?
> 
> * Integration to upstream
>    I think it is a good idea to add virtual DRM to the DRM core functionality,
>    but I would appreciate any suggestions on what needs to be improved for
>    integration to upstream.
> 
> * dumb_create and fb_create callback
>    I think that the dumb_create and fb_create callbacks need to be done by the
>    parent, and it is preferable to use the parent's callbacks as they are.
>    However, since the dumb buffer needs to be registered in the parent and
>    the fb handle needs to be registered in the drm_file of the vDRM, the
>    dumb_create callbacks from the parent driver cannot be used as is.
>    Therefore, the current implementation of the dumb_create callback is
>    workarround.
>    What do you think is the best way to deal with this issue?
> 
> 
> Tomohito Esaki (4):
>    Add Virtual DRM device driver
>    rcar-du: Add support virtual DRM device
>    dt-bindings: display: Add virtual DRM
>    doc-rst: Add virtual DRM documentation
> 
>   .../devicetree/bindings/display/vdrm.yaml     |  67 ++
>   Documentation/gpu/drivers.rst                 |   1 +
>   Documentation/gpu/vdrm.rst                    |  51 ++
>   drivers/gpu/drm/Kconfig                       |   7 +
>   drivers/gpu/drm/Makefile                      |   1 +
>   drivers/gpu/drm/rcar-du/Kconfig               |   4 +
>   drivers/gpu/drm/rcar-du/Makefile              |   1 +
>   drivers/gpu/drm/rcar-du/rcar_du_crtc.c        |  42 +
>   drivers/gpu/drm/rcar-du/rcar_du_crtc.h        |  13 +
>   drivers/gpu/drm/rcar-du/rcar_du_drv.c         |  13 +
>   drivers/gpu/drm/rcar-du/rcar_du_drv.h         |   3 +
>   drivers/gpu/drm/rcar-du/rcar_du_vdrm.c        | 191 ++++
>   drivers/gpu/drm/rcar-du/rcar_du_vdrm.h        |  67 ++
>   drivers/gpu/drm/rcar-du/rcar_du_vsp.c         |  22 +
>   drivers/gpu/drm/rcar-du/rcar_du_vsp.h         |   1 +
>   drivers/gpu/drm/vdrm/vdrm_api.h               |  68 ++
>   drivers/gpu/drm/vdrm/vdrm_drv.c               | 859 ++++++++++++++++++
>   drivers/gpu/drm/vdrm/vdrm_drv.h               |  80 ++
>   18 files changed, 1491 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/vdrm.yaml
>   create mode 100644 Documentation/gpu/vdrm.rst
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.c
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.h
>   create mode 100644 drivers/gpu/drm/vdrm/vdrm_api.h
>   create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.c
>   create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.h
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer