On 2/25/26 1:57 PM, Christian König wrote:
On 2/25/26 14:37, Michel Dänzer wrote:
On 2/25/26 14:25, Christian König wrote:
On 2/25/26 13:46, Yicong Hui wrote:
This patch series adds 2 new flags, DRM_SYNCOBJ_QUERY_FLAGS_ERROR and
DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR for 3 ioctl operations
DRM_IOCTL_SYNCOBJ_QUERY, DRM_IOCTL_SYNCOBJ_WAIT and
DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT to allow them to batch-request error
codes from multiple syncobjs and abort early upon error of any of them.
Patch #1 looks good enough to add my rb.
Patch #2 looks good as well, but I'm not familiar enough with the code and have
no time to wrap my head around it to give a review.
Adding a few people on CC, maybe somebody has time to take another look.
Based on discussions from Michel Dänzer and Christian König, and a
starter task from the DRM todo documentation.
See https://gitlab.gnome.org/GNOME/mutter/-/issues/4624 for discussions
on userspace implementation.
I have looked into adding sub test cases into syncobj_wait.c and
syncobj_timeline.c, igt-tests for this and I think I understand the
process for writing tests and submitting them, however, these ioctls
only trigger in the case that there is an error, but I am not sure what
is the best way to artifically trigger an error from userspace in order
to test that these ioctl flags work. What's the recommended way to
approach this?
When Michel agrees that this is the way to go then we either need an in-kernel
selftest (see directory drivers/gpu/drm/tests/) or an userspace IGT test.
Not sure what is more appropriate, maybe somebody on CC has more experience
with that.
I'd advise against landing this in the kernel before there's a corresponding
display server implementation making use of it, in a mergeable state.
Yeah we clearly have the rule that this can't be pushed into the kernel without
userspace code as well.
Otherwise you might end up with the kernel having to support UAPI which no
real-world user space actually uses. Been there, done that myself.
I don't have the capacity to contribute anything more than advice at this point.
Oh that is sad. Do you know anybody who could work on that?
It is a clear improvement to error handling and I don't like to keep Yicong's
work only on the mailing list.
Thanks,
Christian.
Hello
Is there anything else I can do? Or will we have to just leave all of this here
unmerged
I have read the emails from Tvrtko and Matthew and I'm absolutely happy to send
a v4 to ameliorate these issues, but there might not be a need to do so if the
series won't get merged in the end
Regardless, thank you to Christian and all the maintainers for being welcoming
and all your work reviewing this patch series so far!
Thanks
Yicong
