frational-scale: Don't hard code denomainator

Using the denominator 120 artificially limits the way of implementing fractional scaling that makes it impossible in certain situations to describe a configuration where a fullscreen window covers the whole monitor.

In practice, it means a compositor who always uses the whole monitor resolution cannot agree on a common expected size of surface buffer sizes, as too much precision is lost when transferring the scale over the wire. This means compositors, in order to always be capable of getting the same resulting buffer size as clients, must artificially limit the scaling factor precision, which means it won't always be possible to get a logical fullscreen integer size to match screen resolution when scaled by the scaling factor.

Fix this by not hard coding the denominator, and allow compositors to transfer a factor without loosing precision. Compositors who want to continue to use scaling factors with less precision can hard code 120 in their own implementation to achieve the current behavior.

Signed-off-by: Jonas Ådahl jadahl@gmail.com

---

Since a few years prior to the fractional scaling factor protocol appeared, mutter has been using high precision scaling factors internally, and noticed that in some configurations this makes it impossible to get crisp results due to the loss of precision over the wire.

Requiring over painting, or not using the whole monitor resolution, doesn't seem like a limitation the fractional scaling protocol should enforce.

On a side note, I think we should consider dropping scaling factors completely, and and design a new protocol that ties into configure/ack_configure (where possible) and communicates expected buffer sizes, even if that means requiring roundtrips in certain scenarios.