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.
