User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.15) Gecko/2009101911 Red Hat/3.0.15-3.el5_4 Firefox/3.0.15 Graphical installs on 15" 1600x1200 IBM Thinkpad A22p are in 800x600 window with severe tearing in right 1/3, where Next and Cancel buttons are located. Possible bad mode lines in X. Work-arounds are to use base video (vesa driver) or text mode during initial installation. If base video is chosen, an xorg.conf is created that specifies the vesa driver which allows full 1600x1200 operation. When that xorg.conf file is renamed and the system rebooted, max resolution is reduced to 1280x1024 with severe tearing on the right side of the screen. Reproducible: Always Steps to Reproduce: 1. Select regular (not base) video graphical install 2. 3. Actual Results: An 800x600 window appears in the middle of a 1600x1200 display, and its right side suffers from multiple "tears" and "folds" that appear to be the result of an incorrect mode line set. The distorted area is the same that contains the Next and Cancel buttons in a Fedora install. Expected Results: The native video driver for an ATI Rage Mobility 128 should allow an undistorted video display (size??). The base video work-around results in a vesa driver installation. Except for its slow speed, the vesa driver otherwise offers satisfactory operation including high resolution. The Thinkpad A22p laptop is old, so it may not be worth devoting a lot of time and effort fixing this bug.
Created attachment 367384 [details] xorg log file using aty128fb (?) driver rather than vesa driver Please pass to Adam Williamson. Tnx.
Created attachment 367385 [details] Extract of 'lspci -vv'
(**) R128(0): Using flat panel for display (II) R128(0): Primary Display == Type 2 (II) R128(0): Panel size: 1600x1200 (II) R128(0): Panel ID: LG.PHILIPS LP150U1-A2 (II) R128(0): Panel Type: Color, Single, TFT (II) R128(0): Panel Interface: LVDS (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=25000; xclk=10500 ... (II) R128(0): VESA VBE DDC supported (II) R128(0): VESA VBE DDC Level none (II) R128(0): VESA VBE DDC transfer in appr. 2 sec. (II) R128(0): VESA VBE DDC read failed (==) R128(0): Using gamma correction (1.0, 1.0, 1.0) (II) R128(0): <default monitor>: Using hsync range of 31.50-74.01 kHz (II) R128(0): <default monitor>: Using vrefresh range of 56.00-59.92 Hz ... (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) R128(0): Not using default mode "1600x1200" (hsync out of range) (II) R128(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) ... (--) R128(0): Virtual size is 1280x1024 (pitch 1280) (**) R128(0): *Default mode "1280x1024": 162.0 MHz (scaled from 108.0 MHz), 64.0 kHz, 60.0 Hz (II) R128(0): Modeline "1280x1024"x60.0 162.00 1280 1344 1368 1840 1024 1026 1029 1074 +hsync +vsync (64.0 kHz) This part of the bug looks very similar to a bug ajax fixed in the vesa driver for me a while ago: even though the driver knows the panel size (via the BIOS I guess), it refuses to use it because it can't read DDC info from the panel, uses a default hsync range, and the correct resolution is outside this range. It winds up using 1280x1024, which the panel obviously doesn't handle very well. Fix should be fairly simple. Hopefully the tearing goes away when we fix it to use the correct resolution :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Isn't this duplicate of bug 493441 ?
indeed, looks like it, sorry - I was in a rush yesterday and didn't think to check for dupes. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 493441 ***