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" <robert.foss@collabora.com> ha scritto:

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@chromium.org> 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
>