taaem/mutter-xwayland-fractional-scaling

Description

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.

Installation Instructions

Instructions not filled in by author. Author knows what to do. Everybody else should avoid this repo.

Active Releases

The following unofficial repositories are provided as-is by owner of this project. Contact the owner directly for bugs or issues (IE: not bugzilla).

Release Architectures Repo Download Fedora 40 x86_64 (0)* Fedora 40 (0 downloads)

* Total number of packages downloaded in the last seven days.


This is a companion discussion topic for the original entry at https://copr.fedorainfracloud.org/coprs/taaem/mutter-xwayland-fractional-scaling

Hello. I was trying to build mutter with this patch myself unfortunately after installing it and enabling the experimental features xwayland apps are still blurry. Did it work for you?

I haven’t actually updated to the Fedora 40 Beta, so I haven’t tested my build yet. But did you enable both experimental features?

$ gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer', 'xwayland-native-scaling']"

Yes I had them enabled. I also built gnome-settings-daemon with appropriate patch but it didn’t make a difference.

I managed to just get it all working!
I added instructions to taaem/mutter-xwayland-fractional-scaling Copr if you want to try this out.

Interesting. I will definitely try it out. How did you manage to make it working?

I had to rebase the mutter patches on the current state of the main branch, since they merged experimental vrr support there were some incompatibilities in the code and the experimental options.

If your interested the rebased patches can be found here:

Just spun this up on my Fedora 40 install and I just want to say THANK YOU for this Copr. Works absolutely perfectly. Steam and my games now properly see the full resolution of my 4K panel and even better, Steam’s baked in scaling actually means that it properly scales itself up on my 4K panel now as well so it actually looks sharp and not all fuzzy and awful like before.

Thank you again!

Hi! Congrats for your copr, it’s a very good idea. Is there any way to add Fedora 39 into the repository?

Greetings from France!

Ugo

Thank you for this COPR. But there is a serious bug on my device since version 46.3. Gnome shell crashes every time I try closing any XWayland window. I noticed that it won’t be reproduced in ArchLinux, so I rebuilt the package with patch from AUR and fix it successfully. Could you please fix it (refer to AUR’s patches) or turn to AUR’s patches directly?

Yes, I had that issue too, thats why I temporarily downgraded mutter again.
But I wasn’t aware of these AUR packages, I rebased my patches onto theirs and for me the issue is now fixed.
You should be able to update normally now.

Thanks a lot.

I don’t think thats easily possible, since mutter 46 probably requires gnome-shell 46, which is not in the Fedora 39 repos and I sadly don’t have the time to include everything in this copr.

Furthermore, I don’t have the time and capacity to backport the patches onto mutter 45.

My XWayland windows are clear, just really tiny. I tried with Chromium, which has an option to force scaling, for an integer 2, which brought it up to normal size, but unfortunately, the cursor stayed minuscule.

Did you reboot after enabling the new experimental option?

1 Like

Well, I tried again, and it’s working!

Just found a pretty substantial issue. For whatever reason, on my system 1920x1080 scaled by 1.25x Xorg applications are working with a 3072x1728 resolution. This dramatically reduces graphics performance in those applications (especially games) and it is really wasteful of the system. I have no idea why this is happening on my system. This persisted across numerous installs of Fedora 40, and apps still get this odd resolution. I checked that mutter, mutter-common, and gnome-settings-daemon are all from this copr repository. Is this just normal behaviour or is there something wrong?

Output from Xrandr:

Screen 0: minimum 16 x 16, current 3072 x 1728, maximum 32767 x 32767
eDP-1 connected primary 3072x1728+0+0 (normal left inverted right x axis y axis) 340mm x 190mm
   3072x1728     60.01*+
   2048x1536     60.01  
   1920x1440     59.97  
   1600x1200     59.96  
   1440x1080     59.99  
   1400x1050     59.98  
   1280x1024     59.89  
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   320x240       59.52  
   2560x1600     60.03  
   1920x1200     59.96  
   1680x1050     59.95  
   1440x900      60.03  
   1280x800      59.99  
   1152x720      59.97  
   960x600       59.96  
   928x580       59.88  
   800x500       59.50  
   768x480       59.90  
   720x480       59.71  
   640x400       59.95  
   320x200       58.96  
   2880x1620     60.00  
   2560x1440     60.01  
   2048x1152     59.98  
   1920x1080     60.05  
   1600x900      59.95  
   1368x768      59.88  
   1280x720      59.86  
   1024x576      59.90  
   864x486       59.92  
   720x400       59.55  
   640x350       59.77  

This is indeed also the case for me, I don’t actually know much of the implementation of these patches and if this is needed or not, but maybe check the original merge request and if this is not intended than maybe raise this issue there.

This is my first time using COPR for patched packages. Is it normal that if the original package (in updates repo) gets updated to a version newer than the patched version that DNF tries to update it? If so, can this be prevented?

I’m afraid it is normal. Because patches are not always up-to-date. I think it can’t be prevented, unless you update your system only after checking the packages’ versions and ensure the patches are ready. But you can rebuild them after updating.

1 Like

Works nicely for me so far on M2 Pro Fedora Asahi. Thanks!!
PSA: you might need to use --allowerasing --best in the dnf reinstall command.