"Orlando Andico" <[EMAIL PROTECTED]> writes:
> i did this the hard way. using FC6 on a Toshiba M6 (1280x800 screen)
>
> first add/edit the monitor section to /etc/X11/xorg.conf
>
> Section "Monitor"
> Identifier "LocalLCD"
> HorizSync 47 - 54
> VertRefresh 59 - 61
> Option "DPMS"
> EndSection
>
> notice i've tweaked the VertRefresh to 61 Hz, actually its only 60 Hz
> but the Intel driver falsely calculates the refresh for 1280x800 to be
> 60.xxx Hz which is > 60 Hz and so the 1440x800 resolution is
> "disallowed"
>
> and then in the video card section
>
> Section "Device"
> Identifier "Videocard0"
> Driver "i810"
> Option "DDC" "false"
> EndSection
>
>
> added the parameter Option "DDC" "false" so that the video card
> doesn't try to auto-detect monitor timings and instead will use the
> one you specified in your Monitor section.
You know, that reminds me -- the driver isn't necessarily the one
falsely calculating the 60.xxx Hz. Some monitors actually give out the
wrong timings for driving them. I have a 19" widescreen AOC LCD monitor,
and it gives the wrong timings.
However, this reminds me -- I've been running a bleeding-edge X system
for the past two weeks and it has been a blast. Here are a few
highlights of the stuff coming down the pipeline, especially nice if you
have an Intel i810-based video card:
- A new version of the XRandR protocol (1.2). Why is this nice? Two
words: dual head. At runtime. WITHOUT xorg.conf tweaking. WITHOUT
reloading X. This needs support at the video driver level, of
course -- and what do you know, the intel driver is the first to
implement it. The other cards will follow suit, of course;
- A better intel video driver. The new intel driver no longer needs
915resolution to patch the video BIOS modes because it does
modesetting itself, as part of the changes to support XRandR
1.2;
- Less mucking about with modelines and what-not. Because the intel
driver now does native modeswitching without the video BIOS, and
because of XRandR 1.2, the driver now automagically figures out
the native resolution of the output devices plugged into it via
EDID/DDC.
Currently though, the XRandR 1.2 magic isn't that automagic -- you have
to use the new(er) xrandr commandline tool to manage the
outputs. Hopefully, someone will come up with a desktop applet or
similar that'll do the xrandr stuff automagically.
In my case, this is what I do to use an LCD monitor at 1440x900:
1. Plug in the monitor into my laptop
2. In a terminal:
$ xrandr --output VGA --auto --left-of LVDS
which tells the X server to place the LCD monitor at the left of my
LVDS (local display). Don't ask me what LVDS is, really.
3. Umm... that's it.
Some other features of xrandr(1):
- You can tell both displays to show the same thing by issuing a
--same-as, e.g. 'xrandr --output VGA --same-as LVDS';
- You can control the resolutions of each individual display with
--mode;
- Running xrandr(1) as-is shows what outputs are connected and what
resolutions are supported by the connected outputs.
Now, some caveats:
- Being bleeding-edge, there are some problems with the intel driver
(in particular). For some reason, I don't get XV output, and
disabling it in xorg.conf will make the X server segfault. I've
already filed a bug about it. Another is there seems to be a
corruption bug in the driver involving DPMS and what-not -- I get
hard lockups sometimes when I leave my laptop idle with the lid
closed (which turns off the display). I can't reproduce it, but I
can more-or-less work around it -- I don't turn of my laptop
display by closing the lid or from gnome-screensaver
- Because of a limit (either in the driver or in the hardware, I'm
not sure), you can't enable DRI when the framebuffer width is >
2048 px. This means that the software-based Mesa GL engine is used
instead. What's the framebuffer width? It's the total width of all
the displays you connect side-by-side; you can work around this by
saying that the displays are --above or --below each other
instead. Still, this isn't a big problem for me, as I don't do 3D
anyway.
- I kinda fibbed a bit. There is some configuration to be done in
xorg.conf. You have to add a Virtual line in the Display
subsection of the Screen section, as such:
Section "Screen"
Identifier "Default Screen"
Device "Intel 82852/855GM Integrated Graphics Device"
Monitor "Generic Monitor"
DefaultDepth 24
SubSection "Display"
Depth 24
Virtual 2464 900
EndSubSection
EndSection
If not, you can only have a maximum screen area big enough to fit
the maximum resolutions of all *connected* displays -- annoyance
if you don't have the external display connected at server
startup.
The set up has been nice, to say the least. Sure, I bleed a bit from the
current bugs, but it hasn't been that bad. They're not a major
inconvenience, and I still get work done anyway. :)
FWIW: I use ion3 as my window manager; the downside of it is that I
have to restart ion3 for it to see the screen area change. GNOME
(Metacity) didn't have an issue with it, and the desktop pager did see
the screen change. The panel wasn't resized, however, to fit the new
width. Haven't tried KDE.
--
JM Ibanez
Senior Software Engineer
Orange & Bronze Software Labs, Ltd. Co.
[EMAIL PROTECTED]
http://software.orangeandbronze.com/
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
