[drm_hwc] PSA: drm_hwc submissions via gitlab

[drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

Hey all,
Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
and didn't want to leave anyone out. The good news is that your email address
will forever be remembered in the annals of drm_hwcomposer!

Anyways, back to the point.

Now that we have our shiny freedesktop gitlab instance [1], we should really
start using it to its fullest extent. This means 2 things:

1- When you send patches, please consider using gitlab merge requests instead of
   git send-email. This is not mandatory, but dri-devel is so busy, I want to
   make sure things aren't lost. Further, there might be some who are not
   interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
2- If you're interested in being notified of merge requests (since dri-devel can
   not be cc'd), please consider clicking "Watch" on the project and choose your
   desired notification level.

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.

Thanks for reading,

Sean

[1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Daniel Vetter]

On Thu, May 3, 2018 at 5:04 PM, Sean Paul <seanpaul@chromium.org> wrote:
> Hey all,
> Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
> and didn't want to leave anyone out. The good news is that your email address
> will forever be remembered in the annals of drm_hwcomposer!
>
> Anyways, back to the point.
>
> Now that we have our shiny freedesktop gitlab instance [1], we should really
> start using it to its fullest extent. This means 2 things:
>
> 1- When you send patches, please consider using gitlab merge requests instead of
>    git send-email. This is not mandatory, but dri-devel is so busy, I want to
>    make sure things aren't lost. Further, there might be some who are not
>    interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
> 2- If you're interested in being notified of merge requests (since dri-devel can
>    not be cc'd), please consider clicking "Watch" on the project and choose your
>    desired notification level.
>
> 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).

Cheers, Daniel
>
> Thanks for reading,
>
> Sean
>
> [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

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:
> > Hey all,
> > Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
> > and didn't want to leave anyone out. The good news is that your email address
> > will forever be remembered in the annals of drm_hwcomposer!
> >
> > Anyways, back to the point.
> >
> > Now that we have our shiny freedesktop gitlab instance [1], we should really
> > start using it to its fullest extent. This means 2 things:
> >
> > 1- When you send patches, please consider using gitlab merge requests instead of
> >    git send-email. This is not mandatory, but dri-devel is so busy, I want to
> >    make sure things aren't lost. Further, there might be some who are not
> >    interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
> > 2- If you're interested in being notified of merge requests (since dri-devel can
> >    not be cc'd), please consider clicking "Watch" on the project and choose your
> >    desired notification level.
> >
> > 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.

Sean


> 
> Cheers, Daniel
> >
> > Thanks for reading,
> >
> > Sean
> >
> > [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

On Thu, May 03, 2018 at 03:12:55PM -0400, 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 <seanpaul@chromium.org> wrote:
> > > Hey all,
> > > Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
> > > and didn't want to leave anyone out. The good news is that your email address
> > > will forever be remembered in the annals of drm_hwcomposer!
> > >
> > > Anyways, back to the point.
> > >
> > > Now that we have our shiny freedesktop gitlab instance [1], we should really
> > > start using it to its fullest extent. This means 2 things:
> > >
> > > 1- When you send patches, please consider using gitlab merge requests instead of
> > >    git send-email. This is not mandatory, but dri-devel is so busy, I want to
> > >    make sure things aren't lost. Further, there might be some who are not
> > >    interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
> > > 2- If you're interested in being notified of merge requests (since dri-devel can
> > >    not be cc'd), please consider clicking "Watch" on the project and choose your
> > >    desired notification level.
> > >
> > > 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.
> 

A couple additional thoughts,

We have seen a good uptick in drm_hwc activity in the last month or so, so maybe
there is someone with time to do this. 

The other (imo significant) benefit gitlab has in addition to S/N is that it's
not an email-based workflow. I'm particularly looking forward to reviewing patches
side-by-side instead of in a mutt window :-).

Sean


> Sean
> 
> 
> > 
> > Cheers, Daniel
> > >
> > > Thanks for reading,
> > >
> > > Sean
> > >
> > > [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer
> > >
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Robert Foss]

Hey Sean,

On 2018-05-03 17:04, Sean Paul wrote:
> Hey all,
> Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
> and didn't want to leave anyone out. The good news is that your email address
> will forever be remembered in the annals of drm_hwcomposer!
> 
> Anyways, back to the point.
> 
> Now that we have our shiny freedesktop gitlab instance [1], we should really
> start using it to its fullest extent. This means 2 things:
> 
> 1- When you send patches, please consider using gitlab merge requests instead of
>     git send-email. This is not mandatory, but dri-devel is so busy, I want to
>     make sure things aren't lost. Further, there might be some who are not
>     interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
> 2- If you're interested in being notified of merge requests (since dri-devel can
>     not be cc'd), please consider clicking "Watch" on the project and choose your
>     desired notification level.

About the above two points, maybe we could set up a dummy account that watches 
the gitlab project and sends notifications to the dri-devel list?

> 
> 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.

I can confirm that the TODOs are now very neatly organized issues.
Thanks for setting this up and sending out this ping.


Rob.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Daniel Stone]

Hey all,

On 4 May 2018 at 09:43, Robert Foss <robert.foss@collabora.com> wrote:
> On 2018-05-03 17:04, Sean Paul wrote:
>> Apologies for the direct ping. I've harvested your emails from drm_hwc git
>> logs,
>> and didn't want to leave anyone out. The good news is that your email
>> address
>> will forever be remembered in the annals of drm_hwcomposer!
>>
>> Anyways, back to the point.
>>
>> Now that we have our shiny freedesktop gitlab instance [1], we should
>> really
>> start using it to its fullest extent. This means 2 things:
>>
>> 1- When you send patches, please consider using gitlab merge requests
>> instead of
>>     git send-email. This is not mandatory, but dri-devel is so busy, I
>> want to
>>     make sure things aren't lost. Further, there might be some who are not
>>     interested in reading dri-devel *gasp*, but who are interested in
>> drm_hwc.
>> 2- If you're interested in being notified of merge requests (since
>> dri-devel can
>>     not be cc'd), please consider clicking "Watch" on the project and
>> choose your
>>     desired notification level.
>
> About the above two points, maybe we could set up a dummy account that
> watches the gitlab project and sends notifications to the dri-devel list?

Yeah, we could do that.

>> 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.
>
>
> I can confirm that the TODOs are now very neatly organized issues.
> Thanks for setting this up and sending out this ping.

I'm not a massive fan of the wikis, but you can use GItLab Pages to
generate sites from whatever content in a repo:
https://docs.gitlab.com/ee/user/project/pages/

Perhaps that would be a better way of dealing with it: have the
content in the repo as rst or whatever, some kind of static-site
generator, then you can have it available to view on
drm-hwcomposer.fd.o.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Daniel Stone]

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.

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

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Robert Foss]

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
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Mauro Rossi]

[-- Attachment #1.1: Type: text/plain, Size: 3443 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 5286 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

On Fri, May 04, 2018 at 10:43:22AM +0200, Robert Foss wrote:
> Hey Sean,
> 
> On 2018-05-03 17:04, Sean Paul wrote:
> > Hey all,
> > Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
> > and didn't want to leave anyone out. The good news is that your email address
> > will forever be remembered in the annals of drm_hwcomposer!
> > 
> > Anyways, back to the point.
> > 
> > Now that we have our shiny freedesktop gitlab instance [1], we should really
> > start using it to its fullest extent. This means 2 things:
> > 
> > 1- When you send patches, please consider using gitlab merge requests instead of
> >     git send-email. This is not mandatory, but dri-devel is so busy, I want to
> >     make sure things aren't lost. Further, there might be some who are not
> >     interested in reading dri-devel *gasp*, but who are interested in drm_hwc.
> > 2- If you're interested in being notified of merge requests (since dri-devel can
> >     not be cc'd), please consider clicking "Watch" on the project and choose your
> >     desired notification level.
> 
> About the above two points, maybe we could set up a dummy account that
> watches the gitlab project and sends notifications to the dri-devel list?

Ah, yeah, I didn't think about that. That could definitely work! I do wonder how
many people care about drm_hwc on dri-devel, but we could spin up the dummy
account and see who complains.

> 
> > 
> > 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.
> 
> I can confirm that the TODOs are now very neatly organized issues.
> Thanks for setting this up and sending out this ping.

fd.o was nice enough to let us dogfood gitlab first, so the least we could do is
start using it properly :-)

Shout out to Stefan Schake who's merge request was the first one merged
via the new flow. Honorable mention goes to Alex Gheorghe who submitted the
first merge request, which unfortunately has been held up by my nitty ways :-(

Sean


> 
> 
> Rob.

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

On Fri, May 04, 2018 at 11:48:10AM +0100, Daniel Stone wrote:
> Hey all,
> 
> On 4 May 2018 at 09:43, Robert Foss <robert.foss@collabora.com> wrote:
> > On 2018-05-03 17:04, Sean Paul wrote:
> >> Apologies for the direct ping. I've harvested your emails from drm_hwc git
> >> logs,
> >> and didn't want to leave anyone out. The good news is that your email
> >> address
> >> will forever be remembered in the annals of drm_hwcomposer!
> >>
> >> Anyways, back to the point.
> >>
> >> Now that we have our shiny freedesktop gitlab instance [1], we should
> >> really
> >> start using it to its fullest extent. This means 2 things:
> >>
> >> 1- When you send patches, please consider using gitlab merge requests
> >> instead of
> >>     git send-email. This is not mandatory, but dri-devel is so busy, I
> >> want to
> >>     make sure things aren't lost. Further, there might be some who are not
> >>     interested in reading dri-devel *gasp*, but who are interested in
> >> drm_hwc.
> >> 2- If you're interested in being notified of merge requests (since
> >> dri-devel can
> >>     not be cc'd), please consider clicking "Watch" on the project and
> >> choose your
> >>     desired notification level.
> >
> > About the above two points, maybe we could set up a dummy account that
> > watches the gitlab project and sends notifications to the dri-devel list?
> 
> Yeah, we could do that.
> 
> >> 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.
> >
> >
> > I can confirm that the TODOs are now very neatly organized issues.
> > Thanks for setting this up and sending out this ping.
> 
> I'm not a massive fan of the wikis, but you can use GItLab Pages to
> generate sites from whatever content in a repo:
> https://docs.gitlab.com/ee/user/project/pages/
> 
> Perhaps that would be a better way of dealing with it: have the
> content in the repo as rst or whatever, some kind of static-site
> generator, then you can have it available to view on
> drm-hwcomposer.fd.o.

Ahhh, this is what I was looking for when I started using the wiki! I've been
suffering remourse from moving the CONTRIBUTING file to the wiki. I was hoping
it'd be more visible than the small "CONTRIBUTING" button, but it's really not.

I've filed https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/9
to track.

Sean

> 
> Cheers,
> Daniel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Sean Paul]

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
> >

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Alistair Strachan]

[-- Attachment #1.1: Type: text/plain, Size: 1078 bytes --]

On Fri, May 4, 2018 at 10:35 AM Sean Paul <seanpaul@chromium.org> wrote:

> On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:

[snip]

> > 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.
>

+1. We can take this to another thread. The main issue is that minigbm
assumes a 1:1 planes to handles paradigm, the new generic handle does not.

> 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.
>

If we move to the common handle, my changes can be dropped. That's the
goal, it's just not possible right now.

[-- Attachment #1.2: Type: text/html, Size: 1832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Mauro Rossi]

[-- Attachment #1.1: Type: text/plain, Size: 2352 bytes --]

Il 04 mag 2018 19:51, "Alistair Strachan" <astrachan@google.com> ha scritto:

On Fri, May 4, 2018 at 10:35 AM Sean Paul <seanpaul@chromium.org> wrote:

> On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:

[snip]

> > 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.
>

+1. We can take this to another thread. The main issue is that minigbm
assumes a 1:1 planes to handles paradigm, the new generic handle does not.


Thanks for the info

This allows testing an hwcomposer.minigbm (by just changing some makefile
rules and build as separate project) separately from hwcomposer.drm
In order to select hwcomposer.drm+gralloc.gbm vs
hwcomposer.minigbm+gralloc.minigbm I use init.sh and a boot cmdline
parameter.

When testing drm_hwcomposer+ (chromeos minigbm or intel minigbm) two week
ago I was getting SIGABRT no suitable EGL config.

I will repeat tests with cros/gralloc_drm_handle.h handle now supported via
platformminigbm on amdgpu (requires patch on minigbm), i965 and nouveau.

Mauro

Mauro


> 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, they will suffice for now,  however minigbm was now put in
diverging track from common libdrm gralloc handle.


If we move to the common handle, my changes can be dropped. That's the
goal, it's just not possible right now.


Were those the only specificity introduced in hwc?

Is there documentation on the differences in composition of planes among
driver platforms?

Why is amdgpu the only platform (among the ones supporting atomic) for
which drm mode setting is not working with hwc, is there some difference in
amdgpu drm implementation? [Just a hint, I'll open bug on gitlab]

I'll keep an eye on AOSP minigbm, cros minigbm and intel minigbm to see
if/when they'll be updated to use new gralloc handle.

Mauro

[-- Attachment #1.2: Type: text/html, Size: 5249 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

minigbm/cros_gralloc handle struct (Was: Re: [drm_hwc] PSA: drm_hwc submissions via gitlab)

[Tomasz Figa]

[-- Attachment #1.1: Type: text/plain, Size: 2067 bytes --]

[Really taking this to another thread. Leaving CC as is for the time being.]

On Sat, May 5, 2018 at 4:16 AM Mauro Rossi <issor.oruam@gmail.com> wrote:

>
> Il 04 mag 2018 19:51, "Alistair Strachan" <astrachan@google.com> ha
> scritto:
>
> On Fri, May 4, 2018 at 10:35 AM Sean Paul <seanpaul@chromium.org> wrote:
>
>> On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
>
> [snip]
>
>> > 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.
>>
>
> +1. We can take this to another thread. The main issue is that minigbm
> assumes a 1:1 planes to handles paradigm, the new generic handle does not.
>
>
> Thanks for the info
>

I'm personally skeptical about this, but adding Gurchetan, who is a better
person to comment on this. My biggest concern is that it might not be
possible to define a common handle that is really good for everyone. Also,
since the handle would effectively be a stable ABI between independent
components, changing it to accommodate for future features (or discovered
issues ) would be problematic.

Generally we designed our graphics stack in Chrome OS / ARC++ in a way that
does not rely on the handle struct at all, so that we are free to change
the struct in any way we want in the future, without any compatibility
concerns (such as plane layout isssue mentioned before).

For the needs of EGL and most of other consumers, we are doing well without
any API extensions (most of the time we get some more complete struct, such
as ANativeWindow(Buffer) and for ambiguous formats we adopted lock_ycbcr
method).

Our hwcomposer is the only exception for which we added some perform calls
to retrieve data such as HAL pixel format, width, height, stride and
backing store (unique ID within some private namespace of the gralloc
instance, having similar properties to GEM handle within one DRI FD).

Best regards,
Tomasz

[-- Attachment #1.2: Type: text/html, Size: 3582 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel