On Thu, Jan 21, 2016 at 10:00 AM, Sean Paul <seanp...@chromium.org> wrote:
> > > On Wed, Jan 20, 2016 at 8:49 PM, Chih-Wei Huang <cwhu...@android-x86.org> > wrote: > >> 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+? >> > > No. > > > >> 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? >> > > I'll look at updating android's libdrm today. In the long term, we're > hoping to centralize libdrm between cros and android much like > drm_hwcomposer, but there are still some moving parts that have yet to be > sorted out. > > Once libdrm is updated, we can look at getting robh's patch in. > > I just updated Android's libdrm to 2.4.66, there's a mirror here: https://github.com/crseanpaul/libdrm/tree/merge-2.4.66 The old and new atomic apis are beside each other. Once we have drm_hwcomposer using the new atomic apis, I'll remove the old ones from libdrm. robh, can you please upload your drm_hwcomposer to gerrit so we can get it merged? Sean > > >> 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? >> > >> > > To be honest, I don't think we have any plans to use drm_gralloc, so I'm > not sure where it'll be hosted in the future. > > For the time being, I think adding a stub to drm_gralloc to implement this > call might be the best solution. > > > > 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. >> > > I've been kicking around multi-monitor support for a while, and have some > WIP patches. I can ping you when I post them to gerrit. > > Aside from that, I know zachr (cc'd) is playing around with some cleanup > stuff, I'm not sure whether he has anything concrete. > > Sean > > > >> >> >> 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
