From: Christoph Liebender Subject: Re: NEW: wayland/niri: A scrollable-tiling Wayland compositor To: ports@openbsd.org Date: Tue, 20 Jan 2026 17:18:15 +0100 On 1/18/26 19:55, Tobias Heider wrote: > On Sun, Jan 18, 2026 at 04:14:50PM +0100, Christoph Liebender wrote: >> On 1/17/26 23:04, Tobias Heider wrote: >>> On Tue, Dec 30, 2025 at 07:33:05PM +0100, Landry Breuil wrote: >>>> Le Tue, Dec 30, 2025 at 03:21:56PM +0100, Tobias Heider a écrit : >>>>> On Tue, Mar 04, 2025 at 05:13:07PM +0100, Tobias Heider wrote: >>>>>> Hi, >>>>>> >>>>>> here is a new port for niri [1], a scrollable-tiling Wayland compositor >>>>>> heavily inspired by the PaperWM extension for Gnome. >>>>>> >>>>>> This one is a little different than our existing wayland compositor ports >>>>>> since it doesn't use wlroots but smithay [2] as its underlying compositor >>>>>> library. >>>>>> >>>>>> Smithay is written in rust and pulls in quite a few dependencies, I had to >>>>>> resort to some hacks to make it pick up the patched OpenBSD compatible >>>>>> versions since most patches haven't found their way into an upstream release >>>>>> yet. In the current version I fetch niri itself and all the patched >>>>>> dependencies from my forked trees on github. I already got some of them >>>>>> merged upstream so I'm optimistic that we can swtich over to an official >>>>>> release in the near future. >>>>>> >>>>>> Looking forward to get some feedback. >>>>>> >>>>>> Some open questions: >>>>>> Is there a better way to handle the rust dependencies? >>>>>> Would it make sense for a large rust package such as smithay to be a separate >>>>>> port? >>>>>> I used upstream_version.date for our port version, is there a better solution? >>>>>> >>>>>> [1] https://github.com/YaLTeR/niri >>>>>> [2] https://github.com/Smithay/smithay >>>>> >>>>> Updated it to 25.11 and thought I'd share it here for anyone interested. >>>>> >>>>> The garbled output after exiting niri seems to be fixed and I managed to >>>>> upstream a bunch of patches in dependencies. The port is still fetching from >>>>> my github though and is using drm-rs and smithay from my patched forks. >>>>> >>>>> One open issue is that xwayland-satellite will crash niri after a while, >>>>> I am still trying to figure out why. >>>> >>>> heh, and i thought it was already imported... >>>> >>>> LIB_DEPENDS = devel/llvm/21 >>>> >>>> and you have the MODCARGO lines pointing at libLLVM.so commented out.. >>>> are you sure that LIB_DEPENDS is needed ? if so im not sure that cant >>>> lead to other issues in ports. >>>> >>>> note that startniri.sh should be updated now that we have proper support >>>> for XDG_RUNTIME_DIR. >>>> >>>> with those fixed i'd be inclined to ok it so that you can maintain it in >>>> tree, and itd be good to have non-wlroots implems to play with :) >>>> >>>> Landry >>> >>> I removed the llvm references, fixed startniri.sh and added a bit about the >>> render-drm-device configuration in pkg/README. I was hoping I could fix it >>> but that turned out to be harder than expected so documenting the quirk >>> for now is probably the easier way to unblock this. >>> >>> ok? >> >> small nit in README: >> >>> Running >>> ======= >>> >>> On OpenBSD, use the provided ${PREFIX}/bin/startniri.sh script to >>> launch niri from an text VT (xenodm must be stopped. >> ^ ^ >> Also, FWIW, /usr/ports/infrastructure/bin/portcheck complains: >> >> 3 line(s) longer than 80 chars in Makefile >> executable file: files/startniri.sh >> hardcoded paths detected in pkg/README, consider using SUBST_VARS and >> TRUEPREFIX/LOCALBASE/LOCALSTATEDIR >> >> Apart from that, it appears that niri has stopped working for me - when I >> startniri.sh, there is some log output: > > Interesting. In previous versions I had SMITHAY_USE_LEGACY=1 set in > startniri.sh. Does adding that back fix it for you? > It doesn't seem to be necessary on my (amdgpu) desktop. > Unfortunately, that does not do the trick on my intel thinkpad.