I dislike this idea.
The sysctl sys.class.drm.card0-DP-1 path matches Linux while sysctl sys.device.drmn1.card0.card0-DP-1 not

Here is an example on a computer running Linux 6.18:

# ls -l /sys/class/drm
total 0
lrwxrwxrwx 1 root root    0  9 mars   2026 card0 -> ../../devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0
lrwxrwxrwx 1 root root    0  9 mars   2026 card0-DP-3 -> ../../devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0/card0-DP-3
lrwxrwxrwx 1 root root    0  9 mars   2026 card0-DP-4 -> ../../devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0/card0-DP-4
lrwxrwxrwx 1 root root    0  9 mars   2026 card0-DP-5 -> ../../devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0/card0-DP-5
lrwxrwxrwx 1 root root    0  9 mars   2026 card0-HDMI-A-3 -> ../../devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0/card0-HDMI-A-3
...

So the correct path on Linux is /sys/devices/pci0000:00/0000:00:08.1/0000:17:00.0/drm/card0/card0-DP-3. The difference with my proposal is that they use the PCI address (pci0000:00/0000:00:08.1/0000:17:00.0/drm), and here, we have the device name (drmn0). The other difference is that they use plural for "devices" while we use the singular "device".

The file in /sys/class/drm/... is a symlink to /sys/devices/....

I don’t find the use of /sys/class/drm logical, as the connector should be a child of the device, not a class.

Let’s collect other opinions :-)

I have no opinion but a question: what uses this sysctl or is it purely for information?

I’m not sure anything uses it from the Ports tree as all applications and librairies will certainly be designed around sysfs.

I personnaly use it to determine which display is connected to the computer. This is useful to change my window manager configuration between the laptop’s display and my external monitor.

Heads up: this change causes a regression in the InfiniBand/RoCE stack on main. Filed as PR <298485>: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298485.
Because FreeBSD's sysfs emulation is sysctl-backed and has no symlinks, parenting the kobject under dev->parent does not add a view alongside the class view the way the Linux symlink does - it replaces it.
ibcore sets dev.parent on both its devices (ib_sysfs.c:1340, ib_uverbs_main.c:1061), so sys.class.infiniband_verbs.uverbsN.ibdev and sys.class.infiniband.mlx5_N.* disappeared,
moving to sys.device.mlx5_coreN.*. libibverbs enumerates exclusively via the class view, so ibv_devices and ibv_devinfo now report no devices at all on a fully working adapter, with no error output.
Confirmed by reverting just this hunk and rebuilding.
Also note device_register() in the same header still class-parents unconditionally, so the two registration paths now behave differently for identical input.
Suggestions for a fix that preserves your DRM intent are in the PR.