Add feature to search for KMS DRI card #16
Conversation
|
Thank you for this feature. |
|
Here is my uevent rules: |
Most modern SOCs have separate IP cores for GPU and Display Unit (KMS). To work properly mesa requires initialize gbm interface using KMS card. Mesa uses it to allocate buffers with SCANOUT flag and does not require fd or pathname explicitly specified for GPU. Mesa will search for GPU and load the proper driver. Also, there is no warranty that the KMS card will always have /dev/dri/card0 path and GPU - /dev/dri/card1. Order can depend on many factors. For example: on the rpi4 board, it was observed that enabling the WIFI kernel module swapping the card order. Therefore searching for the KMS card is the only efficient solution. The is_kms_dev function returns true when the libdrm function is returned resources and the target device has at least one CTRC, connector, and encoder. The open_first_kms_dev function returns opened file descriptor on success using the previous function to check for each device. It also returns zeroed value for the case of KMS absence, or the -EINVAL on glob function error. In the case of absence of the "hwc.drm.device" system property the first KMS device or the default path /dev/dri/renderD128 will be used to open. Signed-off-by: Matvii Zorin <[email protected]> Reviewed-by: Roman Stratiienko <[email protected]>
|
@rsglobal, I've updated the PR. As for now, I handle the case if one of the paths is opened with an access error the search will be continued. Also, I extended the log prints. Could you review this solution? |
Both drm_hwcomposer and gralloc can now detect KMS device. Functionality was enabled by the commits: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/108 robherring/gbm_gralloc#16 Signed-off-by: Roman Stratiienko <[email protected]>
Most modern SOCs have separate IP cores for GPU and Display Unit (KMS). To work properly mesa requires initialize gbm interface using KMS card. Mesa uses it to allocate buffers with SCANOUT flag and does not require fd or pathname explicitly specified for GPU. Mesa will search for GPU and load the proper driver. Also, there is no warranty that the KMS card will always have /dev/dri/card0 path and GPU - /dev/dri/card1. Order can depend on many factors. For example: on the rpi4 board, it was observed that enabling the WIFI kernel module swapping the card order. Therefore searching for the KMS card is the only efficient solution. The is_kms_dev function returns true when the libdrm function is returned resources and the target device has at least one CTRC, connector, and encoder. The open_first_kms_dev function returns opened file descriptor on success using the previous function to check for each device. It also returns zeroed value for the case of KMS absence, or the -EINVAL on glob function error. In the case of absence of the "hwc.drm.device" system property the first KMS device or the default path /dev/dri/renderD128 will be used to open. Signed-off-by: Matvii Zorin <[email protected]> Reviewed-by: Roman Stratiienko <[email protected]>
|
Works fine for me. Thanks. |
|
Could you merge this please? |
| if (fd < 0) { | ||
| ALOGE("failed to open %s with error %s", path, strerror(errno)); | ||
| return NULL; | ||
| } |
There was a problem hiding this comment.
Please add drmDropMaster(fd); after this if () {} before line 337
See https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/-/merge_requests/134 for the explanation
|
This apparently breaks AMD gpus |
| if (path[path_len - 1] == '*') { | ||
| fd = open_first_kms_dev(path); | ||
| } else { | ||
| fd = open(path, O_RDWR | O_CLOEXEC); | ||
| } |
There was a problem hiding this comment.
Seems a bit cheeky to assume that every glob must end in * otherwise it will be treated as a regular path. It shouldn't be too bad to call open_first_kms_dev unconditionally?
| break; | ||
|
|
||
| close(fd); | ||
| fd = 0; |
There was a problem hiding this comment.
Theoretically 0 is a valid fd (if it weren't usually used for stdin), this should probably be -1 (and the <= 0 above should be < 0).
| { | ||
| glob_t glob_buf; | ||
| memset(&glob_buf, 0, sizeof(glob_buf)); | ||
| int fd; |
There was a problem hiding this comment.
Will glob() return 0 (instead of an error-code) if it found zero matching paths? If so, this should be initialized as to not return garbage when the loop never runs.
|
This contribution was a part of GloDroid development activity. At this particular moment we almost switched to minigbm's gbm backend, where a little different logic is implemented. @matviizorin, Are there any plans to finish this? If not, consider closing it down so you don't mislead people. |
|
@rsglobal Thanks for the info - I assumed as much given the date and silence of this PR, but thought to comment this anyway in case anyone feels like reviewing/merging. |
Most modern SOCs have separate IP cores for GPU and Display Unit (KMS). To work properly mesa requires initialize gbm interface using KMS card. Mesa uses it to allocate buffers with SCANOUT flag and does not require fd or pathname explicitly specified for GPU. Mesa will search for GPU and load the proper driver.
Also, there is no warranty that the KMS card will always have /dev/dri/card0 path and GPU - /dev/dri/card1. Order can depend on many factors. For example: on the rpi4 board, it was observed that enabling the WIFI kernel module swapping the card order. Therefore searching for the KMS card is the only efficient solution.
The has_kms_dev function returns true when the libdrm function is returned resources and the target device has at least one CTRC, connector, and encoder. The open_first_kms_dev function returns opened file descriptor on success using the previous function to check for each device. It also returns zeroed value for the case of KMS absence, or the -EINVAL on glob function error.
In the case of absence of the "hwc.drm.device" system property the first KMS device or the default path /dev/dri/renderD128 will be used to open.
A similar solution has been created and merged for drm-hwcomposer (MR#108).