[PATCH weston v12 00/40] Atomic modesetting

[Ucan, Emre (ADITG/ESB)]

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