Can someone cherry-pick this .... 87495fc7064d5e0a7575a0713b6895a4172df0fa for server-1.4-branch ??
can you please explain why? making the mode equal function not actually test if the modes are equal, doesn't seem like the kind of obvious change that needs zero explanation. if you need to fudge (which this function seems to be designed to prevent), why not use a fudge factor, instead of taking 1280x768 for 1024x768?
10101 is 7.4, which you've already committed your change to master for.
ah yes, i forgot that it's 1.3 xserver that was released after 7.2 and there was never a 7.3 release.
(In reply to comment #1) > can you please explain why? making the mode equal function not actually test if > the modes are equal, doesn't seem like the kind of obvious change that needs > zero explanation. if you need to fudge (which this function seems to be > designed to prevent), why not use a fudge factor, instead of taking 1280x768 > for 1024x768? > If you look at the current code, the >= is already done xres_virtual to handle displayWidth vs virtualX issues. With fbdev the driver can adjust the virtual y resolution to accelerate YPAN/YWRAP scrolling. Yes, this may well be an fbdev issue, but we need to handle it too. Ideally the fbdev driver would just allocate enough memory to handle the resolution, but with the new acceleration scheme available in fbdev drivers we need to handle these cases. So allowing yres_virtual allows fbdev drivers that got broken with the change to work again. As the "mode equal" was only introduced in xxerver 1.3 and broke some fbdev drivers.
OK, justified this change to myself now. Pushed. (The confusing part was that this isn't about the actual mode resolution in xres/yres, just about the memory backing the display, which we really don't care about)
Exactly. Thanks Eric.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.