linux-kernel - Re: [PATH 0/4] [RFC] Support virtual DRM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9853d0a9-6053-db64-9c79-40b7e0689eec@suse.de>
Date:   Mon, 21 Jun 2021 09:10:19 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Tomohito Esaki <etom@...l.co.jp>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
Cc:     dri-devlel@...ts.freedesktop.org,
        linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATH 0/4] [RFC] Support virtual DRM

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



Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)