CC to the android-x86 devel list so more developers can follow. 2016-01-21 6:19 GMT+08:00 Rob Clark <robdcl...@gmail.com>: > On Wed, Jan 20, 2016 at 4:59 PM, Rob Herring <r...@kernel.org> wrote: >> Hi Sean, >> >> On Thu, Jan 14, 2016 at 1:15 PM, Sean Paul <seanp...@chromium.org> wrote: >>> >>> >>> On Thu, Jan 14, 2016 at 9:47 AM, Chih-Wei Huang <cwhu...@android-x86.org> >>> wrote: >>>> >>>> Hello Sean, >>>> My last try of drm_hwcomposer failed due to >>>> my limited time and knowledge. >>>> >>>> Fortunately more developers join us >>>> to work on this topic now, including >>>> Rob Herring (kernel drm developer), >>>> Rob Clark and Emil Velikov (Mesa developers) >>>> We are working on drm_hwcomposer >>>> for virtio-gpu, the emulated GPU for QEMU. >>>> >>>> If you don't mind, I would invite you to join >>>> our devel group for the discussion. >>> >>> >>> [adding Emil, Rob, and Rob] >>> >>> Hi, >>> Ok, I've signed up for the android-x86 list. I don't anticipate seeing all >>> posts, so please cc me on threads needing feedback. >>> >>> We also just today open-sourced drm_hwcomposer on the chromium gerrit >>> instance, such that we'll be doing all of our development in the open on >>> that repo. >>> >>> The repo is here: >>> https://chromium.googlesource.com/chromiumos/drm_hwcomposer >>> >>> Contributing instructions are here: >>> https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer >> >> Thanks for the pointer. This is essentially what I'm based on. >> >> Is there a testing target we need to use for submitting patches? Pixel >> C? The first problem is the use of the pre mainline atomic functions,
Dear Sean, I echo Rob's words. We planned to use kernel 4.4 and libdrm 2.4.66+ for marshmallow-x86. Do you have an updated drm_gralloc that can work with libdrm 2.4.66+? Or do you hope me to submit a patch for it? >> so using mainline kernel and libdrm are a problem. What is your plan >> to handle that? >> It also no longer works with the drm_gralloc in AOSP due to missing >> GRALLOC_MODULE_PERFORM_GET_USAGE support, so is there any plan to also >> host drm_gralloc? > > Just my own $0.02, but I would really like to move drm_gralloc into > mesa.. or at least the gallium pipe-driver part. > > Having gralloc essentially being a sort of state-tracker is great for > a lot of reasons.. ie. don't have to add new gralloc specific code for > new drivers like freedreno/vc4/etnaviv, and also by sharing a common > pipe_screen we can avoid some refcnt'ing / handle lifecycle issues. > > But that also means using API's which aren't really intended to be > exposed outside of mesa. Ie. gallium is not intended to be consumed > as a stable API from external state trackers. > > I know that chromium had started adding support for some other > non-mesa drivers. I'm not sure how best to handle that. Maybe what > makes most sense is to just copy/paste some code into mesa, and leave > external drm_gralloc just for blob drivers.. > > (I was kinda hoping Emil would someday tackle moving the code into > mesa, since whenever I mess with mesa build system I make a mess of > things :-P) > > BR, > -R > >> Anything you can share about planned changes/features you are working >> on so we can better coordinate work Linaro is doing here. >> >> Rob -- Chih-Wei Android-x86 project http://www.android-x86.org _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
