On Sat, May 6, 2017 at 7:13 PM, Mauro Rossi <issor.or...@gmail.com> wrote: > > > 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?
We use crosreview.com/329448 and crosreview.com/356621 . > > But will this suffice or WuZhen changes in egl/android are anyway, maybe > partialy needed? I believe the 3 steps should be all you need, assuming that your gralloc uses render nodes and prime FDs. Best regards, Tomasz _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
