[Mesa-dev] [PATCH v2 0/4] Android kms_swrast support

Rob Herring robh at kernel.org
Wed Jul 18 13:30:17 UTC 2018


On Tue, Jul 17, 2018 at 4:33 AM Robert Foss <robert.foss at collabora.com> wrote:
>
> This series implements kms_swrast support for the Android
> platform. And since having to debug a null pointer dereference,
> simplify that process for the next guy.

So is this working for you now?

> As it stands now, any kernel must have the following ioctls flagged with
> DRM_RENDER_ALLOW[1], which isn't the case in the mainline kernel.
>
> DRM_IOCTL_MODE_CREATE_DUMB
> DRM_IOCTL_MODE_MAP_DUMB

Ah, sorry. I should have mentioned this. We have discussed this issue
in the past, but to no further conclusion.

But as I recall, I thought the issue was also allowing import and
export of dumb buffers?

> While it would be possible to open a non-render node to pass the
> authentication check, this would still cause authentication issues
> when the /dev/dri/cardX node needs to be opened as master by both mesa
> and the compositor.

Right. We've pretty much stripped the support that was there out. Plus
I don't think it will work with Treble.

> I don't know how acceptable this series is for upstreaming, while relying on
> a non-mainline kernel. I think the policy is to not accept changes that
> don't have both a user and kernel space solution in place.
>
> Like I noted yesterday[2] the alternative to using dumb buffers and having
> authentication issues is using VGEM, which is new territory to me, and it would
> take me a little bit of time to figure exactly how it fits into the current
> kms_swrast approach.
> Input, like noted before, is very much welcome.

I'm very much in favor of the former approach. VGEM seems like an
overly complicated solution when there's a very simple solution.

Rob


More information about the mesa-dev mailing list