Workaround unreliable GDK geometry scaling for matching monitors #768
Conversation
|
Did not work on my end. I think I installed it correctly on Arch. I edited the source to point to your repo and branch and then installed it as a system package. This is the PKGBUILD. Arch Linux PKGBUILDI also double checked the Again, my configs for reference. Hyprpanel monitor configs Monitor Readings GTK Inspector |
|
@uwidev I think your issue is coming from your transform=1 setting in hyprland. You might have to bear with me here (incoming infodump). I think whats happening is that the xdg_output received by GDK/GTK IS correctly fractionally scaled (even in GDK3). However this means that xdg_output is the same as wl_output, GDK receives the intended scale and rounds it up to an integer. Well if that integer scale factor is 2, GDK sees that xdg_output hasn’t been scaled because it equals wl_output so it “corrects” the GDK geometry by scaling it by the scale factor.. 2. This is what @Sawy7 ‘s PR was to fix. However what happens when you have a 90 degree rotation? Well that swaps the height and width, so now xdg_output is not equal to wl_output and GDK seeing this knows NOT to scale it with the scaleFactor. So the geometry will be the correct fractionally scaled inverted height width. I think.. haha 😁Tomorrow morning Ill doing some testing and hopefully we’ll have a true fix |
|
This behavior is driving me nuts. I thought maybe it was a transform thing but I couldn't reproduce it on my end. I have a Mac eDP monitor with resolution 3456x2160 here's my testing for GDK3:
Then for GDK4:
I also tried a bunch of other hyprland render variables and was not able to get similar fractional gdk geometry values like @uwidev. Could be related to the nvidia driver maybe? One interesting thing is that when the gdk scaleFactor is used to scale the gdk geometry (as in my case), rotating the screen 90 degrees does not swap the gdk width/height. So for me at least the rotation logic is incorrect. In @uwidev 's case where the gdk geometry is scaled by the fractional scale, the width/height IS swapped when rotated 90 degrees (similar to GDK4). Current theory is that in my case, both xdg_output and wl_output geometry always matches the original monitor resolution (regardless of rotation, strange). This results in GDK3 scaling the geometry with the scaling factor when it's 2. In @uwidev 's case, I think the xdg_output is prescaled with the fractional scale and transformed correctly, and because xdg_output is different to wl_output..? GDK3 doesn't apply any additional scaling. @uwidev /@tixwho if you wanted to do me and everyone else here a massive solid, you could generate similar tables to above for one of your monitors (remember you need to restart hyprland session after each change). |
|
The gdk key for uwidev's Ankor monitor should be: The hyprland key should be: I'm wondering if maybe the hyprland monitor width/height that Astal gets is already scaled by the fractional scale, so this code is scaling it twice. I'm going to push a change and we'll see if it fixes it.. |
|
Okay this most recent change fixes monitor matching when screens have a transform applied for my (scalefactor) case so that's nice! @uwidev I've made a change to how the fractional scaled key is generated, I'm not 100% sure whether it will work. However I've also just added some debug console logging. Could you update to this latest commit and apply the resolutions you were having issues with, then in a terminal Thank you so much for your support/testing this issue btw! |
|
|
IDK why Does't work for me either, but here is the debug output: |
|
@uwidev Aha! My first commits code was actually correct. The reason that it's not working for you is that hyprland is rounding up your Ankor monitors scale to two decimal places when reporting information. The scale you set in your config is HOWEVER for some reason when hyprland reports monitor scale, it rounds it up to two decimal places giving So this code takes the hyprland monitor scale Unfortunately scale rounding is a hyprland thing, it's not something that could ever be addressed with HyprPanel code (we can't get from 0.94 back to 0.9375). It would be ideal if hyprland rounded the scale to two decimal points when it scales the surface, that way the gdk geometry would be scaled by 0.94 but it's a super minor issue imo. You can just set the scale in your hyprland config to 0.94 and this will work just fine (scaling-wise it will probably be a few pixels difference, completely unnoticeable). I just need to revert the fraction key code to its previous logic. The other thing I'm seeing is that the hyprland width/height is:
We still don't have an explanation as to why you and tixwho have fractionally scaled gdk geometry in the first place but I can definitely make this PR work for you both! |
|
@wistfulbrick Wonderful news, thank you so much for the debugging and follow up!! Do you still need the table for comparison? And if so, since it looks like a decimal rounding issue, are there specific scaling factors you want me to try? |
|
@tixwho Nope! No need for you two to do anything until I've got this new commit out :) Taking a little longer because I'm cleaning up |
|
I have confirmed that rounding the decimal to 2 decimal places has solved the issue. Hyprland operates a bit funky now and doesn't align my monitors or something, but the bars are at least at the right place. |
|
@uwidev @tixwho This latest commit should now match monitors correctly for you both, let me know how it runs. If there's any issues, run hyprpanel in a terminal and give me the debug logs. @ppenguin it works sensibly on my machine but if you could test it again I would appreciate it (particularly monitor rotation/transforms). |
I'm guessing you have probably kept the monitor positions the same, you probably previously figured out the maths for positioning with the 0.9375 scale, you need to redo that math for 0.94 and it should behave more normally. |
|
Finally, work as expected! Posting log here just for reference: |
Still seems to work (on my desktop). |
|
@Jas-SinghFSU I think this is ready to review but I have two things to potentially clean up:
Assuming you have nothing else you'd like to change, once I'm done addressing the above I'll run a final lint and this will be ready to merge :) |
|
@wistfulbrick Great work and investigation! Thank you for that
Looks good, I'll get this reviewed :) |
|
Everything looks good and ready to merge once we fix the type errors and linter issues. Also one more thing, we can add those debug logs but only if |
|
Excellent, I'll get those sorted out. For the debug logs, they will be most useful when keyMatch is false but I think instead of putting them behind a condition I was looking into GJS logging practices. We can convert this logging to Unfortunately whilst GJS advises using the |
|
Yep, that sounds good. |
|
Okay, I think that covers everything! Let me know if you need anything else :) |
|
Thanks for the contribution ❤️. |
|
@wistfulbrick @Jas-SinghFSU just discovered HP and really positive about it. (Shameless plug: testing with versions was so easy because I'm on NixOS/home-manager, so I just change a repo/commit hash in my config and have a new version). I have a few feature ideas for HP but no time at all to work on them, will issue them separately... |
Building on top of the testing and discussion in #713
@Sawy7, sorry for the hijack! Happy for these changes to go into your PR instead, I just want to quickly test this.
Should fix #636 but needs to be tested by the folks in #713 who had fractionally scaled GDK geometry.
This should be linted correctly, please let me know if the comments are incorrect or if you have any other changes you want to make.