linsysfs: add drm render node

[val_packett.cool]

Summary

Running glxgears (from linux-c7-*) against xwayland on amdgpu without disabling dri3 results in Mesa failing to look up device info, because it needs render node info:

stat("/sys/dev/char/226:128/device/drm", 0x7fffffffbfb0) = -1 ENOENT (No such file or directory)

This patch adds this directory.

While here, also s/dri_minor/drm_minor/, because the former seems like a typo, just compare the search results:
https://www.google.com/search?hl=en&q=%22DEVTYPE%3Ddri_minor%22
https://www.google.com/search?hl=en&q=%22DEVTYPE%3Ddrm_minor%22

Sponsored by: https://www.patreon.com/valpackett

[trasz]

sys/compat/linsysfs/linsysfs.c

565

I wonder if this hardcoded "226" could be replaced with a call to linux_driver_get_major_minor(), to make it more evident where it came from?

Otherwise looks good to me, although I have no way to test it (unless it can change things for Intel?)

[val_packett.cool]

sys/compat/linsysfs/linsysfs.c

565

Which GPU shouldn't really matter, I don't think..?

In https://github.com/FreeBSDDesktop/kms-drm/issues/248 you mentioned that you don't get the handle_to_fd error. Please post the strace of glxgears.

[trasz]

sys/compat/linsysfs/linsysfs.c

565

Here it is: https://gist.github.com/trasz/ed3ec17ea445d1d92f05aa87344f359e. It's run from a Linux chroot.

[trasz]

Ping?

[val_packett.cool]

In D26836#621661, @trasz wrote:

Ping?

Is there anything here that needs changing?

I don't really want to unhardcode the major number, it's simpler that way, it's already been there (MAJOR=226)

[trasz]

So, first of all: I have nothing against hardcoding the "226"; if the patch fixes things for you, please commit it.

The only (non) issue I might have is that I don't understand what it does. You've said it fixes the CentOS 7 glxgears from ports on Radeon; the same glxgears worked for me last time I've checked, and one difference is that I'm using integrated Intel graphics.

[val_packett.cool]

In D26836#636327, @trasz wrote:

The only (non) issue I might have is that I don't understand what it does. You've said it fixes the CentOS 7 glxgears from ports on Radeon; the same glxgears worked for me last time I've checked, and one difference is that I'm using integrated Intel graphics.

Are you testing with Xorg on hardware? I'm testing with xwayland. It seems like on xorg a fallback from the render node to the card node is possible, this is from your trace:

stat("/sys/dev/char/226:128/device/drm", 0x7fffffffa790) = -1 ENOENT (No such file or directory)
stat("/sys/dev/char/226:0/device/drm", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0

[trasz]

Ah, that explains the difference; yes, I'm testing it with plain Xorg. Thanks :-)

[trasz]

Ping?

[trasz]

I have no idea if this is still required, but if it is: please go ahead.

[val_packett.cool]

rebased patch, no functional changes. ping!

[dchagin]

sys/compat/linsysfs/linsysfs.c

378

what is 226? im not X expert.

[val_packett.cool]

sys/compat/linsysfs/linsysfs.c

378

it's DRM_MAJOR on Linux

[dchagin]

sys/compat/linsysfs/linsysfs.c

378

Thanks, I got it, I read drm-kmod code, need some time to investigate it ))

[dchagin]

sys/compat/linsysfs/linsysfs.c

378

ugh, in my setup (two GPU) this code is not worked, i915kms attached sysfs devices to the vgapci0 device which is nvidia gpu. I rewrote bus scan code, could you please test? https://people.freebsd.org/~dchagin/drm.patch

kernel need to be rebuild, as I dropped "drm" helper from vgapci code. 10x

[val_packett.cool]

sys/compat/linsysfs/linsysfs.c

378

I can't test right now.. Seems reasonable, probably makes sense to create a review here already

[dchagin]

sys/compat/linsysfs/linsysfs.c

378

https://reviews.freebsd.org/D38546
https://reviews.freebsd.org/D38545