I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it.
Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2].
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides....
Hi Rob,
On 4 December 2015 at 17:49, Rob Herring robh@kernel.org wrote:
I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it.
Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2].
drmPrimeHandleToFD definitely is allowed on card0; does the driver set the DRIVER_PRIME cap, and have a prime_handle_to_fd hook?
Cheers, Daniel
On 04/12/15 19:49, Rob Herring wrote:
I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it.
Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2].
Obsolete when using render nodes, but still necessary on usual nodes (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the render nodes can do.
Authentication should help! Please make sure you are master or authenticated before doing anything on the usual nodes.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.... _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
Benjamin
Le vendredi 4 décembre 2015, Martin Peres martin.peres@linux.intel.com a écrit :
On 04/12/15 19:49, Rob Herring wrote:
I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it.
Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2].
Obsolete when using render nodes, but still necessary on usual nodes (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the render nodes can do.
Authentication should help! Please make sure you are master or authenticated before doing anything on the usual nodes.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.... _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc?
Rob
Benjamin
Le vendredi 4 décembre 2015, Martin Peres martin.peres@linux.intel.com a écrit :
On 04/12/15 19:49, Rob Herring wrote:
I'm working on getting Android working with DRM drivers. ATM, I'm using virtio-gpu as the driver and trying to get just KMS side working without rendering. I have it working with stock AOSP and the emulated fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to get things working with native KMS using drm_gralloc and drm_hwcomposer (now in AOSP). I've hit one problem though which I'm not sure how to solve without hacking around it.
Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not allowed on render nodes and drmPrimeHandleToFD is not allowed on card0, so I'm stuck. I could open both nodes, but then I want the case of no render node to work. After some searching, I thought it was a matter of needing to do drmAuthMagic, but then found that is considered obsolete[2].
Obsolete when using render nodes, but still necessary on usual nodes (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the render nodes can do.
Authentication should help! Please make sure you are master or authenticated before doing anything on the usual nodes.
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4 [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.... _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 12/04/2015 11:23 AM, Rob Herring wrote:
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc?
Rob
Frankly, you probably want to approach this by allocating dma-bufs using something external to DRM (probably ion) and then have your hwcomposer import them into DRM when they're passed to the display.
Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc is designed: like dma-buf, it's built around passing buffers between different hardware blocks, and some of those buffers may never even touch the display hardware. You'll also run up against other (deliberate) limitations of dumb BOs like not being able to allocate YUV buffers.
Unfortunately this currently means adding some shim driver code to create the ion device. (Device-Tree bindings for ion are on my long, long backlog of things to do.) It's not a lot of code, especially if all you need is a CMA heap, but it's still non-zero.
Note that supporting dumb BOs in your KMS driver is still useful, since the recovery console in AOSP has KMS support now. In that case it's a single privileged process software-rendering everything, so it bypasses gralloc/hwcomposer and calls directly into libdrm.
On Fri, Dec 04, 2015 at 03:48:26PM -0800, Greg Hackmann wrote:
On 12/04/2015 11:23 AM, Rob Herring wrote:
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc?
Rob
Frankly, you probably want to approach this by allocating dma-bufs using something external to DRM (probably ion) and then have your hwcomposer import them into DRM when they're passed to the display.
Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc is designed: like dma-buf, it's built around passing buffers between different hardware blocks, and some of those buffers may never even touch the display hardware. You'll also run up against other (deliberate) limitations of dumb BOs like not being able to allocate YUV buffers.
Unfortunately this currently means adding some shim driver code to create the ion device. (Device-Tree bindings for ion are on my long, long backlog of things to do.) It's not a lot of code, especially if all you need is a CMA heap, but it's still non-zero.
Yeah at plumbers in seattle we discussed this and pretty much all agreed that for these kind of embedded cases ION makes tons of sense as the backing allocator. Trying to use dumb buffers for everything really isn't how it's meant to be, and it shows in all the hacks added and hoops you still need to jump through.
As Greg says there's some polish left to do for really neat ION integration, but we captured that in drivers/staging/android/TODO.
Note that supporting dumb BOs in your KMS driver is still useful, since the recovery console in AOSP has KMS support now. In that case it's a single privileged process software-rendering everything, so it bypasses gralloc/hwcomposer and calls directly into libdrm.
Yeah, dumb buffers is for emergency consoles and for boot splash (where loading GL is either not yet possible or too expensive). Anything else will result in sizeable amounts of hurt. -Daniel
On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann ghackmann@google.com wrote:
On 12/04/2015 11:23 AM, Rob Herring wrote:
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc?
Rob
Frankly, you probably want to approach this by allocating dma-bufs using something external to DRM (probably ion) and then have your hwcomposer import them into DRM when they're passed to the display.
Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc is designed: like dma-buf, it's built around passing buffers between different hardware blocks, and some of those buffers may never even touch the display hardware. You'll also run up against other (deliberate) limitations of dumb BOs like not being able to allocate YUV buffers.
Yes, I realize dumb BO are not the long term nor production solution. ATM, I'm just looking for getting things working on new platforms without the need for lots of userspace changes. Perhaps I could just use fb emulation, but having DRM code paths tested is valuable IMO.
Unfortunately this currently means adding some shim driver code to create the ion device. (Device-Tree bindings for ion are on my long, long backlog of things to do.) It's not a lot of code, especially if all you need is a CMA heap, but it's still non-zero.
Laura is working on that. I'm still a bit skeptical about what should go in DT though.
Note that supporting dumb BOs in your KMS driver is still useful, since the recovery console in AOSP has KMS support now. In that case it's a single privileged process software-rendering everything, so it bypasses gralloc/hwcomposer and calls directly into libdrm.
I've not seen that. Where does that live?
Rob
On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring robh@kernel.org wrote:
On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann ghackmann@google.com wrote:
On 12/04/2015 11:23 AM, Rob Herring wrote:
On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard benjamin.gaignard@linaro.org wrote:
Hi Rob,
I got the same problem today with sti drm/kms driver and dumb Bo. The issue comes become hwcomposer because is the master and authenticated on /dev/dri/cardX Dumb allocation is done by gralloc which does a new open (so it is not authenticated) on drm node the consequence is that we can't use prime functions... If you use render node you won't be able to call dumb functions.
To get out of this I think I will implement additional helpers in gem_cma to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP and call them instead of dumb so be able to use render node. Of course it is only for drivers which already use gem_cma helpers (like sti)
That's only marginally better than per driver BO calls which is the whole thing I'm trying to avoid. There should be some way to pass the auth token to gralloc?
Rob
Frankly, you probably want to approach this by allocating dma-bufs using something external to DRM (probably ion) and then have your hwcomposer import them into DRM when they're passed to the display.
Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc is designed: like dma-buf, it's built around passing buffers between different hardware blocks, and some of those buffers may never even touch the display hardware. You'll also run up against other (deliberate) limitations of dumb BOs like not being able to allocate YUV buffers.
Yes, I realize dumb BO are not the long term nor production solution. ATM, I'm just looking for getting things working on new platforms without the need for lots of userspace changes. Perhaps I could just use fb emulation, but having DRM code paths tested is valuable IMO.
Unfortunately this currently means adding some shim driver code to create the ion device. (Device-Tree bindings for ion are on my long, long backlog of things to do.) It's not a lot of code, especially if all you need is a CMA heap, but it's still non-zero.
Laura is working on that. I'm still a bit skeptical about what should go in DT though.
Note that supporting dumb BOs in your KMS driver is still useful, since the recovery console in AOSP has KMS support now. In that case it's a single privileged process software-rendering everything, so it bypasses gralloc/hwcomposer and calls directly into libdrm.
I've not seen that. Where does that live?
https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc98...
Stéphane
Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Benjamin Gaignard -
Daniel Stone -
Daniel Vetter -
Greg Hackmann -
Martin Peres -
Rob Herring -
Stéphane Marchesin