On Do, 2016-11-03 at 12:41 +0100, Christophe Fergeau wrote:
On Thu, Nov 03, 2016 at 09:53:48AM +0100, Gerd Hoffmann wrote:
On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that the resolutions we are going to present to user-space are going to be rounded down to a multiple of 8. In the QXL arbitrary resolution case, this is not useful. This commit forces the actual width/height that was requested by the client in the drm_display_mode structure rather than keeping the rounded version.
Hmm, not sure this is a good idea. There are probably reasons why drm_cvt_mode is rounding down ...
Yeah, I'm sure there are reasons, but I don't know what they are. drm_cvt_mode seems to be calculating various frequencies and timings related to refreshing real world monitors, and this seems to be defined by some VESA standard. Maybe the rounding down is because the real-world monitors or VESA require it.
No worries here, we are in the virtual world, it for sure wouldn't break monitors ;)
Or maybe other parts of the kernel/userspace rely on this rounding down.
This is where I suspect we could run in trouble. Odd resolutions simply don't happen on physical hardware, all usual resolutions are a multiple of 8, most of them are even a multiple of 16.
Various image/video formats use 16x16 blocks. The qemu vnc server operates on 16x16 blocks too (and we had bugs in the past with odd resolutions).
Also scanlines and cachelines align nicely if you don't use odd resolutions.
I unfortunately don't know :(
I don't have definitive answers too, just a gut feeling that this might cause trouble.
Maybe we should add a module option for this? So there is an easy (as-in: doesn't require a kernel rebuild) way out in case it causes trouble in certain setups?
cheers, Gerd