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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux