I'm sending this message because I think others might benefit from my
success in getting the external monitor to work on a Sony Vaio
PCG-C1VFK with XFree86 4.1.0 on Linux 2.4.9 (Red Hat 7.2).

An unexpected side benefit of my solution is that I am able to switch
from viewing the virtual screen through a LCD-panel-sized viewport on
the built-in panel to viewing the entire virtual screen at full size
on the external monitor only.

This machine uses the ATI Rage Mobility P/M video hardware (I think),
which others have reported trouble with.  My solution requires using
the "atitvout" program at key moments during the running of the
XFree86 server.  In particular, I need to run it at least once after
starting the X server and after every video mode change.  As of
2002-04-01, you can find atitvout at:

  http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/

Although my solution seems to work fine, I'm not fully satisfied
because it is a bit awkward to change video modes (I can't just use
the Control-Alt-KP_Add and Control-Alt-KP_Subtract key combinations)
and on occasion, I have experienced the machine hanging completely
when changing video modes.  Also, it is quite awkward to recover from
the strange things that happen when I switch VTs.  So it would be
great if someone who understood these things better could incorporate
the essence of the solution into the next version of XFree86 in a less
hang-prone manner.

I've enclosed my /etc/X11/XF86Config-4 file below.  There are comments
in the file that explain how I change from one video mode to another
and recover from strange things that go wrong.

-- 
Joe Wells

----------------------------------------------------------------------
# This is for a Sony Vaio PCG-C1VFK running mainly Red Hat Linux with
# a few updated RPMs.  In particular, the XFree86 RPM is numbered
# 4.1.0-15.

Section "ServerLayout"
        Identifier     "internal"
        Screen         0 "Screen 0|internal"
        InputDevice    "Mouse0"    "CorePointer"
        InputDevice    "USB Mice"  "SendCoreEvents"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "ServerLayout"
    Identifier     "external"
    Screen         0 "Screen 0|external"
    InputDevice    "Mouse0"    "CorePointer"
    InputDevice    "USB Mice"  "SendCoreEvents"
    InputDevice    "Keyboard0" "CoreKeyboard"

    # We need to invoke the "atitvout" program to get the external
    # monitor to work.  As of 2002-04-01, you can find this program
    # at:
    #
    #   http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout/
    #
    # The "sleep 10" seems to be enough time to allow the client
    # session to start up.  Unfortunately, there doesn't seem to be
    # any way just using this file to guarantee that the invocations
    # of "atitvout" are properly delayed.
    Option         "VTInit"    "(echo VTInit sleeping; sleep 10; echo VTInit about to 
act; a=/usr/local/bin/atitvout; $a c; $a auto; echo VTInit done) 1>&2 &"

    # With this setup, I start out viewing the virtual screen through
    # a 1024x480 viewport on both the internal LCD panel and external
    # monitor.  Let "vn" stand for "xvidtune -next" and let "a" stand
    # for "atitvout".  Let "small" stand for "vn; a lc" and let
    # "large" stand for "vn; a c".  Then I can switch to viewing the
    # entire virtual screen on the external monitor with "large".  I
    # can switch back to viewing through the small viewport on both
    # LCD panel and external monitor with "small".  When viewing
    # through the small viewport, I can also turn off the external
    # monitor with "a l".  (Why though?  Perhaps for privacy.  Or
    # maybe driving the external monitor takes extra power?)

    # Things seem to get screwed up when I switch to another VT and
    # then switch back.  However, enough repetition of the commands
    # mentioned above seems to eventually clear things up.  In
    # particular, if I switched while in large mode, then "small;
    # large" will restore things.  If I switched while in small mode,
    # then things are more difficult.  I have discovered the sequence
    # "large; chvt 1; chvt 8; vn; vn; small" will restore things
    # (assuming the X server is using VT 8).  Unfortunately, the
    # text-mode VTs seem to be permanently mildly screwed up by this
    # stuff.

    # WARNING:  I have experienced the machine hanging completely when
    # running the "small" command.  It was not just X that hung, the
    # entire machine was unresponsive.  In particular, SSH sessions
    # from another machine were hung and the machine stopped
    # responding to ping.
EndSection

# # For someday when the ATI driver supports using both CRTCs of the
# # ATI Rage Mobility P/M.
#
#Section "ServerLayout"
#        Identifier     "multi-head"
#        Screen         0 "Screen 0|internal"
#        Screen         1 "External Screen" LeftOf "Screen0"
#        InputDevice    "Mouse0" "CorePointer"
#        InputDevice    "USB Mice" "SendCoreEvents"
#        InputDevice    "Keyboard0" "CoreKeyboard"
#        Option "Xinerama"  "true"
#EndSection

Section "Files"
    # Is this needed?  I thought this was the default.
    RgbPath     "/usr/X11R6/lib/X11/rgb"
    # Use xfs instead of specific font directories.
    FontPath   "unix/:7100"
EndSection

Section "Module"
        Load "GLcore"  # OpenGL support
        Load "glx"     # OpenGL X protocol interface
        Load "dbe"     # double buffering
        Load "extmod"  # miscellaneous extensions (e.g., SHAPE)
        Load "fbdevhw"
        Load "pex5"    # PHIGS for X 3D environment (obsolete?)
        Load "dri"     # Direct Rendering Infrastructure
        #Load "drm"    # more of Direct Rendering Infrastructure
        Load "record"  # X event recorder (needed?)
        Load "xie"     # X image extension (obsolete?)
        #Load "v4l"    # video for Linux
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbLayout" "gb"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol"        "PS/2"
        Option      "Device"          "/dev/psaux"
        #Option     "Device"          "/dev/mouse"   # why not this instead?
        Option      "ZAxisMapping"    "4 5"
        Option      "Emulate3Buttons" "no"
EndSection

Section "InputDevice"
        Identifier  "USB Mice"
        Driver      "mouse"
        Option      "Protocol"        "IMPS/2"
        Option      "Device"          "/dev/input/mice"
        Option      "ZAxisMapping"    "4 5"
        Option      "Buttons"         "5"
        Option      "Emulate3Buttons" "no"
EndSection

Section "Monitor"
    Identifier  "Sony Vaio PCG-C1VFK LCD Panel"
    VendorName  "Sony"
    ModelName   "Vaio PCG-C1VFK"

    # If we want to experiment with this while using the crt_screen
    # option, then we need to supply the following values.
    #HorizSync     30.0-70.0
    #VertRefresh   50.0-160.0

    # Some mode lines for this panel that I have seen.  I don't think
    # I've tried any of them.
    #Modeline "1024x480"   65    1024 1032 1176 1344   480  491  493  525 -hsync -vsync
    #Modeline "1024x480"   65    1024 1032 1176 1344   480  488  494  563 -hsync -vsync
    #ModeLine "1024x480"   65    1024 1048 1192 1216   480  497  501  502 -hsync -vsync

    # This mode line is reported to work correctly for the built-in LCD
    # panel when _not_ using the new kernel framebuffer support, which
    # is reported to be a choice one must make to get an external
    # monitor to work.  However, I got the external monitor working
    # another way.
    #Modeline "1024x480" 65.00 1024 1032 1176 1344 480 488 494 560 -hsync -vsync

    # This mode line is also reported to actually work, but maybe this
    # is for a kernel version without framebuffer support.
    #ModeLine "1024x480" 65.00 1024 1032 1176 1344   480  488  494  563 -hsync -vsync

    # The final correct mode line was found at
    # http://www.stevebarr.com/cgi-bin/cgiwrap/barrst/goto.pl?c1vnsol
    # where it is credited to "gandalf".  Apparently, the correct
    # values are changed by using the new kernel framebuffer support.
    ModeLine "1024x480" 65    1024 1048 1192 1216   480  488  494  563 -hsync -vsync

    # The ATI driver automatically adds a mode named "Native panel mode"
    # to the mode table based on hardware probing.  However, this mode
    # doesn't actually work very well as lines of pixels are cut off
    # of the borders of the display.

    # I'm not sure exactly what effect this will have for the built-in
    # LCD panel, but why not?
    Option "dpms"
EndSection

Section "Monitor"
    Identifier    "External Monitor"
    VendorName    "unknown"
    ModelName     "unknown"
    HorizSync     30.0-70.0
    VertRefresh   50.0-160.0

    # Various mode lines I am not using.
    # # 1024x768 @ 60 Hz, 48.4 kHz hsync
    # Modeline "1024x768@60Hz"    65    1024 1032 1176 1344   768  771  777  806 
-hsync -vsync
    # # 1024x768 @ 70 Hz, 56.5 kHz hsync
    # Modeline "1024x768@70Hz"    75    1024 1048 1184 1328   768  771  777  806 
-hsync -vsync
    # # 1024x768 @ 76 Hz, 62.5 kHz hsync
    # Modeline "1024x768@76Hz"    85    1024 1032 1152 1360   768  784  787  823
    # # 1024x768 @ 85 Hz, 70.24 kHz hsync
    # Modeline "1024x768@85Hz"   98.9  1024 1056 1216 1408   768 782 788 822 -HSync 
-VSync
    # # 1024x768 @ 100Hz, 80.21 kHz hsync
    # Modeline "1024x768@100Hz"   115.5  1024 1056 1248 1440  768  771  781  802 
-HSync -VSync
    # # "1024x768" @ 76 Hz, 60.9 kHz

    # # These settings obtained via xvidtune with Sony Multiscan100sf monitor.
    # Modeline "1024x768@76Hz B" 81.3 1024 1046 1156 1334 768 771 779 802

    # An attempt to push the hsync signal much later to try to work
    # around some strange problems which turned out to be unrelated.
    # Modeline "1024x768@75Hz B" 80.277600 1024 1168 1280 1328 768 771 780 806

    # "1024x768" @ 75 Hz, 60.45 kHz
    # (calculate-mode-line 75.0 1024 768 standard-sync-timings)
    Modeline "1024x768@75Hz" 80.277600 1024 1064 1176 1328 768 771 780 806

    # We make available a mode line for use with the internal CRT.  If
    # we are running with the crt_screen option and we switch to this
    # mode, we can turn on the LCD panel with "atitvout l" or
    # "atitvout lc" and it will display things.  Cool!
    ModeLine "1024x480" 65    1024 1048 1192 1216   480  488  494  563 -hsync -vsync

    Option        "dpms"
EndSection

Section "Device"
    # X reports: "ATI Mach64 LR rev 100"
    # lspci reports "ATI Technologies Inc Rage Mobility P/M (rev 64)"
    # Optimistically, we are assuming the latter is correct ...
    Identifier   "ATI|Rage Mobility P/M|Screen 0|internal"
    Driver       "ati"
    BusID        "PCI:0:13:0"
    VendorName   "ATI Technologies, Inc."
    BoardName    "ATI Rage Mobility P/M"
    Screen       0
EndSection

Section "Device"
    Identifier   "ATI|Rage Mobility P/M|Screen 0|external only"

    # The main effect of the crt_screen option is to immediately turn
    # on a signal to the external monitor and turn off power to the
    # internal LCD panel.  However, the signal is screwed up seemingly
    # because it is still carrying out computations as though it were
    # displaying to the LCD panel.  This generally means the portions
    # of the display are rearranged horribly or the external monitor
    # fails to recognize the signal at all and is blank.  The only way
    # to fix it is by running "atitvout c".
    Option       "crt_screen"

    Driver       "ati"
    VendorName   "ATI Technologies, Inc."
    BoardName    "ATI Rage Mobility P/M"
    BusID        "PCI:0:13:0"
    Screen       0

    # Various junk that I was experimenting with.
    #
    # The extern_disp option is not used by either "ati" or "vesa"
    # drivers.
    #Option       "extern_disp"
    # The composite_sync option does not seem to have had an effect.
    #Option "composite_sync" "off"
    # An attempt not to use the "ati" driver.  However, it got
    # restricted to the 480 pixel height of the LCD panel for some
    # reason.  The crt_screen and extern_disp options were ignored.
    #Driver       "vesa"
    # Ordinarily, the following information would be determined by
    # probing, but maybe this doesn't work when using the "vesa"
    # driver.  Maybe this will help in other cases.  Who knows?
    #ClockChip    "Internal"
    #VideoRam     8192
EndSection

# # I will need something like the following for use with Xinerama
# # someday when the ATI driver supports it.
#
# Section "Device"
#     Identifier   "ATI|Rage Mobility P/M|Screen 1"
#     Driver       "ati"
#     BusID        "PCI:0:13:0"
#     VendorName   "ATI Technologies, Inc."
#     BoardName    "ATI Rage Mobility"
#     Screen       1
# EndSection

Section "Screen"
    Identifier          "Screen 0|internal"
    Device              "ATI|Rage Mobility P/M|Screen 0|internal"
    Monitor             "Sony Vaio PCG-C1VFK LCD Panel"
    DefaultColorDepth   16
    Subsection          "Display"
        Depth               24
        Modes               "1024x480"
    EndSubsection
    Subsection          "Display"
        Depth               16
        Modes               "1024x480"
    EndSubsection  
    Subsection          "Display"
        Depth               8
        Modes               "1024x480"
    EndSubsection  
EndSection

Section "Screen"
    Identifier          "Screen 0|external"
    Device              "ATI|Rage Mobility P/M|Screen 0|external only"
    Monitor             "External Monitor"
    DefaultColorDepth   16
    Subsection          "Display"
        Depth               24
        Virtual             1024 768
        Modes               "1024x480" "1024x768@75Hz"
    EndSubsection
    Subsection          "Display"
        Depth               16
        Virtual             1024 768
        Modes               "1024x480" "1024x768@75Hz"
    EndSubsection  
    Subsection          "Display"
        Depth               8
        Virtual             1024 768
        Modes               "1024x480" "1024x768@75Hz"
    EndSubsection  
EndSection

Section "DRI"
    # Sets the permissions on /dev/dri/card? to allow anyone on the
    # system with a connection to the X server access to the
    # hardware.  ????
    Mode 0666
EndSection
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to