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@xxxxxxxxxxxxx> ha scritto:
Heya,I'm currently working on getting something like this up and running for
On 2018-05-04 12:51, Daniel Stone wrote:
> Hi,
>
> On 3 May 2018 at 20:12, Sean Paul <seanpaul@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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.
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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
