[PATCH v10 00/61] Atomic modesetting rides again

[Daniel Stone]

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