<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 10:00 AM, Sean Paul <span dir="ltr"><<a href="mailto:seanpaul@chromium.org" target="_blank" class="cremed">seanpaul@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jan 20, 2016 at 8:49 PM, Chih-Wei Huang <span dir="ltr"><<a href="mailto:cwhuang@android-x86.org" target="_blank" class="cremed">cwhuang@android-x86.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">CC to the android-x86 devel list so more developers can follow.<br>
<div><div><br>
2016-01-21 6:19 GMT+08:00 Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank" class="cremed">robdclark@gmail.com</a>>:<br>
> On Wed, Jan 20, 2016 at 4:59 PM, Rob Herring <<a href="mailto:robh@kernel.org" target="_blank" class="cremed">robh@kernel.org</a>> wrote:<br>
>> Hi Sean,<br>
>><br>
>> On Thu, Jan 14, 2016 at 1:15 PM, Sean Paul <<a href="mailto:seanpaul@chromium.org" target="_blank" class="cremed">seanpaul@chromium.org</a>> wrote:<br>
>>><br>
>>><br>
>>> On Thu, Jan 14, 2016 at 9:47 AM, Chih-Wei Huang <<a href="mailto:cwhuang@android-x86.org" target="_blank" class="cremed">cwhuang@android-x86.org</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hello Sean,<br>
>>>> My last try of drm_hwcomposer failed due to<br>
>>>> my limited time and knowledge.<br>
>>>><br>
>>>> Fortunately more developers join us<br>
>>>> to work on this topic now, including<br>
>>>> Rob Herring (kernel drm developer),<br>
>>>> Rob Clark and Emil Velikov (Mesa developers)<br>
>>>> We are working on drm_hwcomposer<br>
>>>> for virtio-gpu, the emulated GPU for QEMU.<br>
>>>><br>
>>>> If you don't mind, I would invite you to join<br>
>>>> our devel group for the discussion.<br>
>>><br>
>>><br>
>>> [adding Emil, Rob, and Rob]<br>
>>><br>
>>> Hi,<br>
>>> Ok, I've signed up for the android-x86 list. I don't anticipate seeing all<br>
>>> posts, so please cc me on threads needing feedback.<br>
>>><br>
>>> We also just today open-sourced drm_hwcomposer on the chromium gerrit<br>
>>> instance, such that we'll be doing all of our development in the open on<br>
>>> that repo.<br>
>>><br>
>>> The repo is here:<br>
>>> <a href="https://chromium.googlesource.com/chromiumos/drm_hwcomposer" rel="noreferrer" target="_blank" class="cremed">https://chromium.googlesource.com/chromiumos/drm_hwcomposer</a><br>
>>><br>
>>> Contributing instructions are here:<br>
>>> <a href="https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer" rel="noreferrer" target="_blank" class="cremed">https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer</a><br>
>><br>
>> Thanks for the pointer. This is essentially what I'm based on.<br>
>><br>
>> Is there a testing target we need to use for submitting patches? Pixel<br>
>> C? The first problem is the use of the pre mainline atomic functions,<br>
<br>
</div></div>Dear Sean,<br>
I echo Rob's words.<br>
We planned to use kernel 4.4 and libdrm 2.4.66+<br>
for marshmallow-x86.<br>
Do you have an updated drm_gralloc that<br>
can work with libdrm 2.4.66+?<br></blockquote><div><br></div></div></div><div>No.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Or do you hope me to submit a patch for it?<br>
<div><div><br>
>> so using mainline kernel and libdrm are a problem. What is your plan<br>
>> to handle that?<br></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Once libdrm is updated, we can look at getting robh's patch in.</div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>I just updated Android's libdrm to 2.4.66, there's a mirror here: <a href="https://github.com/crseanpaul/libdrm/tree/merge-2.4.66">https://github.com/crseanpaul/libdrm/tree/merge-2.4.66</a></div><div><br></div><div>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.</div><div><br></div><div>robh, can you please upload your drm_hwcomposer to gerrit so we can get it merged?</div><div><br></div><div>Sean </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
>> It also no longer works with the drm_gralloc in AOSP due to missing<br>
>> GRALLOC_MODULE_PERFORM_GET_USAGE support, so is there any plan to also<br>
>> host drm_gralloc?<br>
><br></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>For the time being, I think adding a stub to drm_gralloc to implement this call might be the best solution.<br></div><span class=""><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
> Just my own $0.02, but I would really like to move drm_gralloc into<br>
> mesa.. or at least the gallium pipe-driver part.<br>
><br>
> Having gralloc essentially being a sort of state-tracker is great for<br>
> a lot of reasons.. ie. don't have to add new gralloc specific code for<br>
> new drivers like freedreno/vc4/etnaviv, and also by sharing a common<br>
> pipe_screen we can avoid some refcnt'ing / handle lifecycle issues.<br>
><br>
> But that also means using API's which aren't really intended to be<br>
> exposed outside of mesa.  Ie. gallium is not intended to be consumed<br>
> as a stable API from external state trackers.<br>
><br>
> I know that chromium had started adding support for some other<br>
> non-mesa drivers.  I'm not sure how best to handle that.  Maybe what<br>
> makes most sense is to just copy/paste some code into mesa, and leave<br>
> external drm_gralloc just for blob drivers..<br>
><br>
> (I was kinda hoping Emil would someday tackle moving the code into<br>
> mesa, since whenever I mess with mesa build system I make a mess of<br>
> things :-P)<br>
><br>
> BR,<br>
> -R<br>
><br>
>> Anything you can share about planned changes/features you are working<br>
>> on so we can better coordinate work Linaro is doing here.<br></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Aside from that, I know zachr (cc'd) is playing around with some cleanup stuff, I'm not sure whether he has anything concrete.</div><span class=""><font color="#888888"><div><br></div><div>Sean</div></font></span><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
>><br>
>> Rob<br>
<br>
<br>
<br>
</div></div><div><div>--<br>
Chih-Wei<br>
Android-x86 project<br>
<a href="http://www.android-x86.org" rel="noreferrer" target="_blank" class="cremed">http://www.android-x86.org</a><br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>