Replies: 4 comments 6 replies
-
Hey! Thanks a lot for the detailed feedback.
Yeah, so I don't have NVIDIA on any of my machines currently, so I don't know if and how well niri works there. In theory, Smithay (through cosmic-comp) should be tested on NVIDIA, but I wouldn't be surprised if it required special workarounds somewhere. I can't test myself due to lack of access to NVIDIA hardware (also from what I know, the proprietary NVIDIA driver still has major issues with Wayland support). It's good to hear that it at least somewhat works on NVIDIA though, thanks for testing!
That one sounds kinda like a damage tracking issue. Or maybe a EGL issue. Might be worth asking in the Smithay matrix channel, maybe it's something that could be relatively easily fixed.
So, yeah, I definitely agree that an error indication is needed. The main reason it's not a thing yet is because it requires rendering text (a famously complex problem), and I still haven't chose how I want to go about it in niri.
That's an interesting idea, and it kind of matches what happens when you live-edit the config (if there are errors, a new config is simply not loaded, so you stick with the previous one, before the edit). Might be surprising at times though, before an error banner is implemented. Although, I'm not sure how common of a case this is. Since during the initial config creation the "last" config is the default anyway, but any later edits can be done live, without restarting the compositor, which already preserves the working config on errors?
Right. How would you deal with this on sway for instance? It also has a different default terminal and a US layout by default.
This is indeed missing currently, but should be simple to add.
Yeah, it's another one of the worst config UX things currently. It's printed by the The way to solve this would probably be an IPC type system so you can do similar things to
Different drivers compute the monitor timings slightly differently, which might be the reason it isn't working. Depends, though.
This is an interesting idea and should be rather straightforward to do. I think I'll be going for subcommands on the main binary rather than separate binaries, for convenience. |
Beta Was this translation helpful? Give feedback.
-
I already posted it on matrix, but for search indexing's sake i'll post it here too. My mostly-polished flake is available at https://github.com/sodiboo/niri-flake. It currently has a NixOS module and i plan to make a home-manager module as well, and maybe some other goodies |
Beta Was this translation helpful? Give feedback.
-
I think the NVIDIA issue has to do with GSP, I'm experiencing the same behavior you describe in Nouveau after loading the GSP firmware with a RTX 3080. |
Beta Was this translation helpful? Give feedback.
-
I guess all of this is now fixed; NVIDIA was also fixed for at least several users in 0.1.3. |
Beta Was this translation helpful? Give feedback.
-
This is not really a single issue, but moreso multiple, and not necessarily well-defined. I apologize in advance for the lack of structure.
I'll start this by saying that I'm on NixOS with an nvidia GPU. This is not a particularly easy combo, especially with Wayland, and given that this is a project in alpha, I by no means expect everything to work out of the box. I've created my own NixOS module to install niri, which I will publish once it's a bit more polished and I can be satisfied with a working setup.
One thing I would like to know is whether anyone else is using nvidia with niri? If so, did you run into any issues, and how have you resolved them, if at all?
Two major pain points I have before even getting to use niri properly, which basically prevent me from using it at all:
Exhibit A: I'm getting extremely low refresh rates. (NVIDIA)
I can open a terminal, and the prompt does not appear. Typing works just fine, I can even launch e.g. Firefox, and that causes the screen to refresh. Clicking can somewhat reliably force a refresh.
Notably, this is only for window buffers. The screen itself is responsive, the mouse is smooth, the windows can be moved freely and the borders update in real-time. But type in the terminal? it doesn't show up. scroll on a website? it might update, if you're lucky.
This is caused by proprietary NVIDIA drivers, and it works just fine on nouveau.
Exhibit B: The config is, in a UX-sense, quite fragile.
When it is malformed, niri does print an error.
It also launches a graphical session, which does not contain the error. This is fixable, and I suggest that if the default config is loaded, a banner or message of some kind should show on startup informing the user of this, and why it happened.
"The provided config file (does not exist / is malformed [error details]), and therefore the default config has been loaded" would be better. Best would be if at all possible to load the last-known-good config, and as such prevent everything from resetting.
It's problematic for me, because my monitors are "strange" and the default layout is completely wrong, with bad scaling. I also have a non-US keyboard layout, and as such typing becomes hard with the default config, and I also don't use alacritty so I have to resort to another tty to even fix the config.
I also don't get to see the config error if I launch it from a login manager. I have to figure out that the config didn't load, then go to a new tty, launch niri manually, close immediately, read the error, and there I can finally fix it.
For that matter of my monitors, there are two more pain points:
I can't seem to find a way to disable a monitor.
I have two monitors connected, but I only use one. I would ideally like to hotswap whether the second one is enabled or not at any time, but that's not what I'm even trying to do. Before even prioritizing getting that working, I'd like to make it work with one monitor disabled. I may be mistaken, but there does not seem to be a way to disable a monitor.
I can't figure out the correct mode for my monitor
Admittedly, I "should" know this already, and I do for one of my monitors, but not the other. The default config tells me that the debug output shows supported modes, but it is not obvious where to find this. It also hints at using wayland-info utility, which can show me my available displays but not their supported modes.
Somehow, this seems to also be NVIDIA related, because, while testing on nouveau when writing this, I found that my desired mode just works on nouveau? no changes needed? Needs more investigation.
In essence, what I want from this is an easier way to list out the supported display modes, rather than "guessing".
I don't expect fixes to all of these, especially the NVIDIA-related issues, but I do at least want to gather these thoughts and share them rather than keep them to myself. I would, however, like a way to disable an output in the config.
Additionally, on top of the config improvements, something that would be useful to me is some flag or separate binary to validate the config (not just syntax but the niri-specific structure). If this was provided, then I could probably hack away at getting nix to validate the config and rollback to the last valid config for me, before niri ever sees an invalid config, which would be quite useful. I am willing to implement this myself, if the desire for this is agreed upon.
Beta Was this translation helpful? Give feedback.
All reactions