Re: [Question] drm: Picking a compatible CRTC for a connector seems not to work as expected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again,

now I feel really silly. You can in fact use any CRTC with any
connector, just like the API suggests. I however got stuck in object
oriented (?) hell, where the CRTC was already being used with another
connector as stored in.. some object I don't know exactly but it was
probably something the CRTC_ID property of another connector. My modeset
request did not unset this property as it simply left the connector
alone, which obviously now won't work anymore. Annoyingly, the debug log
did not indicate this at all and the error was incredibly vague.

Issue is fixed now, was not a bug

On 2/2/25 2:09 AM, Pancake wrote:
Hello!

I'm working on getting a modeset to happen via atomic commit and I've got most of my code done already but there's one small thing I'm getting hung up on.
In order to display something I need to dedicate a CRTC to a connector, but not all CRTCs can be used for all connectors. As far as I have understood, each connector has a list of compatible encoders and every encoder has a bit set for all compatible CRTCs. Now I've used a variety of things to check which connector is compatible with what CRTC:
- I ran drm_info which showed that each connector supports a unique subset of encoders, but each encoder supports all 4 CRTCs.
- I wrote a small c program where I called drmModeConnectorGetPossibleCrtcs(), which resulted in the same outcome.
- And I used my main application written in rust, which I encountered this issue with in the first place.
I tested this both on an NVIDIA GPU with proprietary drivers as well as an integrated AMD GPU with, I believe, the amdgpu driver. Same outcome.
This leads me to believe I can freely choose any CRTC to attach to a connector (as long as I don't reuse them, obviously), however this isn't the case. Only when iterating through the connectors and CRTCs in the order that I initially received them in when getting the resource handles, does my modeset work. If not in this exact order the atomic commit fails with invalid parameter and logs into dmesg something along the lines of "CRTC/connector mismatch".
Am I encountering bugs in both the AMD and NVIDIA drivers here, or is there something I'm missing when it comes to choosing a compatible CRTC?
If this is some sort of quirk, what's the best way to work around it?

Easiest way to replicate this is to simply grab drm_info from emersion's gitlab, or write a small c program that fetches the resource handles and iterates over all connectors, calling drmModeConnectorGetPossibleCrtcs() and observing the lower 4 bits.

Thanks!
Emilia





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux