Hi, v10 has very few changes to the end result. Probably most notable is that viewporting now works correctly into planes, including scaling. Mostly though it's a bunch of refactoring to the earlier patches (pixel formats, fb refcounting) to make sure that we don't introduce leaks or asserts in intermediate patches.
Patch 1 is new, which I end up using in patch 39. I think it's a good patch to have regardless though. Patch 2 has seen some revision and fixes, and is independent of all the other patches. Patches 3-9 work on drm_fb, adding refcounting and explicit type/format information, so we can use it more pervasively (and retain it for longer). Patches 10-18 work on both the primary/renderer plane and sprite planes, bringing the function and layout of these far closer to the model we'll use for state. Patches 19-21 introduce support for universal planes, so we can back all planes (including primary and cursor) with a drm_plane. Patches 20-26 introduce the three (pending/output/plane) state objects, and begin using them throughout. Patches 27-32 are mostly concerned with making our state application look more atomic internally, regardless of the kernel API used. Patches 33-36 introduce atomic modesetting support, albeit without planes. This relies on new kernel/libdrm API[0], of which review would be greatly appreciated. (New user-visible kernel ABI needs an ack from userspace that it's a sane and usable ABI.) Patches 37-46 attack the mechanical plane-state construction, mostly concerned with attempting to extract helpers for common patterns. Patches 47-49 add support for multi-planar DRM framebuffers, and those with modifiers. Patches 50-54 work on the core assign_planes loop, in preparation for a a two-pass run through it. Patches 55-59 fully split assign_planes, running it through iteratively with atomic check-only commits, to use planes as much as possible. sprites_are_broken is flipped at this point. Patches 60-61 use new GBM (merged) and kernel (not merged / under revision) API for allocating our GBM buffers with modifiers, so we can use tiling & compression for composition output. The kernel API will likely be changed at this point to use blob properties rather than a new ioctl, but as the form of those properties will look extremely similar (read: identical), again review of the ABI would be very useful. Tested lightly on Intel Skylake and Renesas R-Car H3 systems. Cheers, Daniel [0]: https://lists.freedesktop.org/archives/dri-devel/2017-April/138074.html _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
