Closed utzcoz closed 6 years ago
My mclient
and debian
are both arm64
and the recvmsg
receives the correct message from mflinger
.
@utzcoz Brilliant debugging! Thank you so much for tracing this issue. I have never tested Maru on a Rockchip device so I had no idea their gralloc buffers fds were readonly.
I need to look into whether there is another way we can map gralloc buffers to memory in mclient. Ideally, we use the actual HAL libraries to do this just like an Android process would do. Something like libhybris has been requested for a while now, which should let mclient link against the Android graphics libraries directly. I am sure this will require a lot of changes but it is on the list and is being experimented on by some of our community (see https://github.com/maruos/maruos/issues/38).
I am glad you found a temporary solution for now at least!
I also linked to this issue from mflinger, which is the repo where mclient code lives: https://github.com/maruos/mflinger/issues/6
@pdsouza Thank's for your reply. I'm glad to hear the hardware acceleration is on the progress. I will close the issue, and it also can be searched by the user encounters similar problem now or later. If this issue will help someone, I'll be honor.
Hi @pdsouza , I encountered a problem that
mclient
'smmap
failed onrockchip
devices because ofpermission denied
. After some days' debug, I found therockchip
set bufferfd
's access mode to0
(READONLY), when it try to transfer shared bufferfd
which created byrockchip
gralloc
implementation to user space. InAOSP
, there is a code snippet to do the same thing. To fix this problem, I just#include <fcntl.h>
and change0
toO_RDWR
to make sure thefd
has ther/w
access mode.I don't have a better solution to avoid
mclient
's use ofmmap
, so I just note the problem I encountered, and hope it will be helpful for someone who has the same problem now or later.Thanks.