From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Rossi Subject: Re: [drm_hwc] PSA: drm_hwc submissions via gitlab Date: Fri, 04 May 2018 17:19:50 +0000 Message-ID: References: <20180503150409.GD73214@art_vandelay> <20180503191255.GG73214@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1281052062==" Return-path: Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3F0716E229 for ; Fri, 4 May 2018 17:20:02 +0000 (UTC) Received: by mail-oi0-x243.google.com with SMTP id e80-v6so19765060oig.11 for ; Fri, 04 May 2018 10:20:02 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Robert Foss Cc: Alexandru-Cosmin Gheorghe , Liviu Dudau , dri-devel , Stefan Schake , isimha@nvidia.com, =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Rhys Kidd , Puneet Kumar , ghartman@google.com, cwhuang@linux.org.tw, Kalyan Kondapally , Thierry Reding , danalbert@google.com, nartal@nvidia.com, Dmitry Shmidt , Adrian Salido , Tomasz Figa , amartin@nvidia.com, seasonl@nvidia.com, Zach Reizner , Matt Szczesiak , David Hanna , astrachan@google.com, Marissa Wall , davidu@nvidia.com List-Id: dri-devel@lists.freedesktop.org --===============1281052062== Content-Type: multipart/alternative; boundary="000000000000ad5927056b6487bf" --000000000000ad5927056b6487bf Content-Type: text/plain; charset="UTF-8" Hi all, I just wanted to share that I'm conducting "newbie" tests on oreo-x86 with drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle.h and the results are good on nouveau, provided that some changes in drmresources are applied to avoid throwing errors for non connected connectors, i965 completes bootanimation, but surfaceflinger is killed when trying to draw status bar and menu bar (annoying but true) amdgpu (bonaire which supports atomic drm) is affected by problems in setting the correct mode on display (only txt cursor is shown) and there are SIGSEGV MAPERR at libskia trying to draw pixels. There are also errors logged by drm_hwcomposer code, which I'm not much able to interpret/analyze correctly. I would like to open issues on drm_hwcomposer with the details and logs when I encounter them, may I use gitlab or bugzilla for these drm_hwcomposer specific issues? Thanks for instructions Another question is for Intel and Chromeos developers: are you planning to update your minigbm projects to the new common gralloc_handle.h handle structure in latest libdrm? I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm gralloc_handle.h handle and it would make sense for minigbm to evolve accordingly, and I'd like to try them in oreo-x86 as a like-for-like replacement option for gbm_gralloc Thank for any info Mauro Rossi Il 04 mag 2018 14:48, "Robert Foss" ha scritto: Heya, On 2018-05-04 12:51, Daniel Stone wrote: > Hi, > > On 3 May 2018 at 20:12, Sean Paul wrote: >> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote: >>> On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote: >>>> If you're still reading, I'll point out a couple other things: >>>> - There is a bug tracker on the gitlab instance, feel free to add >>>> bugs/features/etc to it. >>>> - I've added a TODO list to the wiki, but in typing this, realized it's probably >>>> better to file bugs for each item. So please ignore the TODO wiki entry. >>> >>> Any plans to wire up autobuilder or maybe even functional CI to the >>> gitlab instance? That's where stuff gets really cool (and I think a >>> lot of people will see the value of abandoning dri-devel much more, >>> beyond the better S/N ratio). >> >> Not as far as I know. A fun afternoon project might be to hook up clang-format >> verification as a merge request hook. Aside from that, I think proper (or even >> improper/simple) CI would require more effort than we have resources. > > That should be pretty easy as a .gitlab-ci.yml. I'm working on getting > support for qemu into the existing runner that we have, so it would be > entirely possible to run a drm-hwc on a 'real' kernel, if you have > something you can test under qemu. I'm currently working on getting something like this up and running for normal feature development on my local machine. That being said AOSP is a fast moving target. So we would have to pin the AOSP version and maybe bump it every year or so. I guess that goes for the kernel,mesa & libdrm as well. Rob. > > For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's > a whole other topic that we don't currently cover. > > Cheers, > Daniel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > --000000000000ad5927056b6487bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I ju= st wanted to share that I'm conducting "newbie" tests on oreo= -x86 with drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle= .h

and the results are g= ood on nouveau, provided that some changes in drmresources are applied to a= void throwing errors for non connected connectors,
<= br>
i965 completes bootanimation, but surfaceflinger= is killed when trying to draw status bar and menu bar (annoying but true)<= /div>

amdgpu (bonaire which su= pports atomic drm) is affected by problems in setting the correct mode on d= isplay (only txt cursor is shown) and there are SIGSEGV MAPERR at libskia t= rying to draw pixels.

Th= ere are also errors logged by drm_hwcomposer code, which I'm not much a= ble to interpret/analyze correctly.

I would like to open issues on drm_hwcomposer with the details = and logs when I encounter them, may I use gitlab or bugzilla for these drm_= hwcomposer specific issues?

Thanks for instructions

Another question is for Intel and Chromeos developers: are you planning= to update your minigbm projects to the new common gralloc_handle.h handle = structure in latest libdrm?

I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new= libdrm gralloc_handle.h handle
and it would make se= nse for minigbm to evolve accordingly,

and I'd like to try them in oreo-x86 as a like-for-like = replacement option for gbm_gralloc

Thank for any info

Mauro Rossi

Il 04 mag 2018 14:48, "Robert Foss" <robert.foss@collabora.com> ha scritt= o:
Heya,


On 2018-05-04 12:51, Daniel Stone wrote:
> Hi,
>
> On 3 May 2018 at 20:12, Sean Paul <seanpaul@chromium.org>= wrote:
>> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
>>> On Thu, May 3, 2018 at 5:04 PM, Sean Paul <seanpaul@chro= mium.org> wrote:
>>>> If you're still reading, I'll point out a couple o= ther things:
>>>> - There is a bug tracker on the gitlab instance, feel free= to add
>>>>=C2=A0 =C2=A0 bugs/features/etc to it.
>>>> - I've added a TODO list to the wiki, but in typing th= is, realized it's probably
>>>>=C2=A0 =C2=A0 better to file bugs for each item. So please = ignore the TODO wiki entry.
>>>
>>> Any plans to wire up autobuilder or maybe even functional CI t= o the
>>> gitlab instance? That's where stuff gets really cool (and = I think a
>>> lot of people will see the value of abandoning dri-devel much = more,
>>> beyond the better S/N ratio).
>>
>> Not as far as I know. A fun afternoon project might be to hook up = clang-format
>> verification as a merge request hook. Aside from that, I think pro= per (or even
>> improper/simple) CI would require more effort than we have resourc= es.
>
> That should be pretty easy as a .gitlab-ci.yml. I'm working on get= ting
> support for qemu into the existing runner that we have, so it would be=
> entirely possible to run a drm-hwc on a 'real' kernel, if you = have
> something you can test under qemu.

I'm currently working on getting something like this up and running for=
normal feature development on my local machine.

That being said AOSP is a fast moving target. So we would have to pin the AOSP version and maybe bump it every year or so. I guess that goes for
the kernel,mesa & libdrm as well.


Rob.


>
> For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that&#= 39;s
> a whole other topic that we don't currently cover.
>
> Cheers,
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.or= g/mailman/listinfo/dri-devel
>

--000000000000ad5927056b6487bf-- --===============1281052062== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1281052062==--