© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Yes I think when using Xdcv we just need to make sure fractional scaling is ALWAYS DISABLED and ignore any bugs that occur if it is enabled, for the time being. :(
While Xdcv reports its RandR version is 1.6, when you try to actually use it (you can test with xrandr --scale or --transform) it will report BadValue which is the cause of:
Impossible to set scaling on crtc 59 to 1.000000, error id 2
And our fractional scaling patch does try to do the right thing - it queries the RandR version and only enables when the reported version is at least 1.3. Since Xdcv reports version 1.6 and returns errors instead of implementing the feature, it's Xdcv at fault there and we have no easy way to work around it either. Just keep fractional scaling always disabled is what I would recommend. The fractional scaling patch is possibly also at fault for not cleanly recovering from the unexpected RandR errors, but this error message:
Impossible to set scaling on crtc 59 to 1.000000, error id 2
suggests that it's the recovery/revert that's failing due to the incomplete RandR implementation in Xdcv. So actually I can't imagine how the fractional scaling patch could do better without Xdcv getting fixed first. Just disable fractional scaling I say.
I think I have been able to hit the bug without fractional scaling but it might have been some residue on the mutter side if it was started with fractional scaling enabled. So please check again:
1. Disable fractional scaling.
2. Log out of gnome-shell and restart the test session.
3. Try to change the scale between 100% and 200% again.
4. If the bug still occurs then please repeat with:
https:/