hikari wayland compositor (fork of raichoo's hikari) (https://hikari.acmelabs.space)
#51Feature Request: add wlr-output-management-unstable-v1 protocol
I have wanted to use hikari for quite awhile but I have been unable to get wayland to use 144hz refresh rate as its default. The only way I found to make wayland use it is with something like wlr-randr which requires this protocol to be implemented.
edit: I understand this is a fork I just stumbled upon it today when repackaging hikari on NixOS for myself (it was removed due to being unmaintained), but I saw you were keeping it up to date with the latest version of wlroots on here. After updating my build file and finally getting it to build it with this fork I am getting errors when attempting to launch things, foot giving the no sub compositor error and wmenu the other one. Here is a log of my session (hikari 2> log) https://pastebin.com/5EsYvhnG. It seems the errors are coming from the programs but they work fine under labwc. Was anything else added that was required to build maybe that isn't just the update to wlroots that I didn't catch?
Not sure if this is maybe just a problem with my building of it or not, https://pastebin.com/4YweaeQ8 is my mkderivation if it helps at all. It is mostly the same mkderivation that 2.3.3 had. Except it is using wlroots 0.17.3 and I added xcbutilwm because I think wlroots/xwayland didnt provide xcb_ewmh.h that something needed. Maybe I need to use 0.17.0? Sorry this kinda turned into 2 issues instead of one 😅.
- description updated
- description updated
Thank you for keeping an eye on this repository. I am thinking of implementing wlr-output-management-unstable-v1 protocol, but there is a lot to do to fully support the protocol. To start with, what you need now is 1) resolve foot and wmenu-run aborting, and 2) use 144hz refresh rate, right?
For the foot aborting issue, please try this patch: https://hub.darcs.net/hiroo/hikari/patch/6661747014986f7b41ee9f723d1370325b345620
Thank you for getting back so quick, yeah that issue order makes the most sense, I assume the protocol will take a bit of work to implement. I just updated my build file with the latest patch and it allows foot to open. Still no wmenu, I know wmenu also wouldn't run on 2.3.3.
For wmenu-run to work, we need to implement xdg_activation_v1 protocol.
Ah I see, I can use something like bemenu or tofi instead as those work without it (gives me more control of customization anyways). wmenu was just a nice drop in for dmenu that was fairly close as a wayland implementation.
Among wlr-output-management-unstable-v1 protocol features, just implemented setting mode (not custom mode) and adaptive_sync. Other features are not supported. Please try and report if there are any regressions. The mode setting can be done via wlr-randr or hikari.conf. The latter is described in hikari(1) manpage.
Assuming there are no regressions, what do you want to be implemented next? xdg_activation_v1 protocol for wmenu-run, or wlr-output-management-unstable-v1 protocol 's other features like transform or scale? (scale support will take time.) If you have not any emergency issue, I am thinking of implementing wlr_input_method_v2 protocol and wlr_text_input_v3 before above features.
This is great! I tried using the mode setting in my config, but it didn't seem to affect anything. I tried it in the format that you added in the manpage with "DP-1" = { mode = "2560x1440@143.912003Hz"; } and also without the equal sign after "DP-1" as that seems to be the proper formatting for the rest of the config and it seemed to not work either way. I ended up just adding the wlr-randr command I was using for labwc into my hikari autostart and it seems to work great.
I see:
00:00:00.885 [INFO] [src/output.c:547] hikari: assigning configured mode (2560x1440@143.912Hz) to DP-1 00:00:00.909 [INFO] [backend/drm/drm.c:786] connector DP-1: Modesetting with 2560x1440 @ 143.912 Hz
pop up when I am starting with my autostart wlr-randr script though, but it seems to not appear when I am not using it.As for xdg_activation_v1 protocol I'd rather you just work on what you want for now as I was just going to use tofi anyways for now which works fine as is.
Right now the only problem I am having is still with foot (this problem was present before adding of output management). At least I believe it to be foot as it is happening when my foot server starts up or if I turn that off when I am just starting foot. It also only happens to occur like 50% of the time which is weird. https://pastebin.com/HHbs4qkX that is the end of the output of hikari with 2>1 when starting it and how it ends up failing. I think it is happening when I assign my cursor in my startup script, I have export XCURSOR_THEME=plan9 in there right before the startup command of the compositor I am using. When testing it happened way less, if at all if I remember, when not assigning a custom cursor.
Okay, one more thing to add. Trying to play a fullscreen game, wanted to try something out to see how hikari handles something that wants fullscreen, I tried CS2 out. It's a little weird but when in game I am only able to move my view around in a constrained square maybe like 50x50-100x100 and my cursor movements are inverted. When putting the game in windowed mode it seems maybe the game isn't being allowed to keep the cursor within the bounds of the window. I tried to use mode-enter-input-grab and it seems to behave the same, I tried that as it seemed like it may contain things but I guess not.
The mode line should be in output section. For example:
outputs { "*" { background = "/usr/local/share/backgrounds/hikari/hikari_wallpaper.png" } "VGA-1" { mode = "832x624" } }
I will take a look into the foot issue and the fullscreen problem first. Thank you.
Thanks again for doing all this work. This is how I currently have the outputs section setup. I am using wlr-randr to find output name and modes.
outputs { "*" { background = "$HOME/pix/bg.png" } "DP-1" { mode = "2560x1440@143.912003Hz" } }
I tried shortening my refresh rate to 143.912Hz as hikaris output seems to see that as an available mode but it still doesn't work setting it up this way. Here is that full output if it is any help. https://pastebin.com/n4v3EF9b- status set to closed
- status set to open
I accidentally closed this sorry about any extra notifications, I don't know how exactly to setup the code block and was trying to see if I could edit it.
Your foot executable does not seem to have this change https://codeberg.org/dnkl/foot/commit/e2aeb7f3361b87e61a8bc5f478bb2dab056b1ac4 yet. Please wait for your OS's packages to update or me implementing the server-side cursor.
I could not reproduce the game problem, but after the commit message, this patch https://hub.darcs.net/wozeparrot/hikari/patch/2958c48f173b31ad46cf0d378bcc37bb2b8fc840 might address the issue. I merged it, so please try the latest patch.
Which hikari.conf file are you editing? /usr/local/etc/hikari.conf? ${HOME}/.config/hikari/hikari.conf?
Sorry, /usr/local/etc/hikari/hikari.conf.
I have my config currently in $HOME/.config/hikari/. The /usr/local/ isn't a directory really used by NixOS. I added that foot patch to my install as there is no release it seems that has it currently. I also updated my mkderivation with the new patches and it seems to not have fixed the game issue. I see it's adding a protocol for pointer constraint, but it still seems to not be constraining my cursor to the center of the screen, maybe also should have added the problem is for first person games if I wasn't clear.
So far I have tested, Minecraft (I just spin in circles, putting the game in a window seems the cursor just doesn't get set to the middle and cursor moves about the screen normally), CS2 (i can move like I stated in the earlier post but it is inverted and movement stops when I hit the edge of my monitor), and Momentum a source mod for bhopping (same problem as CS2). Games like Factorio play just fine as it doesn't need to constrain my cursor.
> I have my config currently in $HOME/.config/hikari/.
That's OK. Then, the problem is that the mode setting in the configuration file is not used (it does not seem to appear in the log). For the game issue, I will revise the code but do not expect to be solved soon.
Sounds good. Thanks for all you've done so far! Hikari is feeling great.
Refactored some code regarding wlr-output-management-v1 protocol and wlr-output-power-management-v1 protocol.
- Supported wlr-randr options: --on, --off, --toggle, --mode, --custom-mode, --preferred, --adaptive-sync custom mode can only be specified with wlr-randr. There is no configuration file support.
- (Yet) Unsupported wlr-randr options: --pos, --transform, --scale
I will return to supporting remaining options after I finish wlr_text_input_v3 and wlr_input_method_v2 protocol support, and wlroots 0.18 adaptation.