Hi,
On 5 April 2016 at 15:04, Rob Clark wrote:
> On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
>> I've been assuming that it would have to be write-only; I don't
>> believe there would be any meaningful usecases for read. Do you have
>> any in mind, or is it just a symmetry/cleanliness
Hi,
On 5 April 2016 at 13:36, Rob Clark wrote:
> ok, so I've been slacking on writing up the reasons that I don't like
> the idea of using a property for fd's (including fence fd's).. I did
> at one point assume we'd use properties for fence fd's, but that idea
> falls apart pretty quickly when
On Tue, Apr 5, 2016 at 10:19 AM, Daniel Stone wrote:
>
>> hmm, I'm assuming that the in/out arrays are handled in
>> drm_mode_atomic_ioctl() and the drivers never see 'em..
>
> True, but it complicates the (already not hugely straightforward)
> parsing that the ioctl has to do. It also makes
On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
> Hi,
>
> On 5 April 2016 at 13:36, Rob Clark wrote:
>> ok, so I've been slacking on writing up the reasons that I don't like
>> the idea of using a property for fd's (including fence fd's).. I did
>> at one point assume we'd use properties for
On Wed, Mar 23, 2016 at 2:47 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> FENCE_FD can now be set by the user during an atomic IOCTL, it
> will be used by atomic_commit to wait until the sync_file is signalled,
> i.e., the framebuffer is ready for scanout.
ok, so I've been slacking on
Hi,
2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> FENCE_FD can now be set by the user during an atomic IOCTL, it
> will be used by atomic_commit to wait until the sync_file is signalled,
> i.e., the framebuffer is ready for scanout.
It seems that
From: Gustavo Padovan
FENCE_FD can now be set by the user during an atomic IOCTL, it
will be used by atomic_commit to wait until the sync_file is signalled,
i.e., the framebuffer is ready for scanout.
Signed-off-by: Gustavo Padovan
---