-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
Don't set background to black if ~/.background-image not present #78346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This value isn't used since 71a8dbb
${pkgs.feh}/bin/feh --bg-${cfg.wallpaper.mode} ${optionalString cfg.wallpaper.combineScreens "--no-xinerama"} $HOME/.background-image | ||
else | ||
# Use a solid black background as fallback | ||
${pkgs.xorg.xsetroot}/bin/xsetroot -solid black |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should have a fallback code path, in other desktop environments I noticed it being a solid black wallpaper when it should be the texture used from the window manager. Feels extra.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah probably just removing that is a better solution. I'm mainly wondering then why it's there in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git blame
gave me the answer: #25101
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually wondering why I ran into that in the first place.
It happened with desktopManagers that didn't use services.xserver.desktopManager.session
to have the bgSupport
attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yeah, I think that PR was the wrong solution to that problem. And I can't reproduce the issue from that PR. Using the current version of the PR without the fallback branch and the following config:
{
services.xserver = {
enable = true;
displayManager.sddm.enable = true;
windowManager.i3.enable = true;
};
users.users.demo = {
initialPassword = "";
isNormalUser = true;
};
}
I get the following after logging in:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, maybe i3 started resetting the root window but I am pretty sure I encountered this issue in some DM/WM combination when testing #53843
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was LightDM & XMonad: #53843 (comment)
Previously if ~/.background-image wasn't present, the background would be set to black, which would override what the user could set in e.g. services.xserver.windowManager.i3.extraSessionCommands
1cbaf4d
to
78d8365
Compare
@infinisil unfortunately not, I switched to Sway and don't have my previous SDDM + i3 configuration anymore (I could create a new test setup of course, but since you've already tested it with SDDM + i3 it shouldn't add any value / give different results). I also assume that i3 started resetting the root window in the meantime, like @jtojnar mentioned, which sounds like a good idea in general. And I agree that defaulting to a black background was just another hack / incomplete solution. However, I'm also not sure if Anyway, I don't have any objections and this PR LGTM (it might still cause a few regressions that result in something similar to #25101, but a black background is also not always optimal). |
Cool, thanks. I think the most important thing here is that the default behavior is to do nothing. So if the user doesn't have a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
…S#78346) Don't set background to black if ~/.background-image not present
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
What is the correct way to set the background to black now? (Using i3 with SDDM, but it's my own i3 desktop environment definition.) EDIT: What happens now is that the background is the SDDM login view how it was left when I logged in... |
I suppose running this explicitly?
|
@jluttine do you still see the behaviour described in #25101 (SDDM login screen as background) or is there a different issue now? Regarding the fix: Yes, running |
@primeos yeah, that looks like the issue I had after this PR was merged. But indeed using |
Ok, thanks for the update :) Then this behaviour might be hardware/driver dependant :o Not sure what we should do in this case / how many users are affected. |
Getting the background color/image correctly configured has been a bit tricky due to the interactions of the display manager, compton, and NixOS. NixOS is doing the following. If ~/.background-image exists, it uses feh to set that as the background, otherwise, it uses xsetroot to set the root X window's background to black: xsetroot -solid black This happens _after_ displayManager.sessionCommands have been run, clobbering any color that was previously set. A fix for this has been merged upstream: NixOS/nixpkgs#78346 Also relevant is a newly introduced option: services.xserver.windowManager.i3.extraSessionCommands NixOS/nixpkgs#49492 (comment) In the meantime, my workaround has been to create an image with the color I want and copy it to ~/.background-image. While trying to figure out how to get conky to work in i3, I learned that compton doesn't play nice with xsetroot. I haven't dug into too much detail, but it behaves as if compton introduces another layer of background that hides the layer xsetroot touches. Instead, using hsetroot has the desired affect.
Motivation for this change
In #49492 @mkaito mentions their usecase of running
nitrogen --restore
to set the background image, which could be implemented with e.g.services.xserver.windowManager.i3.extraSessionCommands
, but only if the code for~/.background-image
wouldn't run after that, which sets a black background, which was done because of #25101.This PR gets rid of setting the background to black again, which I think was the wrong solution to that problem.
This can be tested with a
configuration.nix
likewhich when ran with
results in the background image being set:
which wasn't possible like this previously
Ping @mkaito @worldofpeace @jtojnar @hedning
Note: The first commit is just a cleanup