Hi Dave,
On 12 April 2017 at 05:57, Dave Airlie wrote:
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> +};
I think this struct need a __u32 pad as well.
Thanks
Emil
__
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
or new f
re-adding dri-devel, somehow got lost.
On Tue, Apr 11, 2017 at 8:00 AM, Daniel Vetter wrote:
> On Tue, Apr 11, 2017 at 5:06 AM, Dave Airlie wrote:
>>> You can drop the DRM_UNLOCKED, it's the enforced standard for non-legacy
>>> drivers since:
>>>
>>> commit ea487835e8876abf7ad909636e308c801a2bcd
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
or new f
On Tue, Apr 04, 2017 at 02:27:28PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that have the same
> semantics as sync_file objects, but without requiring an fd
> to be consumed to support them.
>
> This patch just enables the DRM interface to creat
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
or new f
