Wayland on FreeBSD

[Frederic Chardon]

Le mer. 22 avr. 2020 à 16:51, Jan Beich <jbeich at freebsd.org> a écrit :
>
> Frederic Chardon <chardon.frederic at gmail.com> writes:
>
> > Le lun. 20 avr. 2020 à 23:06, Jan Beich <jbeich at freebsd.org> a écrit :
> >
> >>
> >> Frederic Chardon <chardon.frederic at gmail.com> writes:
> >>
> >> >
> >> > The trace shows usage of llvmpipe after the failed ioctl on
> >> > /dev/dri/card0, so as I understand the lack of hardware acceleration
> >> > concerns only Xwayland, whereas wayland itself is accelerated ?
> >>
> >> Yep. Check which ioctls fail then try to reproduce outside of Mesa or
> >> hardcode the result. Overriding PCI ID via INTEL_DEVID_OVERRIDE is
> >> unlikely to help e.g.,
> >
> > All below failure occurs only in xwayland, X11 and wayland succeed.
> >
> > The first failure is with I915_PARAM_CHIPSET_ID. When I hardcode the
> > correct ID I get a failure with I915_PARAM_HAS_RELAXED_DATA. When I
> > force the result to be true (as with X11 and Wayland), the ioctl
> > DRM_I915_GEM_EXECBUFFER2_WR fails with errno EPERM.
>
> Thanks for investigating. Maybe either DRM_AUTH or DRM_RENDER_ALLOW fails.
> Does setuid bit on Xwayland binary help?
Yes, hardware acceleration works. eglinfo still complain about invalid
0xffffffff PCI ID though

> Does disabling render node help
> e.g., chmod 0000 /dev/dri/renderD128 ?
No

What helps however is to mount the different linux filesystems after
i915kms is loaded.
eg I added "late" keyword to fstab as below
devfs   /compat/linux/dev     devfs     rw,late 0 0
fdesc /compat/linux/dev/fd  fdescfs   rw,late,linrdlnk 0 0
linproc /compat/linux/proc    linprocfs rw,late 0 0
linsys  /compat/linux/sys     linsysfs  rw,late 0 0

without the late keyword, acceleration works if devfs alone is
mounted. any other fs (with or without devfs) makes Xwayland use
software rendering.
As with setuid Xwayland, eglinfo complains about invalid PCI ID.


>
> Can you check major number is the same for primary and render nodes?
> Also check if render node device type is correct in case something
> like https://github.com/intel/libva/pull/292 affects Mesa.
>
>   $ ls -lL /dev/dri
>   total 0
>   crw-rw----  1 root  video  0x25b Apr 22 13:04 card0
>   crw-rw----  1 root  video  0x2db Apr 22 13:04 renderD128
>
>   # Based on major() from /usr/include/sys/types.h
>   $ echo $(( (((0x25b >> 32) & 0xffffff00) | ((0x25b >> 8) & 0xff)) ))
>   2
>   $ echo $(( (((0x2db >> 32) & 0xffffff00) | ((0x2db >> 8) & 0xff)) ))
>   2
>
>   # Based on drmGetMinorBase() from graphics/libdrm
>   $ echo $(( 0x2db & 0x80 ))
>   128
In my case card0 has major 0 and renderD128 major 1
Bit 0x80 is sometimes set, sometimes not, but I couln't find a pattern
(it doesn't seem to affect whether hardware rendering is used or not)


> > Should I open an issue on drm-kms github? Or it is more likely a
> > problem on mesa side?
>
> In kms-drm but before that try pending updates just in case:
>
> https://github.com/FreeBSDDesktop/kms-drm/pull/217
> https://github.com/FreeBSDDesktop/kms-drm/pull/221 # maybe unstable
No impact, hardware acceleration is enabled or not solely based on the
mounting of linuxulator pseudofs.

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235570
> https://github.com/myfreeweb/freebsd-ports-dank/tree/lite/graphics/mesa-dev
> >
> >> https://lists.freebsd.org/pipermail/freebsd-x11/2019-January/022551.html
> >>
> >> If you still have no clue try playing with sysctls under compat.linuxkpi
> >> via /boot/loader.conf.
> >
> > Any hints which ones are worth a try? How did you solve your issue (as
> > it seems to be pretty similar).
>
> Disappeared on its own. In bug 241821 for some time I could reliably
> reproduce but not anymore. The issue seems to be vaguely related to the
> order hardware is initialized during boot. Unfortunately, bug 241821
> didn't document "ls -lL /dev/dri" output but on the mailing list
> /dev/dri/renderD128 didn't have 0x80 bit set.

Thanks Jan!