Arch Linux - Configuration application failed #28
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
for-next-chirp
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
BuddiesOfBudgie/budgie-desktop-services#28
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
OS : Arch Linux
Budgie version : 10.10.1
wdisplays settings is not persistent. When I set the frequency to 144Hz, it is not applied at next session.
I found that this service was responsible for saving the configuration from wdisplays.
Here are the logs :
The config file :
I tried to delete it, it get created again correctly but the issue persists.
A strace around the failed event :
I remain available if you need further troubleshooting.
Thanks,
Thanks for the report. A couple things:
wayland-debug -r org.buddiesofbudgie.Services. If you built Budgie Desktop Services from scratch, it'd be:wayland-debug -r ./build/bin/org.buddiesofbudgie.Services -gFor 2, I would suggest making sure it's dead before trying to run it separately (spamming good ol' killall -9 should do the trick)
I appreciate you getting back to me with this. At least based on a quick look, there isn't anything indicative of why there is an error. zwlr_output_configuration_v1.failed can occur if the compositor rejects the changes or doesn't successfully apply it, but it isn't exactly the most communicative back to the client on why a failure happened.
I'm seeing the following in the logs:
We have only found one head, so only having one enable_head (to create a single zwlr_output_configuration_head_v1) is correct, and we aren't setting any properties twice (this would be a protocol error). We're setting for the configuration head:
This all seems legit to me, but it's possible wdisplays is picking up an actual mode whereas we might only be getting the existing mode (I've noticed this on some monitors where EDID isn't correctly reported, like my built-in display). At least that is the first thing my mind goes to.
It might be helpful to compare this against what wdisplays is sending when you click the Apply button. Could you please run that through wayland-debug as well?
Thanks a bunch.
Hi,
Here are the logs :
I can see that the file ~/.config/budgie-desktop/display-config-shim.toml has successfully been updated :
I tried to remove the file then let Budgie-Desktop-Services recreating it, it works :
But the values are set to 0 :
Relaunching Budgie Desktop Services result in a file load success :
And using apply button works after relogging :
After that, I tried to relaunch BDS with wayland-debug to see if the file is correctly loaded and it is (at this moment, wDisplays frequency is set to the same values) :
But after logout/login, it failed again :
I think the issue here is when logging in set a default frequency (here 50hz), the config file has a diff on that (144hz), then the error happen where I suppose it tries to apply back 144hz. A clean file seems to be ok or a file that already has the same values is also ok.