Regressed by base r354413, reverting which makes Xwayland work fine again. $ pkg install sway rxvt-unicode mesa-dri mesa-demos $ export LIBGL_DRI3_ENABLE=1 $ sway <Press Super+Return to open a terminal> $ glxinfo | fgrep -A11 Extended Extended renderer info (GLX_MESA_query_renderer): - Vendor: Intel Open Source Technology Center (0x8086) - Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) (0x1912) + Vendor: VMware, Inc. (0xffffffff) + Device: llvmpipe (LLVM 9.0, 256 bits) (0xffffffff) Version: 19.0.8 - Accelerated: yes - Video memory: 3072MB - Unified memory: yes + Accelerated: no + Video memory: 65536MB + Unified memory: no Preferred profile: core (0x1) - Max core profile version: 4.5 - Max compat profile version: 3.0 + Max core profile version: 3.3 + Max compat profile version: 3.1 Max GLES1 profile version: 1.1 - Max GLES[23] profile version: 3.2 + Max GLES[23] profile version: 3.0
Note, I do have linux(4) loaded but /dev/shm uppears outside of /compat/linux.
/dev/shm appearing in /dev is expected, that’s how devfs(5) works. Can you run stuff under ktrace and see which binary tries to access /dev/shm?
(In reply to Jan Beich from comment #0) Could you check a file permissions on /dev/shm directory?
Removing /dev/shm doesn't help Xwayland. $ devfs rule apply path shm hide (In reply to Edward Tomasz Napierala from comment #2) > Can you run stuff under ktrace and see which binary tries to access /dev/shm? $ kdump -r ... 1096 sway CALL open(0x7fffffffe260,0x120004<O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC>) 1096 sway NAMI "/dev/shm/" 1096 sway RET open 38/0x26 ... 1142 Xwayland CALL ioctl(0x5,0xc0106446,0x7fffffffd580) # DRM_IOCTL_I915_GETPARAM 1142 Xwayland RET ioctl -1 errno 13 Permission denied 1142 Xwayland CALL write(0x2,0x7fffffffcd80,0x34) 1142 Xwayland GIO fd 2 wrote 52 bytes "i965_dri.so does not support the 0xffffffff PCI ID. " 1142 Xwayland RET write 52/0x34 ... $ fgrep /dev/shm =sway $ ldd =sway | awk 'FNR > 1 { print $3 }' | xargs fgrep /dev/shm Binary file /usr/local/lib/libffi.so.6 matches (In reply to Vladimir Kondratyev from comment #3) > Could you check a file permissions on /dev/shm directory? Adjusting permissions doesn't help Xwayland. $ ls -dl /dev/shm dr-xr-xr-x 2 root wheel 512 Nov 9 16:51 /dev/shm $ touch /dev/shm/test touch: /dev/shm/test: Operation not supported $ chmod 1777 /dev/shm $ touch /dev/shm/test $ ls -l /dev/shm/test -rw-r--r-- 1 foo wheel 0 Nov 9 16:52 /dev/shm/test
(In reply to Jan Beich from comment #4) > $ chmod 1777 /dev/shm > $ touch /dev/shm/test > $ ls -l /dev/shm/test > -rw-r--r-- 1 foo wheel 0 Nov 9 16:52 /dev/shm/test Ignore these. I've tried mounting tmpfs(5) over /dev/shm.
Wait, so it’s broken even when /dev/shm doesn’t actually exist, due to being hidden with devfs ruleset? That’s... interesting. Do you know why sway’s mouse cursor doesn’t move, by any chance? Is there some how to on how to setup it in FreeBSD?
(In reply to Edward Tomasz Napierala from comment #6) > Do you know why sway’s mouse cursor doesn’t move, by any chance? Do you see POINTER_MOTION events when running "libinput debug-events" and moving mouse before starting Sway? If not check /dev/input/* permissions then restart moused(8) or set kern.evdev.rcpt_mask=12 to get non-multiplexed events.
I can't reproduce anymore. Not bisecting the fix due to lack of time, and no one confirmed, anyway.