On Mon, 27 Apr 2020 at 16:58, Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > > On Mon, Apr 27, 2020 at 7:45 AM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > > > > On Fri, 24 Apr 2020 at 19:54, Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > > > > > > On Fri, Apr 24, 2020 at 4:11 AM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > > > > > > > > On Thu, 23 Apr 2020 at 23:51, Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > > > > > > > > > > The render node is required by Android which does not support the legacy > > > > > drmAuth authentication process. > > > > > > > > > > Signed-off-by: Peter Collingbourne <pcc@xxxxxxxxxx> > > > > > --- > > > > > drivers/gpu/drm/pl111/pl111_drv.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > The summary talks about drmAuth, yet exposes a render node. Even > > > > through there's no rendering engine in the HW, as mentioned by Eric. > > > > > > > > AFAICT the only way drmAuth is relevant with pl111 is when you want to > > > > export/import dma bufs. > > > > Although that is handled in core and the artificial DRM_AUTH > > > > restriction has been lifted with commit [1]. > > > > > > > > -Emil > > > > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.7-rc2&id=30a958526d2cc6df38347336a602479d048d92e7 > > > > > > Okay, most likely drmAuth is irrelevant here (I don't know much about > > > it to be honest; I know that Android uses render nodes, so I figured > > > that drmAuth must therefore be the thing that it doesn't use). Sorry > > > for the confusion. Here is a better explanation of why I needed this > > > change. > > > > > > Android has a composer process that opens the primary node and uses > > > DRM_IOCTL_MODE_ATOMIC to switch between frame buffers, and a renderer > > > process (surfaceflinger) that opens the render node, prepares frame > > > buffers and sends them to the composer. One idea for adapting this > > > architecture to devices without render nodes is to have the renderer > > > process open the primary node instead. But this runs into a problem: > > > suppose that the renderer process starts before the composer process. > > > In this case, the kernel makes the renderer the DRM master, so the > > > composer can't change the frame buffer. Render nodes don't have this > > > problem because opening them doesn't affect the master. > > > > > > I considered fixing this by having the composer issue > > > DRM_IOCTL_SET_MASTER, but this requires root privileges. If we require > > > drivers to provide render nodes and control access to the primary node > > > while opening up the render node, we can ensure that only authorized > > > processes can become the master without requiring them to be root. > > > > > I think that the crux, is trying to open a _primary_ node for > > _rendering_ purposes. > > While that may work - as you outline above - it's usually a bad idea. > > > > To step back a bit, in practise we have three SoC combinations: > > - complete lack of render device - then you default to software rendering [1] > > - display and render device are one and the same - no change needed, > > things should just work > > - display and render devices are separate - surfaceflinger should > > open the correct _rendering_ device node. > > > > [1] Mesa's libEGL (don't recall exact name on Android) can open VGEM > > (Android uses SwiftShader for software rendering, not Mesa, FWIW.) > I don't know much about SwiftShader. > > render node, to work with the kms-swrast_dri.so software rasteriser > > module. > > > > While I did not try [1] with Android, it was working fine with CrOS. I > > suggest giving it a try and reporting bugs. > > I'm not sure I understand your suggestion, or at least how it would > work on Android. The composer process wouldn't be able to use > DRM_IOCTL_MODE_ATOMIC to display a frame buffer produced by the > surfaceflinger process using a vgem render node, would it? It's a > different driver so the memory region used for the frame buffer > wouldn't necessarily be compatible with the pl111 device. As far as I > know, the frame buffer would need to be produced using a pl111 render > node. > The pl111 will create a buffer, exports it. Renderer will import and draw onto it. Upon completion, the composer will DRM_IOCTL_MODE_ATOMIC the pl111 buffer. I believe this approach has been used for a few years now. -Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
