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 <airl...@gmail.com>
> Reported-by: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: David Herrmann <dh.herrm...@gmail.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>


Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to