On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
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?
Yes please! Feel free to file them via gitlab.
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 assume yes, but I'm not hooked in to what's happening with minigbm.
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
Did you see the latest patches from Alistair Strachan to add minigbm as a supported platform? That might do what you want.
Thanks for testing, it's much appreciated.
Sean
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