On 4 November 2016 at 20:41, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote: >> > 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. > > I think this might be fine actually, there is already one such > resolution in the kernel, which is 1366x768 (1366 is only a multiple of > 2). There is already a bit of a hack to handle it anyway, see > fixup_mode_1366x768() in drm_edid.c. > >> >> 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? > > This seems a bit overkill to me, but I can look into it if needed. I think we should try it an see, if we see problems you could enforce the framebuffer would have a stride aligned to whatever value, and just the view into the framebuffer could be whatever. The CVT stuff is just due to how hw is programmed and monitors are described. Dave. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel