-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
platform/DRMFormat: Don't require a FormatInfo
for each format.
#3463
Conversation
We're now using `DRMFormat` in a situation (linux-dmabuf) where: * We don't actually need to care about many the properties of the format, and * We're processing formats submitted by cilents. This means that the existing “throw an exception if we haven't got a `FormatInfo`” approach works badly; we will disconnect clients with a Wayland internal error if they submit buffers in a format we haven't explicitly listed, even though it *would* work if we just treated the format as an opaque identifier. So, don't do that anymore. Instead, store the fourcc code directly in `DRMFormat` alongside the `FormatInfo` if it exists. Fixes: #3462
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3463 +/- ##
==========================================
- Coverage 77.36% 76.97% -0.39%
==========================================
Files 1076 1081 +5
Lines 68911 69384 +473
==========================================
+ Hits 53310 53407 +97
- Misses 15601 15977 +376 ☔ View full report in Codecov by Sentry. |
I'm not sure if I like this; particularly because we now don't have any signal for “it would be useful to have information on this format, but we don't have it”. It might be better to separate |
This way things which treat `DRMFormat` as entirely opaque don't pay for the extra format information, and we can warn when the things that *do* care about the format details try to look up details we haven't included yet.
I have now Done This. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A minor thing about symbols, but this makes sense to me overall
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A single question that I might be wrong on, but looks good to me 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly sensible. But we can do better with reporting missing format info
/* TODO: This could fire quite frequently. | ||
* Ideally we would have a rate-limited (or once-per-format) logger, but for now, just | ||
* throw it in the debug stream. | ||
*/ | ||
mir::log_debug("Detailed info for format %s missing; please report so this can be added", name()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of TODOs being added. In linux_dmabuf.cpp
we say something similar, but in that context we don't log. I think we need a better approach to reporting this. BTW "rate-limiting" doesn't sound right either.
With this approach, I think "debug" logging requesting reporting is addressing the wrong audience. "debug" and "trace" are for those familiar with the code. "Warning" might be better.
* throw it in the debug stream. | ||
*/ | ||
mir::log_debug("Detailed info for format %s missing; please report so this can be added", name()); | ||
return {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
std::nullopt
?
There we go! I have JFDI and resolved the TODOs rather than adding them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nitpicking. Feel free to land anyway
if (!unknown_formats->contains(fourcc)) | ||
{ | ||
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name()); | ||
unknown_formats->insert(fourcc); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is a micro optimisation but...
if (!unknown_formats->contains(fourcc)) | |
{ | |
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name()); | |
unknown_formats->insert(fourcc); | |
if (unknown_formats->insert(fourcc).second) | |
{ | |
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name()); |
Also, maybe some guidance on where to report?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've put a link to GitHub issues in the message text. I haven't taken the micro-optimisation, because I think it makes the intent slightly less obvious and it is the micro-est of micro-optimisations.
…orting missing formats
We're now using
DRMFormat
in a situation (linux-dmabuf) where:This means that the existing “throw an exception if we haven't got a
FormatInfo
” approach works badly; we will disconnect clients with a Wayland internal error if they submit buffers in a format we haven't explicitly listed, even though it would work if we just treated the format as an opaque identifier.So, don't do that anymore. Instead, store the fourcc code directly in
DRMFormat
, only look up theFormatInfo
(nowDRMFormat::Info
) when code asks for it.Additionally, we log the first time code asks for the
DRMFormat::Info
for a format we haven't got info for; this way we can fill out the needed formats on an as-noticed basis.Fixes: #3462