X.Org vs XFree86 - Debian

This is a discussion on X.Org vs XFree86 - Debian ; Most of my GNU/Linux installations use Debian 3.1, with older Ubuntu, Fedora Core, Lindows, Mandrake, Red Hat, Slackware, etc. IIRC, these all use XFree86, and I had to learn to fine-tune it over the years. Debian 4.0 uses X.Org. I ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: X.Org vs XFree86

  1. X.Org vs XFree86

    Most of my GNU/Linux installations use Debian 3.1, with older Ubuntu,
    Fedora Core, Lindows, Mandrake, Red Hat, Slackware, etc. IIRC, these all
    use XFree86, and I had to learn to fine-tune it over the years.

    Debian 4.0 uses X.Org.

    I presently have a "portable" ViewSonic 21 monitor plugged into one
    Debian box, which I have recently upgraded from Sarge to Etch, and now
    cannot get a higher resolution than 640x480. This is, of course, a
    ridiculous resolution for a 21" screen.

    Even trying other multiscan/multifrequency 17" and "dumb" 15" monitors
    will not allow any resolution change.

    To make matters worse, the detected Trident video card causes a failure
    when xorg tries to initialize a screen.

    Of course the TTY terminals all work, so I do have access to vi for
    xorg.conf edits. The only method I've found to startx for a GUI DE is to
    manually edit xorg.conf and replace "trident" with "vesa" as the driver.

    Running "dpkg-reconfigure -phigh xorg-server" will only rebuild
    xorg.conf back to the detected trident driver.

    The monitor frequency rates also makes no difference if I edit xorg.conf
    and change them to the correct values for the monitor.

    The Trident video card has sufficient memory, and is used in eleven
    other identical PCs which run Debian Sarge fine under XFree86. However
    Sarge support is ending so I must upgrade to Etch as time permits.

    Below is the total /var/log/Xorg.0.log for examination (the font
    problems are of no concern).

    Perhaps someone has an idea that I might try? The xorg.conf can also be
    posted if requested.

    These Debian servers all run headless anyway, but at this point in time,
    I'd certainly like to find and resolve this X.Org resolution problem.

    TIA.


    X Window System Version 7.1.1
    Release Date: 12 May 2006
    X Protocol Version 11, Revision 0, Release 7.1.1
    Build Operating System: UNKNOWN
    Current Operating System: Linux optima12 2.6.18-4-486 #1 Mon Mar 26
    16:39:10 UTC 2007 i586
    Build Date: 24 January 2008
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
    Module Loader present
    Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 1 01:42:25 2008
    (==) Using config file: "/etc/X11/xorg.conf"
    (==) ServerLayout "Default Layout"
    (**) |-->Screen "Default Screen" (0)
    (**) | |-->Monitor "Generic Monitor"
    (**) | |-->Device "Trident Microsystems TGUI 9660/938x/968x"
    (**) |-->Input Device "Generic Keyboard"
    (**) |-->Input Device "Configured Mouse"
    (WW) The directory "/usr/X11R6/lib/X11/fonts/misc" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi/" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi/" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/Type1" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi" does not exist.
    Entry deleted from font path.
    (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi" does not exist.
    Entry deleted from font path.
    (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    does not exist.
    Entry deleted from font path.
    (**) FontPath set to:
    /usr/share/fonts/X11/misc,
    /usr/share/fonts/X11/100dpi/:unscaled,
    /usr/share/fonts/X11/75dpi/:unscaled,
    /usr/share/fonts/X11/Type1,
    /usr/share/fonts/X11/100dpi,
    /usr/share/fonts/X11/75dpi
    (==) RgbPath set to "/etc/X11/rgb"
    (==) ModulePath set to "/usr/lib/xorg/modules"
    (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
    (II) No APM support in BIOS or kernel
    (II) Module ABI versions:
    X.Org ANSI C Emulation: 0.3
    X.Org Video Driver: 1.0
    X.Org XInput driver : 0.6
    X.Org Server Extension : 0.3
    X.Org Font Renderer : 0.5
    (II) Loader running on linux
    (II) LoadModule: "bitmap"
    (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so
    (II) Module bitmap: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    Module class: X.Org Font Renderer
    ABI class: X.Org Font Renderer, version 0.5
    (II) Loading font Bitmap
    (II) LoadModule: "pcidata"
    (II) Loading /usr/lib/xorg/modules/libpcidata.so
    (II) Module pcidata: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.0
    (++) using VT number 7

    (II) PCI: PCI scan (all values are in hex)
    (II) PCI: 00:00:0: chip 8086,7100 card 0000,0000 rev 01 class 06,00,00
    hdr 00
    (II) PCI: 00:07:0: chip 8086,7110 card 0000,0000 rev 01 class 06,01,00
    hdr 80
    (II) PCI: 00:07:1: chip 8086,7111 card 0000,0000 rev 01 class 01,01,80
    hdr 00
    (II) PCI: 00:07:2: chip 8086,7112 card 0000,0000 rev 01 class 0c,03,00
    hdr 00
    (II) PCI: 00:07:3: chip 8086,7113 card 0000,0000 rev 01 class 06,80,00
    hdr 00
    (II) PCI: 00:08:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00
    hdr 00
    (II) PCI: 00:09:0: chip 10ec,8139 card a0a0,0027 rev 10 class 02,00,00
    hdr 00
    (II) PCI: 00:0a:0: chip 1023,9660 card 0000,0000 rev d3 class 03,00,00
    hdr 00
    (II) PCI: End of PCI scan
    (II) Host-to-PCI bridge:
    (II) Bus 0: bridge is at (0:0:0), (0,0,0), BCTRL: 0x0008 (VGA_EN is set)
    (II) Bus 0 I/O range:
    [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
    (II) Bus 0 non-prefetchable memory range:
    [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
    (II) Bus 0 prefetchable memory range:
    [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
    (II) PCI-to-ISA bridge:
    (II) Bus -1: bridge is at (0:7:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
    (--) PCI:*(0:10:0) Trident Microsystems TGUI 9660/938x/968x rev 211, Mem
    @ 0xff800000/22, 0xffef0000/16, BIOS @ 0xffee0000/16
    (II) Addressable bus resource ranges are
    [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
    [1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
    (II) OS-reported resource ranges:
    [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
    [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
    [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
    [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
    [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
    (II) Active PCI resource ranges:
    [0] -1 0 0xffedf800 - 0xffedf8ff (0x100) MX[B]
    [1] -1 0 0xffee0000 - 0xffeeffff (0x10000) MX[B](B)
    [2] -1 0 0xffef0000 - 0xffefffff (0x10000) MX[B](B)
    [3] -1 0 0xff800000 - 0xffbfffff (0x400000) MX[B](B)
    [4] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
    [5] -1 0 0x0000d000 - 0x0000d03f (0x40) IX[B]
    [6] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
    (II) Inactive PCI resource ranges:
    [0] -1 0 0x00004000 - 0x0000401f (0x20) IX[B]
    (II) Active PCI resource ranges after removing overlaps:
    [0] -1 0 0xffedf800 - 0xffedf8ff (0x100) MX[B]
    [1] -1 0 0xffee0000 - 0xffeeffff (0x10000) MX[B](B)
    [2] -1 0 0xffef0000 - 0xffefffff (0x10000) MX[B](B)
    [3] -1 0 0xff800000 - 0xffbfffff (0x400000) MX[B](B)
    [4] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
    [5] -1 0 0x0000d000 - 0x0000d03f (0x40) IX[B]
    [6] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
    (II) Inactive PCI resource ranges after removing overlaps:
    [0] -1 0 0x00004000 - 0x0000401f (0x20) IX[B]
    (II) OS-reported resource ranges after removing overlaps with PCI:
    [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
    [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
    [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
    [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
    [5] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
    (II) All system resource ranges:
    [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
    [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
    [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
    [4] -1 0 0xffedf800 - 0xffedf8ff (0x100) MX[B]
    [5] -1 0 0xffee0000 - 0xffeeffff (0x10000) MX[B](B)
    [6] -1 0 0xffef0000 - 0xffefffff (0x10000) MX[B](B)
    [7] -1 0 0xff800000 - 0xffbfffff (0x400000) MX[B](B)
    [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
    [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
    [10] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
    [11] -1 0 0x0000d000 - 0x0000d03f (0x40) IX[B]
    [12] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
    [13] -1 0 0x00004000 - 0x0000401f (0x20) IX[B]
    (II) LoadModule: "i2c"
    (II) Loading /usr/lib/xorg/modules/libi2c.so
    (II) Module i2c: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.2.0
    ABI class: X.Org Video Driver, version 1.0
    (II) LoadModule: "bitmap"
    (II) Reloading /usr/lib/xorg/modules/fonts/libbitmap.so
    (II) Loading font Bitmap
    (II) LoadModule: "ddc"
    (II) Loading /usr/lib/xorg/modules/libddc.so
    (II) Module ddc: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.0
    (II) LoadModule: "dri"
    (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
    (II) Module dri: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Server Extension, version 0.3
    (II) Loading sub module "drm"
    (II) LoadModule: "drm"
    (II) Loading /usr/lib/xorg/modules/linux/libdrm.so
    (II) Module drm: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Server Extension, version 0.3
    (II) Loading extension XFree86-DRI
    (II) LoadModule: "extmod"
    (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
    (II) Module extmod: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    Module class: X.Org Server Extension
    ABI class: X.Org Server Extension, version 0.3
    (II) Loading extension SHAPE
    (II) Loading extension MIT-SUNDRY-NONSTANDARD
    (II) Loading extension BIG-REQUESTS
    (II) Loading extension SYNC
    (II) Loading extension MIT-SCREEN-SAVER
    (II) Loading extension XC-MISC
    (II) Loading extension XFree86-VidModeExtension
    (II) Loading extension XFree86-Misc
    (II) Loading extension XFree86-DGA
    (II) Loading extension DPMS
    (II) Loading extension TOG-CUP
    (II) Loading extension Extended-Visual-Information
    (II) Loading extension XVideo
    (II) Loading extension XVideo-MotionCompensation
    (II) Loading extension X-Resource
    (II) LoadModule: "freetype"
    (II) Loading /usr/lib/xorg/modules/fonts/libfreetype.so
    (II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
    compiled for 7.1.1, module version = 2.1.0
    Module class: X.Org Font Renderer
    ABI class: X.Org Font Renderer, version 0.5
    (II) Loading font FreeType
    (II) LoadModule: "glx"
    (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
    (II) Module glx: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Server Extension, version 0.3
    (==) AIGLX enabled
    (II) Loading extension GLX
    (II) LoadModule: "int10"
    (II) Loading /usr/lib/xorg/modules/libint10.so
    (II) Module int10: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.0
    (II) LoadModule: "vbe"
    (II) Loading /usr/lib/xorg/modules/libvbe.so
    (II) Module vbe: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.1.0
    ABI class: X.Org Video Driver, version 1.0
    (II) LoadModule: "trident"
    (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so
    (II) Module trident: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.2.3
    Module class: X.Org Video Driver
    ABI class: X.Org Video Driver, version 1.0
    (II) LoadModule: "kbd"
    (II) Loading /usr/lib/xorg/modules/input/kbd_drv.so
    (II) Module kbd: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.1.0
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.6
    (II) LoadModule: "mouse"
    (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so
    (II) Module mouse: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.1.1
    Module class: X.Org XInput Driver
    ABI class: X.Org XInput driver, version 0.6
    (II) TRIDENT: driver for Trident chipsets: tvga9000, tvga9000i, tvga8900c,
    tvga8900d, tvga9200cxr, tgui9400cxi, cyber9320, cyber9388, cyber9397,
    cyber9397dvd, cyber9520, cyber9525dvd, cyberblade/e4, tgui9420dgi,
    tgui9440agi, tgui9660, tgui9680, providia9682, providia9685,
    cyber9382, cyber9385, 3dimage975, 3dimage985, blade3d, cyberbladei7,
    cyberbladei7d, cyberbladei1, cyberbladei1d, cyberbladeAi1,
    cyberbladeAi1d, bladeXP, cyberbladeXPAi1, cyberbladeXP4, XP5
    (II) Primary Device is: PCI 00:0a:0
    (--) Chipset tgui9660 found
    (II) resource ranges after xf86ClaimFixedResources() call:
    [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
    [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
    [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
    [4] -1 0 0xffedf800 - 0xffedf8ff (0x100) MX[B]
    [5] -1 0 0xffee0000 - 0xffeeffff (0x10000) MX[B](B)
    [6] -1 0 0xffef0000 - 0xffefffff (0x10000) MX[B](B)
    [7] -1 0 0xff800000 - 0xffbfffff (0x400000) MX[B](B)
    [8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
    [9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
    [10] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
    [11] -1 0 0x0000d000 - 0x0000d03f (0x40) IX[B]
    [12] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
    [13] -1 0 0x00004000 - 0x0000401f (0x20) IX[B]
    (II) resource ranges after probing:
    [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
    [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
    [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
    [4] -1 0 0xffedf800 - 0xffedf8ff (0x100) MX[B]
    [5] -1 0 0xffee0000 - 0xffeeffff (0x10000) MX[B](B)
    [6] -1 0 0xffef0000 - 0xffefffff (0x10000) MX[B](B)
    [7] -1 0 0xff800000 - 0xffbfffff (0x400000) MX[B](B)
    [8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
    [9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
    [10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
    [11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
    [12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
    [13] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
    [14] -1 0 0x0000d000 - 0x0000d03f (0x40) IX[B]
    [15] -1 0 0x0000ffa0 - 0x0000ffaf (0x10) IX[B]
    [16] -1 0 0x00004000 - 0x0000401f (0x20) IX[B]
    [17] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
    [18] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
    (II) Setting vga for screen 0.
    (**) TRIDENT(0): Depth 24, (--) framebuffer bpp 32
    (II) Loading sub module "vgahw"
    (II) LoadModule: "vgahw"
    (II) Loading /usr/lib/xorg/modules/libvgahw.so
    (II) Module vgahw: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 0.1.0
    ABI class: X.Org Video Driver, version 1.0
    (II) TRIDENT(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
    is 0x0000
    (II) Loading sub module "ramdac"
    (II) LoadModule: "ramdac"
    (II) Loading /usr/lib/xorg/modules/libramdac.so
    (II) Module ramdac: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 0.1.0
    ABI class: X.Org Video Driver, version 1.0
    (==) TRIDENT(0): RGB weight 888
    (==) TRIDENT(0): Default visual is TrueColor
    (==) TRIDENT(0): Using gamma correction (1.0, 1.0, 1.0)
    (==) TRIDENT(0): Using XAA for acceleration
    (==) TRIDENT(0): Linear framebuffer at 0xFF800000
    (--) TRIDENT(0): IO registers at 0xFFEF0000
    (II) Loading sub module "vbe"
    (II) LoadModule: "vbe"
    (II) Reloading /usr/lib/xorg/modules/libvbe.so
    (II) Loading sub module "int10"
    (II) LoadModule: "int10"
    (II) Reloading /usr/lib/xorg/modules/libint10.so
    (II) TRIDENT(0): initializing int10
    (II) Loading sub module "vm86"
    (II) LoadModule: "vm86"
    (II) Loading /usr/lib/xorg/modules/libvm86.so
    (II) Module vm86: vendor="X.Org Foundation"
    compiled for 7.1.1, module version = 1.0.0
    ABI class: X.Org Video Driver, version 1.0
    (II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
    (WW) System lacks support for changing MTRRs
    (II) TRIDENT(0): VESA BIOS detected
    (II) TRIDENT(0): VESA VBE Version 1.2
    (II) TRIDENT(0): VESA VBE Total Mem: 1024 kB
    (II) TRIDENT(0): VESA VBE OEM: Trident TGUI96xx
    (--) TRIDENT(0): Revision is 1
    (--) TRIDENT(0): Found TGUI9680 chip
    (--) TRIDENT(0): RAM type is EDO Ram
    (--) TRIDENT(0): Using HW cursor
    (--) TRIDENT(0): VideoRAM: 1024 kByte
    (--) TRIDENT(0): Memory Clock is 42.95 MHz
    (==) TRIDENT(0): Min pixel clock is 12 MHz
    (--) TRIDENT(0): Max pixel clock is 40 MHz
    (II) TRIDENT(0): Generic Monitor: Using hsync range of 28.00-80.00 kHz
    (II) TRIDENT(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
    (II) TRIDENT(0): Clock range: 12.00 to 40.00 MHz
    (II) TRIDENT(0): Not using default mode "640x350" (vrefresh out of range)
    (II) TRIDENT(0): Not using default mode "320x175" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "640x400" (vrefresh out of range)
    (II) TRIDENT(0): Not using default mode "320x200" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "720x400" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "360x200" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "320x240" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "320x240" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "320x240" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "320x240" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "400x300" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "400x300" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "400x300" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "400x300" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "400x300" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "512x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "512x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "512x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "512x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "512x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1152x864" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "576x432" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1280x960" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1280x960" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x480" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1280x1024" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x512" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1280x1024" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x512" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1280x1024" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x512" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1792x1344" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "896x672" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1792x1344" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "896x672" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1856x1392" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "928x696" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1856x1392" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "928x696" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1920x1440" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "960x720" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1920x1440" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "960x720" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "832x624" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "416x312" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1280x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1280x800" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "640x400" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1152x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "576x384" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1152x864" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "576x432" (bad mode
    clock/interlace/doublescan)
    (II) TRIDENT(0): Not using default mode "1400x1050" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "700x525" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1400x1050" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "700x525" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1400x1050" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "700x525" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1400x1050" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "700x525" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1440x900" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "720x450" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1600x1024" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "800x512" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1680x1050" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "840x525" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1920x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "960x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1920x1200" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "960x600" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1920x1440" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "960x720" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "2048x1536" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "2048x1536" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "2048x1536" (insufficient memory
    for mode)
    (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    for mode)
    (WW) TRIDENT(0): Mode pool is empty
    (EE) TRIDENT(0): No valid modes found
    (II) UnloadModule: "trident"
    (II) UnloadModule: "vm86"
    (II) Unloading /usr/lib/xorg/modules/libvm86.so
    (II) UnloadModule: "int10"
    (II) UnloadModule: "vbe"
    (II) UnloadModule: "ramdac"
    (II) Unloading /usr/lib/xorg/modules/libramdac.so
    (II) UnloadModule: "vgahw"
    (II) Unloading /usr/lib/xorg/modules/libvgahw.so
    (EE) Screen(s) found, but none have a usable configuration.

    Fatal server error:
    no screens found


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  2. Re: X.Org vs XFree86

    On 04/03/2008 06:45 PM, John F. Morse wrote:
    > Most of my GNU/Linux installations use Debian 3.1, with older Ubuntu,
    > Fedora Core, Lindows, Mandrake, Red Hat, Slackware, etc. IIRC, these all
    > use XFree86, and I had to learn to fine-tune it over the years.
    >
    > Debian 4.0 uses X.Org.
    >
    > I presently have a "portable" ViewSonic 21 monitor plugged into one
    > Debian box, which I have recently upgraded from Sarge to Etch, and now
    > cannot get a higher resolution than 640x480. This is, of course, a
    > ridiculous resolution for a 21" screen.
    >
    > Even trying other multiscan/multifrequency 17" and "dumb" 15" monitors
    > will not allow any resolution change.
    >
    > To make matters worse, the detected Trident video card causes a failure
    > when xorg tries to initialize a screen.
    >
    > Of course the TTY terminals all work, so I do have access to vi for
    > xorg.conf edits. The only method I've found to startx for a GUI DE is to
    > manually edit xorg.conf and replace "trident" with "vesa" as the driver.
    >
    > Running "dpkg-reconfigure -phigh xorg-server" will only rebuild
    > xorg.conf back to the detected trident driver.
    >


    Try this instead:
    dpkg-reconfigure -plow xserver-xorg

    > The monitor frequency rates also makes no difference if I edit xorg.conf
    > and change them to the correct values for the monitor.
    >


    Well that confuses me, since that was going to be my first suggestion of
    something to look into.

    > The Trident video card has sufficient memory, and is used in eleven
    > other identical PCs which run Debian Sarge fine under XFree86. However
    > Sarge support is ending so I must upgrade to Etch as time permits.
    >
    > Below is the total /var/log/Xorg.0.log for examination (the font
    > problems are of no concern).
    >
    > Perhaps someone has an idea that I might try? The xorg.conf can also be
    > posted if requested.
    >
    > These Debian servers all run headless anyway, but at this point in time,
    > I'd certainly like to find and resolve this X.Org resolution problem.
    >
    > TIA.
    > [...]
    >


    Xorg reports 1024KiB of memory for your card--is this true?

    Try to disable direct rendering for right now. You probably don't need
    DRI on a server anyway.

    Also, try to use a lower color depth; you're using 24 bits right now;
    perhaps you need to change that to 16.

  3. Re: X.Org vs XFree86


    Hi there,

    I checked your logfile. First of all for a resolution with 800x600 by
    24bit you need at last 1.4MB video memory. You can go down to 16bpp
    which will give you a resolution of 800x600 pixel.

    Another thing could you also send to here your xorg.conf file? That
    would help to find the problem. Because it seems as if you have alot of
    modelines configured. In xorg you shouldn't need anymore modelines, the
    only thing you have to do is tell the server the frequencies of your
    monitor and thats it.

    Another thing is that the pixel clock can limitate your screen
    resolution.

    > (==) TRIDENT(0): Min pixel clock is 12 MHz
    > (--) TRIDENT(0): Max pixel clock is 40 MHz
    > (II) TRIDENT(0): Generic Monitor: Using hsync range of 28.00-80.00 kHz
    > (II) TRIDENT(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
    > (II) TRIDENT(0): Clock range: 12.00 to 40.00 MHz


    Since 1024x786 by 60Hz makes around 48 MHz and the card only alows you to
    set it to 40MHz.

    bye bye,
    Steffen

    --
    Steffen Pohle (stpohle@gmx.net)
    http://stpohle.dyndns.org

    ***** Instant Messanger Contact ******
    * Skype: stpohle Yahoo: stpohle *
    * MSN: stpohle@hotmail.com *
    **************************************


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH9h2bj6xnrikWYrkRApSRAJ48YQxWxVRxvfFQN466tP/ZEDHdMQCfaUf1
    s0YjotrC5Ah3pspUH0pE3AQ=
    =IKUC
    -----END PGP SIGNATURE-----


  4. Re: X.Org vs XFree86

    Thus spake Steffen Pohle:

    > In xorg you shouldn't need anymore modelines, the only thing you have
    > to do is tell the server the frequencies of your monitor and thats it.



    Am I correct that LCD monitors don't use/require horizontal and vertical
    rates?

    --
    sk8r-365
    Take therefore the talent from him, and give it unto him which hath
    ten talents. -- Matthew 25:28

  5. Re: X.Org vs XFree86

    On Fri, 04 Apr 2008 18:58:40 -0500, sk8r-365 wrote:

    > Thus spake Steffen Pohle:
    >
    >> In xorg you shouldn't need anymore modelines, the only thing you have
    >> to do is tell the server the frequencies of your monitor and thats it.

    >
    >
    > Am I correct that LCD monitors don't use/require horizontal and vertical
    > rates?


    I don't think so. Both of my have those specs and if not written into
    xorg.conf the displays don't go to 1280x1024, except in Solaris.

  6. Re: X.Org vs XFree86

    Mumia W. wrote:
    > Try this instead:
    > dpkg-reconfigure -plow xserver-xorg



    Ah ha! That is the configure/reconfigure routine I remember in XFree86
    for Sarge.

    A few days ago after checking the man page, I took "high" priority to
    mean it would ask everything. It actually means the opposite.

    Thanks Mumia for making me try this "low" priority or I would have never
    discovered this!

    Of course these various responses can always be manually edited in
    xorg.conf just like they were in the XF86Config-4 file, but it was good
    to see the familiar monitor sync range settings.


    >> The monitor frequency rates also makes no difference if I edit
    >> xorg.conf and change them to the correct values for the monitor.

    >
    > Well that confuses me, since that was going to be my first suggestion
    > of something to look into.
    >
    >> The Trident video card has sufficient memory, and is used in eleven
    >> other identical PCs which run Debian Sarge fine under XFree86.
    >> However Sarge support is ending so I must upgrade to Etch as time
    >> permits.
    >>
    >> Below is the total /var/log/Xorg.0.log for examination (the font
    >> problems are of no concern).
    >>
    >> Perhaps someone has an idea that I might try? The xorg.conf can also
    >> be posted if requested.
    >>
    >> These Debian servers all run headless anyway, but at this point in
    >> time, I'd certainly like to find and resolve this X.Org resolution
    >> problem.
    >>

    >
    > Xorg reports 1024KiB of memory for your card--is this true?



    I can only go by the report. My old notes for this PC's video card also
    mention 1024k.

    However I did find that this is the only PC of the "identical" 13 I
    originally purchased that has a Trident chipset on the video card. All
    the others are ATI based, and seem to work fine (AFAIK). So my earlier
    statement is incorrect.

    If I can't make this Trident card work correctly, I could always swap it
    with an ATI card that is in the single Windows 98SE PC. I don't really
    need a GUI right now, but it is nice to have for some possible future use.


    > Try to disable direct rendering for right now. You probably don't need
    > DRI on a server anyway.
    >
    > Also, try to use a lower color depth; you're using 24 bits right now;
    > perhaps you need to change that to 16.



    Well, after trying your suggestions around 0400 this morning, nothing
    has changed. Tonight I'm going to reduce the bit depth like Steffen
    suggested and see if the problem is the video card's memory is too small.

    Here's how she's configured after last night's work (including the
    correct monitor info):


    john@optima12:/etc/X11$ cat xorg.conf
    # /etc/X11/xorg.conf (xorg X Window System server configuration file)
    #
    # This file was generated by dexconf, the Debian X Configuration tool, using
    # values from the debconf database.
    #
    # Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
    # (Type "man /etc/X11/xorg.conf" at the shell prompt.)
    #
    # This file is automatically updated on xserver-xorg package upgrades *only*
    # if it has not been modified since the last upgrade of the xserver-xorg
    # package.
    #
    # If you have edited this file but would like it to be automatically updated
    # again, run the following command:
    # sudo dpkg-reconfigure -phigh xserver-xorg

    Section "Files"
    FontPath "/usr/share/fonts/X11/misc"
    FontPath "/usr/X11R6/lib/X11/fonts/misc"
    FontPath "/usr/share/fonts/X11/cyrillic"
    FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"
    FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
    FontPath "/usr/share/fonts/X11/Type1"
    FontPath "/usr/X11R6/lib/X11/fonts/Type1"
    FontPath "/usr/share/fonts/X11/100dpi"
    FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
    FontPath "/usr/share/fonts/X11/75dpi"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
    # path to defoma fonts
    FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    EndSection

    Section "Module"
    Load "bitmap"
    Load "ddc"
    Load "extmod"
    Load "freetype"
    Load "glx"
    Load "int10"
    Load "vbe"
    EndSection

    Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc104"
    Option "XkbLayout" "us"
    EndSection

    Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/psaux"
    Option "Protocol" "ImPS/2"
    Option "Emulate3Buttons" "true"
    EndSection

    Section "Device"
    Identifier "Trident Microsystems TGUI 9660/938x/968x"
    Driver "trident"
    BusID "PCI:0:10:0"
    VideoRam 1024
    EndSection

    Section "Monitor"
    Identifier "ViewSonic 21"
    Option "DPMS"
    HorizSync 30-82
    VertRefresh 50-150
    EndSection

    Section "Screen"
    Identifier "Default Screen"
    Device "Trident Microsystems TGUI 9660/938x/968x"
    Monitor "ViewSonic 21"
    DefaultDepth 16
    SubSection "Display"
    Depth 1
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 4
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 8
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 15
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 16
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 24
    Modes "1280x1024" "1024x768" "800x600" "640x480"
    EndSubSection
    EndSection

    Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen"
    InputDevice "Generic Keyboard"
    InputDevice "Configured Mouse"
    EndSection

    Section "DRI"
    Mode 0666
    EndSection
    john@optima12:/etc/X11$


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  7. Re: X.Org vs XFree86

    Thus spake Dave Uhring:
    > On Fri, 04 Apr 2008 18:58:40 -0500, sk8r-365 wrote:
    >
    >> Thus spake Steffen Pohle:
    >>
    >>> In xorg you shouldn't need anymore modelines, the only thing you have
    >>> to do is tell the server the frequencies of your monitor and thats it.

    >>
    >>
    >> Am I correct that LCD monitors don't use/require horizontal and vertical
    >> rates?

    >
    > I don't think so. Both of my have those specs and if not written into
    > xorg.conf the displays don't go to 1280x1024, except in Solaris.


    Hmm, I ask because it makes no difference on my setup. At least I can't
    detect any benefit or harm as it is. Appears to work fine as is
    currently edited:

    Section "Monitor"
    Identifier "Generic Monitor"
    Option "DPMS"
    #HorizSync 28-84
    #VertRefresh 43-60

    The monitor in use is a Samsung SyncMaster 205bw. What do you think?

    --
    sk8r-365
    And saying, We have piped unto you, and ye have not danced; we have
    mourned unto you, and ye have not lamented. -- Matthew 11:17

  8. Re: X.Org vs XFree86

    sk8r-365 wrote:
    > Thus spake Dave Uhring:
    >
    >> On Fri, 04 Apr 2008 18:58:40 -0500, sk8r-365 wrote:
    >>
    >>
    >>> Thus spake Steffen Pohle:
    >>>
    >>>
    >>>> In xorg you shouldn't need anymore modelines, the only thing you have
    >>>> to do is tell the server the frequencies of your monitor and thats it.
    >>>>
    >>>
    >>>
    >>> Am I correct that LCD monitors don't use/require horizontal and vertical
    >>> rates?
    >>>

    >> I don't think so. Both of my have those specs and if not written into
    >> xorg.conf the displays don't go to 1280x1024, except in Solaris.
    >>

    >
    > Hmm, I ask because it makes no difference on my setup. At least I can't
    > detect any benefit or harm as it is. Appears to work fine as is
    > currently edited:
    >
    > Section "Monitor"
    > Identifier "Generic Monitor"
    > Option "DPMS"
    > #HorizSync 28-84
    > #VertRefresh 43-60
    >
    > The monitor in use is a Samsung SyncMaster 205bw. What do you think?



    I bought a Samsung SyncMaster 931B "19") and replaced the ViewSonic A75f
    (17"), which is now on another couple of PCs through a KVM.

    I have never changed the xorg.conf though, and the SyncMaster is running
    fine.

    Here is the old but still being used xorg.conf monitor section:

    Section "Monitor"
    Identifier "A75f"
    Option "DPMS"
    HorizSync 30-70
    VertRefresh 50-160

    You probably have an "Auto" button like mine on the bottom edge of the
    monitor bezel. When it is pushed the monitor seems to know what is best.

    Of course it makes me wonder if the signal is not really optimal, could
    it be improved so the monitor doesn't need to (possibly) distort it?


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  9. Re: X.Org vs XFree86

    Steffen Pohle wrote:
    > Hi there,
    >
    > I checked your logfile. First of all for a resolution with 800x600 by
    > 24bit you need at last 1.4MB video memory. You can go down to 16bpp
    > which will give you a resolution of 800x600 pixel.
    >
    > Another thing could you also send to here your xorg.conf file? That
    > would help to find the problem. Because it seems as if you have alot of
    > modelines configured. In xorg you shouldn't need anymore modelines, the
    > only thing you have to do is tell the server the frequencies of your
    > monitor and thats it.
    >
    > Another thing is that the pixel clock can limitate your screen
    > resolution.
    >
    >
    >> (==) TRIDENT(0): Min pixel clock is 12 MHz
    >> (--) TRIDENT(0): Max pixel clock is 40 MHz
    >> (II) TRIDENT(0): Generic Monitor: Using hsync range of 28.00-80.00 kHz
    >> (II) TRIDENT(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
    >> (II) TRIDENT(0): Clock range: 12.00 to 40.00 MHz
    >>

    >
    > Since 1024x786 by 60Hz makes around 48 MHz and the card only alows you to
    > set it to 40MHz.
    >
    > bye bye,
    > Steffen



    Thanks, Steffen. Your idea was the solution!

    I decided to get to work early tonight....

    First I tried a depth of four bits, but it was rejected by
    dpkg-reconfigure as not available for my video card.

    So I tried eight bits and it is now working at 800x600. The 16bpp needs
    960 kB, so it should also work.

    My calculations also indicate that 1024x768 at 8bpp will work (786,432
    Bytes required). Do you agree (is my math correct)?

    Also, now with the real monitor sync range, is the pixel clock still a
    concern?

    Here is the newly-generated xorg.conf with only eight bits selected for
    the depth.


    john@optima12:/etc/X11$ cat xorg.conf
    # /etc/X11/xorg.conf (xorg X Window System server configuration file)
    #
    # This file was generated by dexconf, the Debian X Configuration tool, using
    # values from the debconf database.
    #
    # Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
    # (Type "man /etc/X11/xorg.conf" at the shell prompt.)
    #
    # This file is automatically updated on xserver-xorg package upgrades *only*
    # if it has not been modified since the last upgrade of the xserver-xorg
    # package.
    #
    # If you have edited this file but would like it to be automatically updated
    # again, run the following command:
    # sudo dpkg-reconfigure -phigh xserver-xorg

    Section "Files"
    FontPath "/usr/share/fonts/X11/misc"
    FontPath "/usr/X11R6/lib/X11/fonts/misc"
    FontPath "/usr/share/fonts/X11/cyrillic"
    FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"
    FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
    FontPath "/usr/share/fonts/X11/Type1"
    FontPath "/usr/X11R6/lib/X11/fonts/Type1"
    FontPath "/usr/share/fonts/X11/100dpi"
    FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
    FontPath "/usr/share/fonts/X11/75dpi"
    FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
    # path to defoma fonts
    FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    EndSection

    Section "Module"
    Load "bitmap"
    Load "ddc"
    Load "extmod"
    Load "freetype"
    Load "glx"
    Load "int10"
    Load "vbe"
    EndSection

    Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc104"
    Option "XkbLayout" "us"
    EndSection

    Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/psaux"
    Option "Protocol" "ImPS/2"
    Option "Emulate3Buttons" "true"
    EndSection

    Section "Device"
    Identifier "Trident Microsystems TGUI 9660/938x/968x"
    Driver "trident"
    BusID "PCI:0:10:0"
    EndSection

    Section "Monitor"
    Identifier "ViewSonic 21"
    Option "DPMS"
    HorizSync 30-82
    VertRefresh 50-150
    EndSection

    Section "Screen"
    Identifier "Default Screen"
    Device "Trident Microsystems TGUI 9660/938x/968x"
    Monitor "ViewSonic 21"
    DefaultDepth 8
    SubSection "Display"
    Depth 1
    Modes "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 4
    Modes "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 8
    Modes "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 15
    Modes "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 16
    Modes "800x600" "640x480"
    EndSubSection
    SubSection "Display"
    Depth 24
    Modes "800x600" "640x480"
    EndSubSection
    EndSection

    Section "ServerLayout"
    Identifier "Default Layout"
    Screen "Default Screen"
    InputDevice "Generic Keyboard"
    InputDevice "Configured Mouse"
    EndSection

    Section "DRI"
    Mode 0666
    EndSection



    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  10. Re: X.Org vs XFree86

    On Sat, 05 Apr 2008 01:16:16 +0000, John F. Morse wrote:

    > I bought a Samsung SyncMaster 931B "19") and replaced the ViewSonic A75f
    > (17"), which is now on another couple of PCs through a KVM.
    >
    > I have never changed the xorg.conf though, and the SyncMaster is running
    > fine.
    >
    > Here is the old but still being used xorg.conf monitor section:
    >
    > Section "Monitor"
    > Identifier "A75f"
    > Option "DPMS"
    > HorizSync 30-70
    > VertRefresh 50-160


    You are probably running at less than optimum refresh rate. Put the
    numbers from Samsung's own site in there:

    http://www.samsung.com/cp/products/m...9mebsbdxaa.asp

    I didn't bother searching further for an English language site but that one
    has numbers you can see.


  11. Re: X.Org vs XFree86

    Thus spake John F. Morse:

    > I bought a Samsung SyncMaster 931B "19") and replaced the ViewSonic A75f
    > (17"), which is now on another couple of PCs through a KVM.
    >
    > I have never changed the xorg.conf though, and the SyncMaster is running
    > fine.
    >
    > Here is the old but still being used xorg.conf monitor section:
    >
    > Section "Monitor"
    > Identifier "A75f"
    > Option "DPMS"
    > HorizSync 30-70
    > VertRefresh 50-160
    >
    > You probably have an "Auto" button like mine on the bottom edge of the
    > monitor bezel. When it is pushed the monitor seems to know what is best.
    >
    > Of course it makes me wonder if the signal is not really optimal, could
    > it be improved so the monitor doesn't need to (possibly) distort it?
    >


    I do have that "auto" buton, but when depressed a message reads, "Auto
    Adjustment Not Available". Go figure. Just for the heck of it I
    uncommented the HSync and VRefesh digits, then restarted X ... nothing
    of note. Hmmm? I *guess* for LCD's it's not important.

    --
    sk8r-365
    And all the people were amazed, and said, Is not this the son of
    David? -- Matthew 12:23

  12. Re: X.Org vs XFree86

    sk8r-365 wrote:
    > Thus spake John F. Morse:
    >
    >
    >> I bought a Samsung SyncMaster 931B "19") and replaced the ViewSonic A75f
    >> (17"), which is now on another couple of PCs through a KVM.
    >>
    >> I have never changed the xorg.conf though, and the SyncMaster is running
    >> fine.
    >>
    >> Here is the old but still being used xorg.conf monitor section:
    >>
    >> Section "Monitor"
    >> Identifier "A75f"
    >> Option "DPMS"
    >> HorizSync 30-70
    >> VertRefresh 50-160
    >>
    >> You probably have an "Auto" button like mine on the bottom edge of the
    >> monitor bezel. When it is pushed the monitor seems to know what is best.
    >>
    >> Of course it makes me wonder if the signal is not really optimal, could
    >> it be improved so the monitor doesn't need to (possibly) distort it?
    >>
    >>

    >
    > I do have that "auto" buton, but when depressed a message reads, "Auto
    > Adjustment Not Available". Go figure. Just for the heck of it I
    > uncommented the HSync and VRefesh digits, then restarted X ... nothing
    > of note. Hmmm? I *guess* for LCD's it's not important.



    I don't know if it matters, but I'm using the analog (HDDB-15)
    interface, and not the digital interface.

    If the digital interface was being used, there is a possibility the
    monitor may be controlled by the video card, kind of like a HDMI cable
    can support between a TV and a home theater.

    I'll have to reconfigure my xorg.conf someday when I need to reboot.


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  13. Re: X.Org vs XFree86

    Dave Uhring wrote:
    > On Sat, 05 Apr 2008 01:16:16 +0000, John F. Morse wrote:
    >
    >
    >> I bought a Samsung SyncMaster 931B "19") and replaced the ViewSonic A75f
    >> (17"), which is now on another couple of PCs through a KVM.
    >>
    >> I have never changed the xorg.conf though, and the SyncMaster is running
    >> fine.
    >>
    >> Here is the old but still being used xorg.conf monitor section:
    >>
    >> Section "Monitor"
    >> Identifier "A75f"
    >> Option "DPMS"
    >> HorizSync 30-70
    >> VertRefresh 50-160
    >>

    >
    > You are probably running at less than optimum refresh rate. Put the
    > numbers from Samsung's own site in there:
    >
    > http://www.samsung.com/cp/products/m...9mebsbdxaa.asp
    >
    > I didn't bother searching further for an English language site but that one
    > has numbers you can see.



    Thanks, Dave.

    I see the info:

    Le Samsung SyncMaster 931b est un moniteur ACL TFT analogique et
    numérique de 19 po qui offre un rapport de contraste de 700:1, une
    luminosité de 300cd/m2, une résolution de 1280 x 1024, un angle de
    visionnement de 160/160 et une fréquence de balayage horizontal de 30-81
    KHz et vertical de 56-75 Hz avec un temps de réponse rapide de 8 ms. Il
    comprend les fonctions MagicTune, MagicBright II et MagicColor, ainsi
    qu'un bloc d'alimentation intégré.

    I know no French, but like you said, the numbers all speak for
    themselves. ;-)

    Evidentially a linked server with all the images is down right now, or
    the site is unkempt, so I couldn't see whatever else is on that page. I
    did some snooping and found this:

    http://www.samsung.com/cp/support/pr...vedmonitor.sec

    or http://tinyurl.com/44to3x

    which has a PDF that is in English for my model.

    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  14. Re: X.Org vs XFree86

    Thus spake John F. Morse:


    > http://www.samsung.com/cp/support/pr...ad/FileView.as
    > px?cttfileid=876633&type=Monitor&typecode=&subtype=Archived+Monitor&
    > subtypecode=&cmssubtypecode=&model=931B&filetype=UM&language=&LSSI=/cp/
    > module/ssi/left/lmenu_monitor_archivedmonitor.sec&RSSI=/cp/module/ssi/
    > right/rmenu_archivedmonitor.sec



    Sir, I dunno if you are aware of a *long* standing USENET protocol,
    therefore please allow me to bring it to light: at no time is a line of
    text to exceed 80 characters, but preferably keep it to 72. The line
    above was 312 (I manually wrapped it). Even while using a wide screen
    monitor reading that line is unnecessarily long to view and of no
    reading value.

    http://www.cs.tut.fi/~jkorpela/usenet/dont.html

    #2 (in part)

    "Plain text means it's text only, with line length under 80 (preferably
    under 72) characters; it doesn't mean boring or careless text. Use good
    writing style."

    > or http://tinyurl.com/44to3x


    Having supplied a tinyurl is perfectly correct, readable and useful. If
    you will do that _alone_ in the future, people will be grateful.

    Here's a useful source on the topic:
    http://www.google.com/Top/Computers/Usenet/Etiquette/

    Regards,
    --
    sk8r-365
    So the last shall be first, and the first last: for many be called,
    but few chosen. -- Matthew 20:16

  15. Re: X.Org vs XFree86

    Thus spake John F. Morse:
    > -- John
    >
    > No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used
    > in the preparation or transmission of this message.
    >
    > The EULA sounds like it was written by a team of lawyers who want to
    > tell me what I can't do. The GPL sounds like it was written by a human
    > being, who wants me to know what I can do.


    The above message is correct, IMO, but ... while I'm at it - and I'm not
    wanting to offend - it needs to be mentioned your sig file is _too_
    l-o-n-g and should be no more than the accepted 4 lines, less is OK,
    when properly wrapped (I wrapped it). Please.

    http://www.faqs.org/faqs/usenet/posting-rules/part1/

    " Please keep your signatures concise, as people do not appreciate
    seeing lengthy signatures, nor paying the phone bills to repeatedly
    transmit them. 2 or 3 lines are usually plenty. Sometimes it is also
    appropriate to add another line or two for addresses on other major
    networks where you can be reached (e.g., CompuServ, Bitnet). Long
    signatures are definitely frowned upon. DO NOT include drawings,
    pictures, maps, or other graphics in your signature -- it is not the
    appropriate place for such material and is viewed as rude by other
    readers."

    Thank you,
    --
    sk8r-365
    So the last shall be first, and the first last: for many be called,
    but few chosen. -- Matthew 20:16

  16. Re: X.Org vs XFree86

    sk8r-365 wrote:

    > Sir, I dunno if you are aware of a *long* standing USENET protocol,
    > therefore please allow me to bring it to light: at no time is a line of
    > text to exceed 80 characters, but preferably keep it to 72. The line
    > above was 312 (I manually wrapped it). Even while using a wide screen
    > monitor reading that line is unnecessarily long to view and of no
    > reading value.
    >



    I'm aware of everything, including the widespread proliferation of net
    nannys. I've used USENET for many years and have run my own NNTP news
    servers since 2000, with BBSes since 1990.

    But don't pop a cork yet! Let me explain a few of my feelings.

    I provided a URL, and it was meant to be clicked -- not read. You are
    absolutely correct stating it has no reading value. You could click it
    on the left end and it would have worked.

    I don't wrap text on this end because I have no way of knowing how it
    will appear to all of the various newsreaders. If I would have broken
    the URL, it would have been, well, broken for everybody. I provided the
    TinyURL knowing many people would wrap and break the URL.

    If a reader prefers text wrapped to a certain length, then they
    certainly are free to do it. I can't format it here or some of the
    people will always object. I provide text, and those who are reading
    provide formatting in whatever way they desire.

    If you believe I should format it, then HTML would be the better option.
    I'm sure that is not desired. ;-)

    You use slrn. That is your choice, but it, and many readers similar to
    it, are from and designed for the past, as you stated ("*long* standing
    USENET protocol").

    IOW, don't try and make everyone on the Interstate Highway System ride
    horses and pull wagons. Time marches on, and only those who refuse to
    use what is modern will be left in the dust, hollering and screaming at
    those who have better things to do and places to go. Or they will be run
    over!

    I use many Unix newsreaders, including slrn, Pan, KNode, Sylpheed-Claws,
    KLibido, emacs+Gnus, Mozilla and Thunderbird/Icedove. I prefer
    Thunderbird/Icedove because I also use it for e-mail, and have years of
    archives in the Mozilla-style format for instant reference. I've used
    many other news clients under Windows (Agent, Xnews, Gravity, OE )
    and several on the Mac OS for some 22 years, but I still preferred the
    Moz-type news clients on those platforms.

    Some of the groups on the 11 news servers where I am active will nearly
    always post in HTML, and include images. HTML-ready newsreaders just
    make better sense than text-only newsreaders for me since I do move
    through the groups fast and frequently.


    > http://www.cs.tut.fi/~jkorpela/usenet/dont.html
    >
    > #2 (in part)
    >
    > "Plain text means it's text only, with line length under 80 (preferably
    > under 72) characters; it doesn't mean boring or careless text. Use good
    > writing style."
    >
    >
    >> or http://tinyurl.com/44to3x
    >>

    >
    > Having supplied a tinyurl is perfectly correct, readable and useful. If
    > you will do that _alone_ in the future, people will be grateful.
    >



    I provided the TinyURL it as a courtesy because the URL was long. How
    long can only be determined by the readers.

    Creating a TinyURL does involve a few extra steps and a little
    additional time, especially since I do bother to verify that it works as
    intended.

    I don't believe I should be expected to do all the work, when there are
    people who just want to sit back and not bother to use a news client
    that can display messages in the format that they choose or desire.

    These people have their preferences, and I adjust practically all the
    time. But if I should post one long line, or someone thinks my sig has
    too many lines (when they wrap it), well it's their privilege to gripe,
    not to gripe, plonk, whatever.


    > Here's a useful source on the topic:
    > http://www.google.com/Top/Computers/Usenet/Etiquette/
    >
    > Regards,
    >



    I try to cater to the majority, that's why I bottom post, or post
    inline, when I actually prefer top-posting. I also do trim away
    non-relevant lines, which many others do not.

    I know, many net nannys will say logic dictates the reply should follow
    the original text, but my logic says I can remember previous articles,
    and it is a big waste of time for me to scroll down to see new material
    in nearly every message. Again, this is an old throwback to the past,
    and I'm aware that you can't teach old dogs new tricks, so I accommodate
    those who believe USENET has unbreakable laws, and I bottom post, and do
    a lot of scrolling to read.

    Same goes for plain text and no HTML. A throwback to the days of slow
    modems and hard-copy printing terminals. A picture is worth a thousand
    words, but to keep peace, I don't use HTML where it is not accepted.

    I certainly appreciate your politeness in this matter, but I did want to
    let you know how I stand on these issues. Some will agree, and some will
    disagree, but that is the way life is.

    I do try to fit in and do as the newsgroup users prefer. I'll remember
    to only use a TinyURL if the normal URL line appears too long -- if I
    can catch it since I can only guess. You know I use larger monitors,
    normally set at 1280x1024, and 80 columns can be only an educated guess
    at best.

    Again, thanks for sharing your thoughts, and for listening to mine.


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  17. Re: X.Org vs XFree86

    sk8r-365 wrote:
    > Thus spake John F. Morse:
    >
    >> -- John
    >>
    >> No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used
    >> in the preparation or transmission of this message.
    >>
    >> The EULA sounds like it was written by a team of lawyers who want to
    >> tell me what I can't do. The GPL sounds like it was written by a human
    >> being, who wants me to know what I can do.
    >>

    >
    > The above message is correct, IMO, but ... while I'm at it - and I'm not
    > wanting to offend - it needs to be mentioned your sig file is _too_
    > l-o-n-g and should be no more than the accepted 4 lines, less is OK,
    > when properly wrapped (I wrapped it). Please.
    >
    > http://www.faqs.org/faqs/usenet/posting-rules/part1/
    >
    > " Please keep your signatures concise, as people do not appreciate
    > seeing lengthy signatures, nor paying the phone bills to repeatedly
    > transmit them. 2 or 3 lines are usually plenty. Sometimes it is also
    > appropriate to add another line or two for addresses on other major
    > networks where you can be reached (e.g., CompuServ, Bitnet). Long
    > signatures are definitely frowned upon. DO NOT include drawings,
    > pictures, maps, or other graphics in your signature -- it is not the
    > appropriate place for such material and is viewed as rude by other
    > readers."
    >
    > Thank you,
    >



    You don't offend me, and I thank you for your kind remarks.

    However, as I mentioned in the previous message, it is impossible for me
    to wrap the length of the lines at any certain column that everyone
    likes. There are too many different newsreaders and preferences used by
    all of the USENET people. Those readers will have to wrap wherever they
    want the lines to break.

    For instance, the "80" column (or less) idea was devised in the
    teletypewriter era when everyone used a hard copy printer or printing
    terminal, like a Teletype 33 KSR/ASR, a DECwriter, DEC TP-1000, etc.
    More than 80 columns created a big, black blob at the end of the line.
    At least until smarter printers came out that could count the characters
    and force a carriage return at 78 or 80. The CR is now called "Enter" of
    course, but that shows the evolution of things.

    With modern computers instead of mechanical terminals, and configurable
    software, wrap can occur anywhere. Therefore the "80-column rule" is no
    longer needed.

    I can see where each and every one of the hot gripes by the net nannys
    are based on the available technology from back in the 1990s and
    earlier. This is 2008, and people need to get up to speed and use what
    is available, and quit holding back those who do want to get ahead.
    Mostly, they need to stop the petty picking and nannying. A prime
    example is a.o.l.ubuntu, which has turned into a very unpleasant place
    to try and give or get help.

    Please don't fall into this trap sk8tr, and please try and help others
    who somehow feel nannying is more important than providing help on the
    newsgroup name subjects. The nannying just causes flames and runs off
    the good guys, leaving undesirables behind to kill the groups. Before
    long they will have completely killed USENET, and then all that will
    remain is mailing lists and IRC, both which I despise.

    I know very well what is considered "etiquette," or even "standard
    rules" by some in USENET, but maybe if you told me why slrn cannot wrap
    the lines wherever you prefer them, I'd have an idea why this is such an
    issue with you (and many others obviously).

    While you are at it (you didn't object to me about this because I wasn't
    guilty of it), what is a reason to never top-post? Is it because some
    people hate to pound the spacebar to get through long, boring quoted
    material after they have read the new stuff? Perhaps because some lazy
    replier said a few words at the top and didn't trim anything?

    What about me pounding my spacebar to get down to the relevant new
    material? If I really need a refresher, I can always scroll back up.
    Can't slrn do that, even when using a non-GUI pseudo TTY terminal
    without any GUI scrollbars? Does work for slrn, nn,
    tin, or trn?

    Not counting the two blank lines, my sig is actually three lines -- if
    you don't wrap them. The delimiter isn't part of the sig, it is a
    separator and should cause an automatic trim unless a reader is using
    trash like OE. The time to send three lines online is microseconds. The
    extra lines aren't wasting anybody's canary yellow teleprinter paper
    like when the "rule" was established, and the text is not a big
    commercial advertisement in nature.

    I ask these questions because using something like Thunderbird, I don't
    have any problems with line wrap, long sigs, or even multiple sigs like
    one a.o.l.ubuntu user whom I'm sure you know, nor even with useful HTML.
    My gripe is the need to scroll past stale material to get to the new,
    and mostly, having to read constant nannying by those who are
    self-appointed USENET police.

    Please don't feel offended because I'm not singling you out. I just felt
    you deserved an explanation why I do or prefer these things. Perhaps you
    will have a second look and maybe even consider a change in preference,
    even if you do not actually make any changes as to how you post.

    Again, thanks for sharing your opinions, and for listening to mine.

    I have replaced my normal sig on this message for you and me.


    --
    John

    Whoever loves his brother lives in the light, and there is nothing in him to make him stumble. 1 John 2:10

  18. Re: X.Org vs XFree86

    I demand that sk8r-365 may or may not have written...

    > Thus spake John F. Morse:
    >
    >> http://www.samsung.com/cp/support/pr...ad/FileView.as
    >> px?cttfileid=876633&type=Monitor&typecode=&subtype=Archived+Monitor&
    >> subtypecode=&cmssubtypecode=&model=931B&filetype=UM&language=&LSSI=/cp/
    >> module/ssi/left/lmenu_monitor_archivedmonitor.sec&RSSI=/cp/module/ssi/
    >> right/rmenu_archivedmonitor.sec

    [snip]
    >> or http://tinyurl.com/44to3x


    > Having supplied a tinyurl is perfectly correct, readable and useful. If you
    > will do that _alone_ in the future, people will be grateful.


    Some will; some of us don't want the redirection URL and would rather see the
    original.

    [snip]
    --
    | Darren Salt | linux or ds at | nr. Ashington, | Toon
    | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
    | + Interception of this message for advertising purposes is not permitted.

    Don't shoot the pianist.

  19. Re: X.Org vs XFree86

    Thus spake John F. Morse:

    > With modern computers instead of mechanical terminals, and configurable
    > software, wrap can occur anywhere. Therefore the "80-column rule" is no
    > longer needed.


    Not so, for the wrap is based on a break, and your 312 character URL
    doesn't have one. I have slrn set to wrap (set wrap_flags 7).

    > I can see where each and every one of the hot gripes by the net nannys
    > are based on the available technology from back in the 1990s and
    > earlier. This is 2008, and people need to get up to speed and use what
    > is available, and quit holding back those who do want to get ahead.



    Grrr ... this is a peeve. That view point is of one who lives in the
    States, while neglecting to consider there are millions more not using
    large monitors and high speed connections. It leaves out consideration
    of the needs and situation even of those in modernized non-US countries,
    many in England for example, who have to pay by the minute/bytes for
    their dial up. Your attitude neglects there a handicapped readers who
    have trouble doing all the simple scrolling, pointy-clicky things.
    Slapping people with pictures (ASCII or otherwise), unneeded text, HTML
    code, etc. is rude. Seen that thoughtless attitude elsewhere, "If they
    would rather die," said Scrooge, "they had better do it, and decrease
    the surplus population."

    BTW, you said, "people need to get up to speed and use what is
    available" - slrn is available, up to speed and of my choosing above all
    other options.

    > Please don't fall into this trap sk8tr, and please try and help others
    > who somehow feel nannying is more important than providing help on the
    > newsgroup name subjects.



    I offer computer related help much more than providing lessons in net
    etiquette on USENET - but all of it is help. What I'm trying to do here
    is maintain long standing, and useful, guidelines which have served the
    world over - the world, as you know, isn't the U.S. only. Your current
    cavalier approach is equivalent to Microsoft's treading on the Web with
    their own special non-standard page coding, unintelligent top posting
    approach and specialized formatting simply due to your having the
    capability and software which corrects the laziness and thoughtlessness
    of others. In contrast, I suspect that by your replies to my request for
    Net-etiquette here you care and you aren't intentionally trying be
    bad-mannered... unlike MS.

    > I know very well what is considered "etiquette," or even "standard
    > rules" by some in USENET, but maybe if you told me why slrn cannot
    > wrap the lines wherever you prefer them, I'd have an idea why this is
    > such an issue with you (and many others obviously).


    slrn is modern and in current development. slrn wraps at a break as
    other proggies do. Your URL had no break for 312 characters.

    % If you want to wrap long lines automatically, without having to
    % press a key, you can set the variable to one of these values:

    % 7 wrap headers, quoted material and body

    set wrap_flags 7

    slrn is very configurable and has a powerful scoring method. Another
    useful benefit of slrn is that when posting, and there's a Net-etiquette
    faux pas, it stops with a message and chance to correct it. I prefer it
    to pointy-clicky because I _read_ USENET and very rarely bother with
    binaries (I do lurk alt.binaries.pictures.scenic).

    > While you are at it (you didn't object to me about this because I wasn't
    > guilty of it), what is a reason to never top-post? Is it because some
    > people hate to pound the spacebar to get through long, boring quoted
    > material after they have read the new stuff? Perhaps because some lazy
    > replier said a few words at the top and didn't trim anything?


    It's illogical. Most read books from the first page (top) to the last
    (bottom). Top posting breaks the intelligent natural order of reading...
    it's beginning to end, not end to beginning as MS has it done. Would you
    find these messages better reading if posted in reverse order?

    As for boring info: snipping unneeded text improves on the problem.

    For a complete treatment of the topic read
    http://www.caliburn.nl/topposting.html .

    About recalling what you wrote in a thread ... I don't recall what you
    wrote, nor will the potentially millions of others who might read it
    over the years. Be thoughtful.

    > What about me pounding my spacebar to get down to the relevant new
    > material?


    You're suffering from UTS - unsnipped text syndrome. Have you said
    anything to that poster? Net-etiquette is your friend.

    > If I really need a refresher, I can always scroll back up.
    > Can't slrn do that, even when using a non-GUI pseudo TTY terminal
    > without any GUI scrollbars? Does work for slrn, nn,
    > tin, or trn?



    Quit sniping. slrn has back and forward keys. Browse the Web for slrn
    information and you'll find all the answers to your questions.

    > I ask these questions because using something like Thunderbird, I don't
    > have any problems with line wrap, long sigs, or even multiple sigs like
    > one a.o.l.ubuntu user whom I'm sure you know, nor even with useful HTML.


    TB is a very good email client masquerading as a news client (oh, oh,
    here come the flames! ). slrn does one thing and it does it
    properly - it's a newsreader. Also, I don't read *ubuntu.

    > My gripe is the need to scroll past stale material to get to the new,
    > and mostly, having to read constant nannying by those who are
    > self-appointed USENET police.


    I'm not the first to ask you to be considerate?

    > Please don't feel offended because I'm not singling you out. I just felt
    > you deserved an explanation why I do or prefer these things.


    I started this off topic thread; not feeling singled out.

    > Perhaps you will have a second look and maybe even consider a change
    > in preference, even if you do not actually make any changes as to how
    > you post.


    I've been on the Net before there were GUI tools generally available. It
    was all vt and UNIX commands. Have kept regard for, and long supported,
    net etiquette that full time. I see net etiquette as a "do unto others"
    matter.

    > Again, thanks for sharing your opinions, and for listening to mine.


    You too. If you want, you can have the last word - but, please, no
    questions. Otherwise, I'll feel obligated to respect you but held back
    to avoid violating my "last word" offer. 8P

    > I have replaced my normal sig on this message for you and me.


    I'm especially found of 1 John. Favorite is 1 John 3:1-3

    "Behold, what manner of love the Father hath bestowed upon us, that we
    should be called the sons of God: therefore the world knoweth us not,
    because it knew him not.

    Beloved, now are we the sons of God, and it doth not yet appear what we
    shall be: but we know that, when he shall appear, we shall be like him;
    for we shall see him as he is.

    And every man that hath this hope in him purifieth himself, even as he
    is pure."

    --
    sk8r-365
    What I tell you in darkness, that speak ye in light: and what ye
    hear in the ear, that preach ye upon the housetops. -- Matthew 10:27

  20. Re: X.Org vs XFree86

    On Apr 4, 1:45 am, "John F. Morse" wrote:
    > Most of my GNU/Linux installations use Debian 3.1, with older Ubuntu,
    > Fedora Core, Lindows, Mandrake, Red Hat, Slackware, etc. IIRC, these all
    > use XFree86, and I had to learn to fine-tune it over the years.
    >
    > Debian 4.0 uses X.Org.
    >
    > I presently have a "portable" ViewSonic 21 monitor plugged into one
    > Debian box, which I have recently upgraded from Sarge to Etch, and now
    > cannot get a higher resolution than 640x480. This is, of course, a
    > ridiculous resolution for a 21" screen.
    >
    > Even trying other multiscan/multifrequency 17" and "dumb" 15" monitors
    > will not allow any resolution change.


    This is becouse the graphical card has too litle memory. At least it
    thinks so.

    > To make matters worse, the detected Trident video card causes a failure
    > when xorg tries to initialize a screen.
    >
    > Of course the TTY terminals all work, so I do have access to vi for
    > xorg.conf edits. The only method I've found to startx for a GUI DE is to
    > manually edit xorg.conf and replace "trident" with "vesa" as the driver.
    >
    > Running "dpkg-reconfigure -phigh xorg-server" will only rebuild
    > xorg.conf back to the detected trident driver.


    Try 'dpkg-reconfigure -plow xserver-xorg'

    > The monitor frequency rates also makes no difference if I edit xorg.conf
    > and change them to the correct values for the monitor.


    You shouldn't set values for modern monitors. They tell the graphical
    card
    all it needs. Only for buggy monitors it's needed.
    Try only ' option "DPMS"' as is the default anyway.

    > The Trident video card has sufficient memory, and is used in eleven
    > other identical PCs which run Debian Sarge fine under XFree86. However
    > Sarge support is ending so I must upgrade to Etch as time permits.


    No, Xorg can't detect sufficient memory, as you can see in your log.
    You should prob. tell Xorg the size.
    We really need to also see /etc/X11/xorg.conf

    > Below is the total /var/log/Xorg.0.log for examination (the font
    > problems are of no concern).


    > Perhaps someone has an idea that I might try? The xorg.conf can also be
    > posted if requested.


    It is needed, as your posted Xorg.0.log (good!)

    > These Debian servers all run headless anyway, but at this point in time,
    > I'd certainly like to find and resolve this X.Org resolution problem.
    >
    > TIA.
    >
    > X Window System Version 7.1.1
    > Release Date: 12 May 2006
    > X Protocol Version 11, Revision 0, Release 7.1.1
    > Build Operating System: UNKNOWN
    > Current Operating System: Linux optima12 2.6.18-4-486 #1 Mon Mar 26
    > 16:39:10 UTC 2007 i586
    > Build Date: 24 January 2008
    > Before reporting problems, checkhttp://wiki.x.org
    > to make sure that you have the latest version.
    > Module Loader present
    > Markers: (--) probed, (**) from config file, (==) default setting,
    > (++) from command line, (!!) notice, (II) informational,
    > (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    > (==) Log file: "/var/log/Xorg.0.log", Time: Tue Apr 1 01:42:25 2008
    > (==) Using config file: "/etc/X11/xorg.conf"
    > (==) ServerLayout "Default Layout"
    > (**) |-->Screen "Default Screen" (0)
    > (**) | |-->Monitor "Generic Monitor"
    > (**) | |-->Device "Trident Microsystems TGUI 9660/938x/968x"
    > (**) |-->Input Device "Generic Keyboard"
    > (**) |-->Input Device "Configured Mouse"
    > (WW) The directory "/usr/X11R6/lib/X11/fonts/misc" does not exist.
    > Entry deleted from font path.
    > (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
    > Entry deleted from font path.
    > (WW) The directory "/usr/X11R6/lib/X11/fonts/cyrillic" does not exist.
    > Entry deleted from font path.
    > (WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi/" does not exist.
    > Entry deleted from font path.
    > (WW) The directory "/usr/X11R6/lib/X11/fonts/75dpi/" does not exist.
    > Entry deleted from font path.
    > (WW) The directory "/usr/X11R6/lib/X11/fonts/Type1" does not exist.
    > Entry deleted from font path.


    You should prob clean your paths. They have changed

    > (II) Bus 0: bridge is at (0:0:0), (0,0,0), BCTRL: 0x0008 (VGA_EN is set)
    > (II) Bus 0 I/O range:
    > [0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
    > (II) Bus 0 non-prefetchable memory range:
    > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
    > (II) Bus 0 prefetchable memory range:
    > [0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
    > (II) PCI-to-ISA bridge:
    > (II) Bus -1: bridge is at (0:7:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
    > (--) PCI:*(0:10:0) Trident Microsystems TGUI 9660/938x/968x rev 211, Mem
    > @ 0xff800000/22, 0xffef0000/16, BIOS @ 0xffee0000/16


    Found Trident PCI card att PCI 0:10:0

    > (II) LoadModule: "vbe"
    > (II) Loading /usr/lib/xorg/modules/libvbe.so
    > (II) Module vbe: vendor="X.Org Foundation"
    > compiled for 7.1.1, module version = 1.1.0
    > ABI class: X.Org Video Driver, version 1.0
    > (II) LoadModule: "trident"
    > (II) Loading /usr/lib/xorg/modules/drivers/trident_drv.so
    > (II) Module trident: vendor="X.Org Foundation"
    > compiled for 7.1.1, module version = 1.2.3
    > Module class: X.Org Video Driver
    > ABI class: X.Org Video Driver, version 1.0


    loading trident Xorg driver

    > (II) LoadModule: "mouse"
    > (II) Loading /usr/lib/xorg/modules/input/mouse_drv.so
    > (II) Module mouse: vendor="X.Org Foundation"
    > compiled for 7.1.1, module version = 1.1.1
    > Module class: X.Org XInput Driver
    > ABI class: X.Org XInput driver, version 0.6
    > (II) TRIDENT: driver for Trident chipsets: tvga9000, tvga9000i, tvga8900c,
    > tvga8900d, tvga9200cxr, tgui9400cxi, cyber9320, cyber9388, cyber9397,
    > cyber9397dvd, cyber9520, cyber9525dvd, cyberblade/e4, tgui9420dgi,
    > tgui9440agi, tgui9660, tgui9680, providia9682, providia9685,
    > cyber9382, cyber9385, 3dimage975, 3dimage985, blade3d, cyberbladei7,
    > cyberbladei7d, cyberbladei1, cyberbladei1d, cyberbladeAi1,
    > cyberbladeAi1d, bladeXP, cyberbladeXPAi1, cyberbladeXP4, XP5
    > (II) Primary Device is: PCI 00:0a:0
    > (--) Chipset tgui9660 found
    > (II) resource ranges after xf86ClaimFixedResources() call:
    > [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
    > [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]


    Trident PCI card with tgui9660 found by Xorg trident driver

    > (II) Setting vga for screen 0.
    > (**) TRIDENT(0): Depth 24, (--) framebuffer bpp 32
    > (II) Loading sub module "vgahw"
    > (II) LoadModule: "vgahw"
    > (II) Loading /usr/lib/xorg/modules/libvgahw.so
    > (II) Module vgahw: vendor="X.Org Foundation"
    > compiled for 7.1.1, module version = 0.1.0
    > ABI class: X.Org Video Driver, version 1.0
    > (II) TRIDENT(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
    > is 0x0000


    Trident found and used

    > (WW) System lacks support for changing MTRRs
    > (II) TRIDENT(0): VESA BIOS detected
    > (II) TRIDENT(0): VESA VBE Version 1.2
    > (II) TRIDENT(0): VESA VBE Total Mem: 1024 kB
    > (II) TRIDENT(0): VESA VBE OEM: Trident TGUI96xx
    > (--) TRIDENT(0): Revision is 1
    > (--) TRIDENT(0): Found TGUI9680 chip
    > (--) TRIDENT(0): RAM type is EDO Ram
    > (--) TRIDENT(0): Using HW cursor
    > (--) TRIDENT(0): VideoRAM: 1024 kByte
    > (--) TRIDENT(0): Memory Clock is 42.95 MHz
    > (==) TRIDENT(0): Min pixel clock is 12 MHz
    > (--) TRIDENT(0): Max pixel clock is 40 MHz
    > (II) TRIDENT(0): Generic Monitor: Using hsync range of 28.00-80.00 kHz
    > (II) TRIDENT(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
    > (II) TRIDENT(0): Clock range: 12.00 to 40.00 MHz
    > (II) TRIDENT(0): Not using default mode "640x350" (vrefresh out of range)
    > (II) TRIDENT(0): Not using default mode "320x175" (bad mode
    > clock/interlace/doublescan)
    > (II) TRIDENT(0): Not using default mode "640x400" (vrefresh out of range)
    > (II) TRIDENT(0): Not using default mode "320x200" (bad mode
    > clock/interlace/doublescan)
    > (II) TRIDENT(0): Not using default mode "720x400" (insufficient memory
    > for mode)


    As seen, lots of different resolutions are detected for the monitor,
    but not sufficent ram in graphical card to run them.

    > (II) TRIDENT(0): Not using default mode "2048x1536" (insufficient memory
    > for mode)
    > (II) TRIDENT(0): Not using default mode "1024x768" (insufficient memory
    > for mode)
    > (WW) TRIDENT(0): Mode pool is empty
    > (EE) TRIDENT(0): No valid modes found
    > (II) UnloadModule: "trident"
    > (II) UnloadModule: "vm86"
    > (II) Unloading /usr/lib/xorg/modules/libvm86.so
    > (II) UnloadModule: "int10"
    > (II) UnloadModule: "vbe"
    > (II) UnloadModule: "ramdac"
    > (II) Unloading /usr/lib/xorg/modules/libramdac.so
    > (II) UnloadModule: "vgahw"
    > (II) Unloading /usr/lib/xorg/modules/libvgahw.so
    > (EE) Screen(s) found, but none have a usable configuration.
    >
    > Fatal server error:
    > no screens found


    Xorg panics and exits when it cant find a suitable resolution for the
    card.


+ Reply to Thread
Page 1 of 2 1 2 LastLast