© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
There's no need for a vv6 "completely disabling fractional scaling" because that's the first thing we already tried in vv1 and it didn't work as mentioned in comment #11. If you want to test it again then see https:/
> I did test that with a Cinnamon session and confirmed it. I basically did:
> xrandr --output VNC-output-1 --auto
> and it immediately goes to a blank screen
Cinnamon might not be the best test case because it used to be based on mutter. We need to test a desktop environment that has no relation to mutter to confirm that's a bug in the DCV viewer/server. Or any simple X session with a legacy window manager?
> - Fractional scaling is supported in RandR 1.3 or newer
> - Xdcv reports its RandR version is 1.6, but when you try to use fraction scaling it errors (error id 2)
I want to say that's an Xdcv bug but by chance I am working on NVIDIA right now and find it returns the same errors from xrandr --scale or --transform. Yet somehow fractional scaling still works on NVIDIA!? This might not matter because so far this issue has not stopped us from progressing on the main revert bug 2020782.
> - The corruption bug 1924689 may be caused by the fractional scaling patch (or a side effect of the "error id 2"?)
Maybe, not sure. It won't take much effort to confirm if the same mutter corruption bug occurs without the fractional scaling patch. But it's also a separate bug so I would prefer to keep that conversation separate.
> - Xdcv is reporting a bogus refresh rate
That's an Xdcv bug which is probably also intentionally a design feature. I think it should be fixed in Xdcv because this design will break other compositors like it has broken mutter. Technically correct compositor behaviour would be to render at 0Hz, which would not be usable ;) So Xdcv probably should be changed to avoid the same problem occuring in other desktop environments.
> - There's a "config history" issue identified by Mustafa in comments #26 and #30
The config history raised by Mustafa in comment #30 should be treated as an enhancement request and logged elsewhere (https:/
I want to keep this bug focussed on the failure to revert because the conversation gets too complex otherwise. And also to avoid the expectation that multiple bugs should be fixed under a single bug number.