[PATCH xserver 0/3] Use DRM GetFB2 ioctl
Pekka Paalanen
ppaalanen at gmail.com
Thu Nov 21 08:20:21 UTC 2019
On Wed, 20 Nov 2019 19:54:15 +0200
Timo Aaltonen <tjaalton at ubuntu.com> wrote:
> On 23.3.2018 15.50, Daniel Stone wrote:
> > Hi,
> > This short patchset makes modesetting use the shiny, new, and completely
> > not at all merged GetFB2 DRM ioctl:
> > https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html
> >
> > When starting Xorg with -background none, it uses GetFB to interrogate
> > the current framebuffer, importing it into a Glamor texture so it can
> > copy back to its own storage. Unfortunately, if your buffer was
> > multi-planar (e.g. new Intel with auxiliary compression buffer), or just
> > too exotic to be described without a modifier (etnaviv in tiled mode),
> > GetFB fell short of what we actually needed.
> >
> > GetFB2 is the equivalent to AddFB2 (or AddFB2WithModifiers; both the
> > same from an ioctl point of view), so this ports modesetting to use that
> > where available and use with more complex buffers.
> >
> > The kernel ABI rules require positive review from real userspace (not
> > random hacked-up libdrm tests) before merging. Given that, I'd
> > appreciate someone taking a look at the use of GetFB2 here, and
> > following up with a statement that they think the ABI is actually good
> > and long-term usable for what Xorg needs. (Or, well, some kind of
> > constructive criticism.)
> >
> > Happy new-kernel-ABI Friday!
> >
> > Cheers,
> > Daniel
>
> Hi,
>
> Is there a second version of patches 2 & 3 somewhere? AIUI this would
> need to land in xserver before the kernel patches can be accepted?
Hi,
no, not land. The DRM rules are: get userspace accepted officially but
*not* merged. Then merge kernel bits. Once kernel bits are in a
non-rebasing tree, one can merge userspace bits.
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20191121/8d798243/attachment.sig>
More information about the xorg-devel
mailing list