Hey Rob,
On 2018-07-18 15:30, Rob Herring wrote:
On Tue, Jul 17, 2018 at 4:33 AM Robert Foss <robert.f...@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.
I've started a discussion about this on the LKML[1], but I havent really managed
to get it off the ground.
But, about VGEM, what are the complicated parts you're referring to ^^?
I'm only asking, because I have a pretty poor understanding of what it would
look like.
[1] https://lkml.org/lkml/2018/7/24/187
Rob
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
