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) <eu...@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:dan...@fooishbar.org] > > Sent: Mittwoch, 1. November 2017 15:14 > > To: Ucan, Emre (ADITG/ESB) > > Cc: wayland-devel@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) > > <eu...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
