drm/compositor: test complete state on format test #1708
Conversation
include all planes when testing a format, we only set the primary plane so test with all other planes disabled
|
Just tried this, doesn't seem to fix it :/ |
|
Can you please add both logs, debug log from the compositor and a drm debug log? I am not sure why it does not work, the format test should not differ from direct DrmCompositor usage. |
Hello, sorry for being this late. Here's the DRM debug log and compositor log gathered using this script #!/usr/bin/env bash
echo 0x19F | sudo tee /sys/module/drm/parameters/debug # enables verbose drm logging
sudo dmesg -C # clears kernel debug logs
sudo dmesg -w > ~/dmesg.log & # writes kernel logs in the background to a file at ~/dmesg.log
RUST_LOG=trace fht-compositor > ~/fht-comopsitor.log # write compositor log
fg # after this, use CTRL+C to stop writing the logs
echo 0 | sudo tee /sys/module/drm/parameters/debug # disables drm logging, don't forget this to avoid slowdowns |
|
From the dmesg log it looks like you request a mode that exceeds the supported bandwidth. You can see a lot of messages like: So the drivers tries to lower the bpc, but still fails to select a supported mode. My guess is that the pixel clock exceeds what is supported by your hardware. The driver seems to return an out of memory error for this case (not something in smithay): The log indicates that the highest supported mode is Logind seems to use a pixel clock of |
|
I suppose using a lower bpc value (IE. using 8-bit colors instead of 10-bit ones) would allow for plane creation, but this doesn't seem to change anything? At least from the DRM logs, the compositor is still requesting 10bpc even when using |
Afaict from the amdgpu driver source and the dmesg log it already tries to reduce bpc, starting from the max_bpc specified. But that does not address the pixel clock I mentioned, did you try with the timings I provided or with reduced blanking? |
Trying reduced blanking gave me a black screen. With the monitor saying there's no signal. Trying the modeline, the DRM logs do give that pixel clock, as seen in the logs But I still get a black screen, with the monitor saying there's no signal. If you can any additional cues from the log, here is it. |
|
@cmeissl So it seems, whatever I do, it always has too much bandwidth for the link, and if it finds a mode that fits, it seems that the compositor does not do anything? Maybe its then something from my side. |
The mode from logind, which I guess works?, should be something like this: |
|
What's confusing me the most is that this only happens when I try to start the compositor with that mode. If I start the compositor with the default mode ( |
That's strange, yeah. Hm, do you disable all connectors on startup prior to initializing the outputs? Can you also take a log of the working switch (smithay and drm)? |
I do not do that? At least I don't think I am. I do
|
You can disable all connectors when initializing the |
Yep, I am already doing it. |
include all planes when testing a format, we only set the primary plane so test with all other planes disabled