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

Robert Foss robert.foss at collabora.com
Wed Aug 1 14:14:48 UTC 2018

Hey Rob,

On 2018-07-18 15:30, Rob Herring wrote:
> 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.
> 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

More information about the mesa-dev mailing list