-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
config/output: support DRM_FORMAT_ARGB8888 #8344
Conversation
Some display output hardware [1] doesn't support any of the current formats, but works with ARGB8888. Fall back to it if available. [1] https://github.com/torvalds/linux/blob/196145c606d0f816fd3926483cb1ff87e09c2c0b/drivers/gpu/drm/xlnx/zynqmp_disp.c#L313 Signed-off-by: Steffen Dirkwinkel <[email protected]>
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.
Indeed, sounds good to me!
I would kind of have expected a display device that supports ARGB to also be able to disable blending and do XRGB as well, but oh well. Having "extra" render formats on the list just means that when the formats are supported but lighting up the monitor is not possible, we end up wasting a bit more time allocating buffers for bogus tests. Buffer-less commit tests would be fantastic... LGTM! |
@kennylevinsen @emersion I also got it working by setting the default here (maybe it could be set to a format the hardware actually supports?):
I didn't end up submitting that, because sway already iterates over format. |
We already use Lines 795 to 805 in f957c7e
The "problem" is that many GPUs support all the formats on the list, so if an output is failing to light up for some non-format reason (e.g., bandwidth or CRTC limit), we end up allocating and testing all those buffer types to no avail. This was already the case before this patch, with the 10-bit BGR test being quite bogus on most GPUs. IMO, not something we need to worry about yet. If this ends up being enough of an issue (e.g., if the list grows longer or people experience noticeable delays), maybe we could add a heuristic to only try alternate format variations if the primary isn't supported to reduce the number of tested formats (e.g., BGR only if RGB isn't supported, ARGB only if XRGB isn't supported). The "proper" fix is kernel support for doing a commit test for a buffer format without an actual buffer allocation, in which case we could just cycle through and test all supported formats without worry. |
Made a draft of the heuristic approach here for the heck of it: #8345 |
Some display output hardware [1] doesn't support any of the current formats, but works with ARGB8888. Fall back to it if available.
[1] https://github.com/torvalds/linux/blob/196145c606d0f816fd3926483cb1ff87e09c2c0b/drivers/gpu/drm/xlnx/zynqmp_disp.c#L313