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 -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
