Libdrm-nvdc 32.4.2 breaks atomic modesetting non-tegra clients

Hi,

We have a non-tegra drm/kms driver that we control through atomic modesetting calls from libdrm. Because the application accesses both this driver and the tegra-udrm one, the default L4T setup is appropriate – libdrm.so.2 is symlinked to libdrm-nvdc.so (nvidia’s tegra/libdrm.so.2), and the distro’s libdrm.so.2.4.0 is called by libdrm-nvdc.so when accessing a driver other than tegra-udrm or drm-nvdc. This worked perfectly fine in releases prior to 32.4.2.

As of 32.4.2, libdrm-nvdc.so breaks this ability. The libdrm-nvdc.so library itself will flag any call to drmModeAtomicAddProperty when object ids other than ones for tegra-udrm/drm-nvdc are used. This implementation is flawed for non-tegra drivers – it should let libdrm.so.2.4.0 decide whether those object ids are valid or not, if it’s using a different driver, because the object ids will be different. After it flags these property settings, the subsequent call to drmModeAtomicCommit is rejected by libdrm-nvdc.so and never gets forwarded to libdrm.so.2.4.0.

Please confirm that this change was made, and advise on a fix or workaround. Is there a way to tell libdrm-nvdc.so to not do this checking, or to ignore the checks so calls to drmModeAtomicCommit will be forwarded on to libdrm.so.2.4.0 as they used to be?

Thanks,

Kurt

Hi Kurt,

This sounds a problem… but I am wondering what kind of usecase could hit such error?

The libdrm-nvdc.so library itself will flag any call to drmModeAtomicAddProperty when object ids other than ones for tegra-udrm/drm-nvdc are used

Why there would be such ids that are not used for drm-nvdc? Could you elaborate more about this part?
It would be better if you could share the example.

Hi Wayne,

We have a non-tegra drm/kms driver (for custom hardware) that we control through atomic modesetting calls from libdrm.

Kurt

Ok, so such hardware does not rely on tegra hardware(nvdisplay) and it should use libdrm from distro but after rel-32.4.2, they are all using “drmModeAtomicAddProperty” in libdrm-nvdc, right?

Correct, the application uses the atomic modesetting for both the tegra hardware and the custom hardware. The application is unchanged, and after 32.4.2, it does not work for the custom hardware anymore (it does still work for the tegra hardware). If I replace /usr/lib/aarch64-linux-gnu/tegra/libdrm.so.2 with the copy from the previous release, it works correctly again.

Let me check with internal team and see if we can make an enhancement.

1 Like

Hi Kurt,

We want to know if there is any possible reasons that you must go through the path of drm-nvdc when non-tegra device is in use. I mean you could just use the API from distro’s drm if you don’t mix two kinds of drm usage in one application, right?

Hi Kurt,

Could you kindly share your application and some detail about your hardware? We would like to check this issue with our own non-tegra hardware.

Hi Wayne,

Our application needs to access both the tegra display and a display that is being run through an fpga for safety reasons. I have some other threads about this in the forums, if you would like to take a look at my previous posts.

The easiest way to reproduce the problem is by using the modetest program from drm (https://gitlab.freedesktop.org/mesa/drm/-/tree/master/tests/modetest)

For tegra hardware, it can run like this (and works):

./modetest -M tegra-udrm -P 4000@1000:3840x2160@AR24 -s 1000:"3840 x 2160" -a

For other hardware, the invocation depends on the plane and crtc ids, but on our custom hardware this fails due to this bug where plane and crtc ids are not 4000/1000:

./modetest -M vout -P 25@26:3840x2160@AR24 -s 28:3840x2160@AR24 -a

Hi Wayne,

Is there any update on this?

No, it will take longer time for this issue. I would say you could use the old libdrm as workaround at this moment.

Sorry for inconvenience.

Hi Kurt,

Sorry for late reply.
May I know what kind of device are you connecting to tegra? Also, are you using devkit?

Hi Wayne,

I am connecting an FPGA to the Tegra via PCIe, on a custom carrier board.

Thanks,

Kurt