[Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2

[Thomas Hellstrom]

On 09/01/2015 03:49 PM, Emil Velikov wrote:
> Hi all,
>
> On 1 August 2015 at 20:40, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>> Hi!
>>
>> On 08/01/2015 07:16 PM, Emil Velikov wrote:
>>> On 22 July 2015 at 00:00, Rob Clark <robdclark at gmail.com> wrote:
>>>> From: Rob Clark <robclark at freedesktop.org>
>>>>
>>>> Like xa_surface_from_handle(), but takes a handle type, rather than
>>>> hard-coding 'shared' handle.  This is needed to fix bugs seen with
>>>> xf86-video-freedreno with xrandr rotation, for example.  The root issue
>>>> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
>>>> associated with the drm_file will result in two unique handles for the
>>>> same bo.  Which causes all sorts of follow-on fail.
>>>>
>>>> Cc: "10.5 10.6" <mesa-stable at lists.freedesktop.org>
>>>> Signed-off-by: Rob Clark <robclark at freedesktop.org>
>>>> ---
>>>> Note: it would be good to get this in stable too, since I have a patch
>>>> for xf86-video-freedreno which will depend on this.
>>>>
>>> Bth, I'm not too excited about having new APIs in the stable branch,
>>> despite them being trivial as this one.
>>> Regardless it would be nice to get a pair of eyes looking in this direction.
>>>
>>> The patch does exactly what it says on the tin, although I do wonder
>>> if we should bump XA_TRACKER_VERSION_MINOR ?
>> I haven't had time yet to look at the patch itself (I'm on vacation and
>> back next week), but having XA recognize handle types, in particular
>> dma-buf fds is, IMO a good thing.
>>
>> Regarding adding new interfaces to XA, the XA documentation is pretty
>> explicit about how this should be handled and recognized, with version
>> numbers. As long as all XA users follow this, it should be pretty
>> straightforward also in a stable mesa branch. IIRC, the XA minor must be
>> bumped in this case, and an out-of-mesa-tree user can't rely on the
>> symbol being present, since an old libxatracker with the same major
>> number might be present, but needs to use dlsym() or something similar.
>>
> Rob, Thomas do you plan on picking this up and addressing the final bits ?
>
> -Emil
Hi!

we'll need this for dri3 support in vmwgfx but for us there's no need to
take it through stable.
Rob, are you going for glamor or do you need this for stable?

Thanks,
Thomas