[PATCH] drm: Add fake controlD* symlinks for backwards compat

Greg Kroah-Hartman gregkh at linuxfoundation.org
Fri Dec 9 14:21:34 UTC 2016


On Fri, Dec 09, 2016 at 02:56:56PM +0100, Daniel Vetter wrote:
> We thought that no userspace is using them, but oops libdrm is using
> them to figure out whether a driver supports modesetting. Check out
> drmCheckModesettingSupported but maybe don't because it's horrible and
> totally runs counter to where we want to go with libdrm device
> handling. The function looks in the device hierarchy for whether
> controlD* exist using the following format string:
> 
> /sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d
> 
> The "/drm" subdirectory is the glue directory from the sysfs class
> stuff, and the only way to get at it seems to through
> kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
> instance in sysfs). Git grep says we're not the only ones touching
> that, so I hope it's ok we dig into such internals - I couldn't find a
> proper interface for getting at the glue directory.
> 
> Quick git grep shows that at least -amdgpu, -ati are using this.
> -modesetting do not, and on -intel it's only about the 4th fallback
> path for device lookup, which is why this didn't blow up earlier.
> 
> Oh well, we need to keep it working, and the simplest way is to add a
> symlink at the right place in sysfs from controlD* to card*.
> 
> v2:
> - Fix error path handling by adding if (!minor) return checks (David)
> - Fix the controlD* numbers to match what's been there (David)
> - Add a comment what exactly userspace minimally needs.
> - Correct the analysis for -intel (Chris).
> 
> Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
> Cc: Dave Airlie <airlied at gmail.com>
> Reported-by: Alex Deucher <alexander.deucher at amd.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>
> Cc: David Herrmann <dh.herrmann at gmail.com>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>


Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>


More information about the dri-devel mailing list