I found some problems associated with the new mode validation code released in 7.2: (1) In xf86Mode.c, this portion of code is used for shrinking virtual size if necessary after mode pool is created: /* * If we estimated the virtual size above, we may have filtered away all * the modes that maximally match that size; scan again to find out and * fix up if so. */ if (inferred_virtual) { int vx = 0, vy = 0; for (p = scrp->modes; p; p = p->next) { if (p->HDisplay > vx && p->VDisplay > vy) { vx = p->HDisplay; vy = p->VDisplay; } } if (vx < virtX || vy < virtY) { xf86DrvMsg(scrp->scrnIndex, X_WARNING, "Shrinking virtual size estimate from %dx%d to %dx%d\n", virtX, virtY, vx, vy); virtX = vx; virtY = vy; linePitch = miScanLineWidth(vx, vy, linePitch, apertureSize, ^^^^^^^^^ BankFormat, pitchInc); } } Is there any reason, in re-calculating linePitch, the old linePitch, a value corresponding virutual size before shrinking, is used instead of minPitch ? We saw an example, where virtual size before shrinking is 1600x1200, after shrinking is 1280x1024, but the new linePitch is still 1600 which causes garbled screen. The problem could be solved using minPitch. (2) By using the largest mode size of all modes, the use of EDID detailed timing sector mode (even preferred) is not enforced. In the example below Supported Future Video Modes: (II) NV(0): #0: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) NV(0): #1: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) NV(0): #2: hsize: 640 vsize 400 refresh: 70 vid: 2609 (II) NV(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) NV(0): #4: hsize: 1280 vsize 960 refresh: 85 vid: 22913 (II) NV(0): #5: hsize: 1280 vsize 1024 refresh: 85 vid: 39297 (II) NV(0): #6: hsize: 1600 vsize 1200 refresh: 70 vid: 19113 (II) NV(0): #7: hsize: 1600 vsize 1200 refresh: 75 vid: 20393 (II) NV(0): Supported additional Video Mode: (II) NV(0): clock: 94.5 MHz Image Size: 300 x 225 mm (II) NV(0): h_active: 1024 h_sync: 1072 h_sync_end 1168 h_blank_end 1376 h_border: 0 (II) NV(0): v_active: 768 v_sync: 769 v_sync_end 772 v_blanking: 808 v_border: 0 (II) NV(0): Serial No: 24Y034300132 mode "1600x1200" is chosen, instead the of "1024x768" in detailed timing sector. (3) M_T_USERDEF deos not seem to be used in any modelines. Why user defined modes are not given type M_T_USERDEF in configMonitor() of xf86Config.c ?
Created attachment 9969 [details] [review] Patch to solve problem The patch tries to fix the problem (2). The fix it to enforce to use of preferred mode during validation process: If there is no config file, or Modes are not defined in config file, then add the preferred mode (with M_T_PREFERRED on in type) if any, to the top of mode validation list. The preferred mode is picked up in the sequence from modes of type M_T_BUILTIN, M_T_USERDEF and M_T_DRIVER. The fix for problem (1) and prolem (2) is obvious and is already described in description field.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.