2017-05-05 19:14 GMT+02:00 Rob Herring <robherri...@gmail.com>: > On Mon, May 1, 2017 at 9:55 AM, Tomasz Figa <tf...@chromium.org> wrote: > > On Mon, May 1, 2017 at 11:17 PM, Mauro Rossi <issor.or...@gmail.com> > wrote: > >> Hi all, > >> > >> another try to merge android swrast patches in mesa 17.1 or mesa-dev > >> if they are somehow considered useful for android. > > I would really like to, but all my attempts at getting swrast to work > so far have failed. > > >> > >> Mauro > >> > >> > >> 2017-01-20 20:17 GMT+01:00 Mauro Rossi <issor.or...@gmail.com>: > >>> > >>> > >>> > >>> Il lunedì 9 gennaio 2017, Zhen Wu <wuz...@jidemail.com> ha scritto: > >>>> > >>>> Thanks for your review, Rob. Using kms-dri would mean writing a new > >>>> gralloc to basically the same thing as > >>>> gralloc.default and moving to grm_gralloc seems to be a bigger task > meant > >>>> for another day. But I agree we would > >>>> want to avoid introducing dependency. Would extending drisw loader > func > >>>> and limit gralloc dependency in egl_android > >>>> ok with you? > >>> > >>> > >>> Just to avoid a stall situation, > >>> > >>> I get that Rob comments are here as here is the gralloc dependency to > be > >>> avoided. > >>> Is this assumption correct? > >>> > >>> BTW I can also confirm patches are working as I tested with Android CTS > >>> dEQP test for EGL and GLES2 modules with marshmallow-x86 > >>> > >>> Mauro > >> > >> > >> Hi Rob, > >> we are still maintaining these changes to use llvmpipe > >> they are working and they are useful for testing on VMs and for software > >> rendering. > >> > >> May I kindly jask if the unwanted gralloc dependency was essentially in > >> this patch 07/08 > >> "android: support creating texture from gralloc buffer"? > >> > >> And if that is confirmed, which approaches are applicable here? > >> > >> 1. Reuse some kms-dri specific change implemented in CrOS (? Tomasz did > you > >> neeed to change something in dri/sw winsys ? ) > > > > Did you by any chance mean kms_swrast? If so, we don't need any > > changes other than falling back to kms-dri in > > egl/drivers/dri2/platform_android.c, if hardware driver fails to load. > > See this patch: https://chromium-review.googlesource.com/c/442414/ . > > > > However on ChromeOS we disallow access to DRI control nodes from > > render processes, so we use DRI render nodes and have a local patch > > for the kernel to allow dumb BO ioctls on render nodes. If you can use > > control nodes, you should be okay with the code as is. > > I've got this kind of working with the above patch and disabling all > DRM permission checks. While it seems like things boot up normally, I > can't get anything but a black screen both on qemu and db410c. Even if > I memset buffers when mmapping them, just black. But things like > moving the mouse causes hwc updates and I don't see any errors. I've > successfully used SwiftShader for s/w rendering though. > > Rob >
Hi, we have DRM permission checks disabled in android-x86 kernels. In order to give it a try on virtualbox, do I just need: 1) build kms_swrast 2) apply the fallback patch to egl/drivers/dri2/platform_android.c 3) apply patch to kernel? Where may I get this kernel patch? But will this suffice or WuZhen changes in egl/android are anyway, maybe partialy needed? Mauro
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
