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
