Wayland on FreeBSD

[Jan Beich]

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? Does disabling render node help
e.g., chmod 0000 /dev/dri/renderD128 ?

  # Before
  $ procstat -f $(pgrep Xway glx) | awk 'FNR == 1 || /dev\/drm/'
    PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME
  46130 glxgears             4 v c rw------   1       0 -   /dev/drm/128
  46022 Xwayland             3 v c rw------   2       0 -   /dev/drm/128
  46022 Xwayland             5 v c rw------   2       0 -   /dev/drm/128
  46022 Xwayland            12 v c rw---n--  13       0 -   /dev/drm/0

  # After (still accelerated)
  $ procstat -f $(pgrep Xway glx) | awk 'FNR == 1 || /dev\/drm/'
    PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME
  46130 glxgears             4 v c rw------   1       0 -   /dev/drm/0

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

> 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

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.