I agree that my patch is no good and change you are suggesting is a better idea.
2017-01-31 18:15 GMT+02:00 Olivier Fourdan <[email protected]>: > Hi > >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574 >> >> Signed-off-by: Svitozar Cherepii <[email protected]> >> --- >> hw/xwayland/xwayland-cvt.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/hw/xwayland/xwayland-cvt.c b/hw/xwayland/xwayland-cvt.c >> index 9655e104e..d6ff305c7 100644 >> --- a/hw/xwayland/xwayland-cvt.c >> +++ b/hw/xwayland/xwayland-cvt.c >> @@ -101,7 +101,7 @@ xwayland_cvt(int HDisplay, int VDisplay, float VRefresh, >> Bool Reduced, >> VFieldRate = VRefresh; >> >> /* 2. Horizontal pixels */ >> - HDisplayRnd = HDisplay - (HDisplay % CVT_H_GRANULARITY); >> + HDisplayRnd = HDisplay; >> >> /* 3. Determine left and right borders */ >> if (Margins) { >> -- >> 2.11.0 > > I don't think the patch is correct, the code is to calculate a CVT mode and > 1366x768 is not compliant. > > So why does it actually matter? The root window has the correct size > (1366x768) whereas the CVT is used to compute the mode, which is not used > actually in Xwayland, apart for returning a mode in both xrandr and the > "fake" vidmode extension support in Xwayland. > > So I wonder, is it just about the mode name in xrandr? If so, then it would > be better to change the snprintf() at the end of xwayland_cvt() to to get > "1366x768" as the mode name without changing the actual CVT computation. > > Cheers, > Olivier > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
