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?