[PATCH weston v12 00/40] Atomic modesetting

[Matt Hoosier]

What sort of testing on this series would be most helpful? I figure that
you and pq have most of the code review covered, so the main contribution I
can make with the hardware available to me is to exercise this on
consumer-grade systems like Macbooks with Intel display controllers. Are
there are specific use-cases that will put the most stress on your new
stuff? I assume that doing some sub-fullscreen OpenGL windows will kick in
the overlay selections to test that out.

On Thu, Nov 2, 2017 at 2:05 AM, Ucan, Emre (ADITG/ESB) <eucan at de.adit-jv.com
> wrote:

> Hi Daniel,
>
> Your proposal is exactly what I thought, how it should be.
> I am looking forward for next revision of patches.
>
> Best regards
>
> Emre Ucan
> Engineering Software Base (ADITG/ESB)
>
> Tel. +49 5121 49 6937
>
> > -----Original Message-----
> > From: Daniel Stone [mailto:daniel at fooishbar.org]
> > Sent: Mittwoch, 1. November 2017 15:14
> > To: Ucan, Emre (ADITG/ESB)
> > Cc: wayland-devel at lists.freedesktop.org
> > Subject: Re: [PATCH weston v12 00/40] Atomic modesetting
> >
> > Hi Emre.
> >
> > On 1 November 2017 at 11:56, Ucan, Emre (ADITG/ESB)
> > <eucan at de.adit-jv.com> wrote:
> > > Is this the latest WIP branch to test "
> > https://gitlab.collabora.com/daniels/weston/commits/wip/2017-10/atomic-
> > v13" ?
> >
> > Right you are.
> >
> > > In my opinion, it would easier to review/test your patches if you can
> > separate them in multiple patch series.
> > >
> > > For example, you can send at first up to "compositor-drm: Atomic
> > modesetting support". Commit message states that it enables atomic API
> > support for weston.
> > > Other features like GBM_BO_IMPORT_FD_MODIFIER support are nice to
> > have but not a hard requirement of atomic modesetting support.
> > >
> > > What do you think ?
> >
> > It's a reasonable idea, but in practice the two aren't completely
> > independent. The reason GBM_BO_IMPORT_FD_MODIFIER was tied up with
> > this is that it relies quite heavily on changes made to drm_fb which
> > have now been merged, but were previously part of the atomic series.
> > I've been considering pulling those out separately, but on the other
> > hand there are quite large conflicts doing so: before the 'helper'
> > commits, there are two separate GBM import paths for primary/scanout
> > and overlay planes, which only get unified inside the atomic series.
> >
> > My current thinking is:
> >   * everything up to 'atomic modesetting support' is qutie
> > self-contained, largely reviewed, and should hopefully be very very
> > close to landing by the time I can send out a new revision next week
> > (been busy with internal stuff & travel recently)
> >   * once that's landed, everything up to 'Add modifiers to GBM dmabuf
> > import', and possibly including 'Support plane IN_FORMATS' + 'Support
> > modifiers with GBM' can be considered as one independent series
> > (though will need a non-trivial rebase) which should be quite easy to
> > review
> >   * the rest of the code dealing with plane assignments (up to 'Enable
> > planes for atomic') can be considered another separate series; though
> > there are a couple of bugfixes in there, the rest is more complex and
> > difficult
> >
> > I think it makes the most sense to work through like that in order. Of
> > course if you have any other ideas or priorities, I'd be really
> > interested to hear - anything which makes it easier to review is
> > obviously good! :)
> >
> > Cheers,
> > Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171102/58a56b62/attachment.html>