On 05/03/2026 16:23, Yicong Hui wrote:
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
I wasn't following closely the userspace angle of the discussion to be
sure, nor I know enough about what are all the userspaces which may want
to use it, but in general, if there is more than one potential
userspace, perhaps you could try to interest some of them into the
feature. Or add support for it yourself, submit to them and say this
improves this or that and I have the kernel feature waiting already.
One other thing, so that your effort is not lost should someone want to
work on it in the future, perhaps a patch for the TODO file which links
to your latest series on lore (once all review comments are addressed)
and noting that the kernel implementation exists but is waiting on
userspace? Not sure if we ever done something like that but maybe we
should to avoid work duplication in the future. And also to preserve
some credit if someone picks up the work 1-2-3 years down the road.
Regards,
Tvrtko
Regardless, thank you to Christian and all the maintainers for being
welcoming and all your work reviewing this patch series so far!
Thanks
Yicong
