mmap failed on rockchip devices

[utzcoz]

Hi @pdsouza , I encountered a problem that mclient's mmap failed on rockchip devices because of permission denied. After some days' debug, I found the rockchip set buffer fd's access mode to 0(READONLY), when it try to transfer shared buffer fd which created by rockchip gralloc implementation to user space. In AOSP, there is a code snippet to do the same thing. To fix this problem, I just #include <fcntl.h> and change 0 to O_RDWR to make sure the fd has the r/w access mode.

I don't have a better solution to avoid mclient's use of mmap, 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.

[utzcoz]

My mclient and debian are both arm64 and the recvmsg receives the correct message from mflinger.

[pdsouza]

@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

[utzcoz]

@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.