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. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
