On Fri, Dec 09, 2016 at 11:42:01AM +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 and UXA in -intel are using this. -modesetting and SNA in -intel do not, which is why this didn't blow up earlier.
Note that for -intel, it is in the common code. It's about the 4th fallback, if the Xserver doesn't pass along the right fd, path or pci and we are expected to probe from scratch.
Oh well, we need to keep it working, and the simplest way is to add a symlink at the right place in debugfs from controlD* to card*.
s/debugfs/sysfs/ -Chris