1 |
On Wed, Aug 25, 2010 at 7:57 AM, Paul Hartman |
2 |
<paul.hartman+gentoo@×××××.com<paul.hartman%2Bgentoo@×××××.com> |
3 |
> wrote: |
4 |
|
5 |
> On Wed, Aug 25, 2010 at 9:44 AM, Mick <michaelkintzios@×××××.com> wrote: |
6 |
> > On 25 August 2010 15:38, Paul Hartman <paul.hartman+gentoo@×××××.com<paul.hartman%2Bgentoo@×××××.com>> |
7 |
> wrote: |
8 |
> >> On Wed, Aug 25, 2010 at 9:25 AM, Mick <michaelkintzios@×××××.com> |
9 |
> wrote: |
10 |
> >>> On 25 August 2010 15:17, Paul Hartman <paul.hartman+gentoo@×××××.com<paul.hartman%2Bgentoo@×××××.com>> |
11 |
> wrote: |
12 |
> >>>> On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman <kogorman@×××××.com> |
13 |
> wrote: |
14 |
> >>>>> I found the specs with Hsync and VSync limits, but they don't mention |
15 |
> the |
16 |
> >>>>> clock speed. I guess I'll just have to fool with it until it works |
17 |
> or |
18 |
> >>>>> catches fire. |
19 |
> >>>> |
20 |
> >>>> That basically describes the way I've done my X monitor settings for |
21 |
> >>>> the past 10 years or so. I just made up a bunch of numbers and hope |
22 |
> >>>> they accidentally work. :) Now I'm thankful for EDID in monitors and |
23 |
> >>>> smarter video drivers. |
24 |
> >>> |
25 |
> >>> I think that if xrandr -q does not show the resolution you are |
26 |
> >>> seeking, then the video card or driver in question cannot provide it. |
27 |
> >>> I'm not sure that feeding xorg any odd modeline will change things, |
28 |
> >>> plus unlike a CRT monitor, LCDs only provide a clear image at their |
29 |
> >>> native resolution (denoted by '+' in the xrandr list of resolutions) |
30 |
> >> |
31 |
> >> I've been able to generate modelines in the past for all kinds of |
32 |
> >> crazy non-standard resolutions. I think the ones listed may be the |
33 |
> >> ones defined in the card's BIOS. |
34 |
> >> |
35 |
> >> I just remembered about CVT, I think it's what I used to generate the |
36 |
> >> modelines I posted earlier. It is part of the x11-base/xorg-server |
37 |
> >> package and will generate the frequencies and everything for you based |
38 |
> >> on VESA standards. You simply give it X and Y resolution and it does |
39 |
> >> the rest. For example: |
40 |
> >> |
41 |
> >> $ cvt 1280 720 |
42 |
> >> # 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz |
43 |
> >> Modeline "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 |
44 |
> >> 748 -hsync +vsync |
45 |
> > |
46 |
> > Fair enough, but anything other than the native resolution on an LCD |
47 |
> > monitor will end looking distorted or blurred. |
48 |
> |
49 |
> Of course, and I agree completely, but what I was going for was at |
50 |
> least he can get blurry 16:9 that fills the whole screen rather than |
51 |
> 4:3 that is either stretched or leaves gaps on the sides. :) |
52 |
> |
53 |
> |
54 |
Precisely my goal when I started this thread. In my case, native appears to |
55 |
be 1920x1080. |
56 |
With no xorg.conf, X finds 1280x1024, which is usable either stretched, or |
57 |
with the gaps. |
58 |
There is no discernable flicker, blur or distortion, just capacity that is |
59 |
not being used. |
60 |
|
61 |
There are some confusing things about this. |
62 |
- The log contains 1920x1080 modelines, but is not using them or clearly |
63 |
stating the reason. |
64 |
- The log contains the lines |
65 |
(!!) MACH64(0): Virtual resolutions will be limited to 8191 kB |
66 |
due to linear aperture size and/or placement of hardware cursor |
67 |
image area. |
68 |
|
69 |
I have no idea how to reconcile that with the fact that the resolution |
70 |
being used results in |
71 |
1310720 (1.3 million) pixels, at 3 bytes (24 bits) per pixel, which |
72 |
sounds to me like over |
73 |
3 megabytes. The desired resolution would have 2073600 (2 million) |
74 |
pixels and about |
75 |
6 megabytes. They sound too big, but the first one actually works. I |
76 |
don't understand this at all. |
77 |
|
78 |
- (--) MACH64(0): Internal programmable clock generator detected. |
79 |
(--) MACH64(0): Reference clock 157.5/11 (14.318) MHz. |
80 |
(II) MACH64(0): <default monitor>: Using hsync range of 30.00-85.00 kHz |
81 |
(II) MACH64(0): <default monitor>: Using vrefresh range of 55.00-75.00 Hz |
82 |
(II) MACH64(0): <default monitor>: Using maximum pixel clock of 160.00 |
83 |
MHz |
84 |
(II) MACH64(0): Estimated virtual size for aspect ratio 1.7931 is |
85 |
1920x1080 |
86 |
(this bothers me because, 1920/1080 is |
87 |
more like 1.7777) |
88 |
(II) MACH64(0): Maximum clock: 120.00 MHz |
89 |
|
90 |
So it's still contemplating 1920x1080, but mentions both 120MHz and 160MHz |
91 |
as the max |
92 |
for pixel clock. Anyway, for 2 million pixels, 120MHz is not going to cover |
93 |
any overhead at 60 Hz, and 55Hz might not make it either. Maybe the MACH64 |
94 |
cannot actually get above 120 MHz. How to find out if that's what the log |
95 |
is trying to say? |
96 |
|
97 |
- it complains about memory for 2048x1536, but not for anything smaller (I |
98 |
don't think the monitor has that many pixels anyway.) So I guess there's |
99 |
memory enough for all the others. Instead it complains about many modelines |
100 |
in this fashion (but showing just the last 2 lines) |
101 |
(II) MACH64(0): Not using driver mode "1920x1080" (bad mode |
102 |
clock/interlace/doublescan) |
103 |
(WW) MACH64(0): Shrinking virtual size estimate from 1920x1080 to |
104 |
1280x1024 |
105 |
|
106 |
|
107 |
-- |
108 |
Kevin O'Gorman, PhD |