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.