Re: Trident TGUI9680 and general X woes - Xwindows

This is a discussion on Re: Trident TGUI9680 and general X woes - Xwindows ; "Charlie Gibbs" writes: [snip] > Wow. Nifty utilities. I'll do some more digging sometime. > >>X is very easy to configure after you understand /etc/X11/XF86Config-4 >>and modelines. Do some googling. >>man X >>man startx >>man XFree86 >>man XF86Config-4 [snip] man ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: Trident TGUI9680 and general X woes

  1. Re: Trident TGUI9680 and general X woes

    "Charlie Gibbs" writes:
    [snip]
    > Wow. Nifty utilities. I'll do some more digging sometime.
    >
    >>X is very easy to configure after you understand /etc/X11/XF86Config-4
    >>and modelines. Do some googling.
    >>man X
    >>man startx
    >>man XFree86
    >>man XF86Config-4

    [snip]

    man XF86Config

    There's no man page for XF86Config-4 ; that's just one of the names
    checked for your XF86Config.

  2. Re: Trident TGUI9680 and general X woes

    llewelly wrote:
    > "Charlie Gibbs" writes:
    > [snip]
    >
    >>Wow. Nifty utilities. I'll do some more digging sometime.
    >>
    >>
    >>>X is very easy to configure after you understand /etc/X11/XF86Config-4
    >>>and modelines. Do some googling.
    >>>man X
    >>>man startx
    >>>man XFree86
    >>>man XF86Config-4

    >
    > [snip]
    >
    > man XF86Config
    >
    > There's no man page for XF86Config-4 ; that's just one of the names
    > checked for your XF86Config.


    It exists in Debian systems:

    XF86Config-4(5x) XF86Config-4(5x)

    NAME
    XF86Config-4 - configuration file for XFree86

    DESCRIPTION
    XFree86 uses a configuration file called XF86Config for
    its initial setup. This configuration file is searched
    for in the following places when the server is started as
    a normal user:
    ....


  3. Re: Trident TGUI9680 and general X woes

    In article rjshaw@iprimus.com.au
    (Russell Shaw) writes:

    > llewelly wrote:
    >
    >> "Charlie Gibbs" writes:
    >> [snip]
    >>
    >>>> man XF86Config-4

    >>
    >> [snip]
    >>
    >> man XF86Config
    >>
    >> There's no man page for XF86Config-4 ; that's just one of the names
    >> checked for your XF86Config.

    >
    > It exists in Debian systems:


    It must be unique to Debian: my Slackware and OpenBSD boxes don't
    recognize it.

    For now I'm off hunting for the phantom SiS video adapter that
    for some reason is detected while booting - it's probably not
    even an X problem at all. (I should have known - after all,
    one of my debugging principles is "If you can't find what you're
    looking for, you might be looking in the wrong place.")

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!


  4. Re: Trident TGUI9680 and general X woes

    Russell Shaw writes:

    > llewelly wrote:
    >> "Charlie Gibbs" writes:
    >> [snip]
    >>
    >>>Wow. Nifty utilities. I'll do some more digging sometime.
    >>>
    >>>
    >>>>X is very easy to configure after you understand /etc/X11/XF86Config-4
    >>>>and modelines. Do some googling.
    >>>>man X
    >>>>man startx
    >>>>man XFree86
    >>>>man XF86Config-4

    >> [snip]
    >> man XF86Config
    >> There's no man page for XF86Config-4 ; that's just one of the names
    >> checked for your XF86Config.

    >
    > It exists in Debian systems:

    [snip]

    hm. Interesting. It isn't in my FreeBSD or Mandrake systems. And few
    minutes of googling does not turn it up on www.xfree86.org . Must
    be a Debian special feature.


  5. Re: Trident TGUI9680 and general X woes

    Charlie Gibbs wrote:
    > In article rjshaw@iprimus.com.au
    > (Russell Shaw) writes:
    >
    >>llewelly wrote:
    >>

    ....
    >>>
    >>>There's no man page for XF86Config-4 ; that's just one of the names
    >>> checked for your XF86Config.

    >>
    >>It exists in Debian systems:

    >
    > It must be unique to Debian: my Slackware and OpenBSD boxes don't
    > recognize it.
    >
    > For now I'm off hunting for the phantom SiS video adapter that
    > for some reason is detected while booting - it's probably not
    > even an X problem at all. (I should have known - after all,
    > one of my debugging principles is "If you can't find what you're
    > looking for, you might be looking in the wrong place.")


    Maybe it's on the motherboard.
    XFree86 -scanpci
    lspci
    cat /proc/pci


  6. Re: Trident TGUI9680 and general X woes

    In article rjshaw@iprimus.com.au
    (Russell Shaw) writes:

    > Charlie Gibbs wrote:
    >
    >> For now I'm off hunting for the phantom SiS video adapter that
    >> for some reason is detected while booting - it's probably not
    >> even an X problem at all. (I should have known - after all,
    >> one of my debugging principles is "If you can't find what you're
    >> looking for, you might be looking in the wrong place.")

    >
    > Maybe it's on the motherboard.
    > XFree86 -scanpci
    > lspci
    > cat /proc/pci


    Ah, here's one of the disadvantages of working with OpenBSD:
    it doesn't have either lspci or the /proc filesystem.
    XFree86 -scanpci gave nothing, but its man page contained
    a reference to a utility called scanpci:

    puffy# /usr/X11R6/bin/scanpci -v

    pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x1039 device 0x5597
    SiS Device unknown
    STATUS 0x2200 COMMAND 0x0007
    CLASS 0x06 0x00 0x00 REVISION 0x02
    BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00

    pci bus 0x0000 cardnum 0x01 function 0x00: vendor 0x1039 device 0x0008
    SiS Device unknown
    STATUS 0x0200 COMMAND 0x0007
    CLASS 0x06 0x01 0x00 REVISION 0x01
    BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00
    BYTE_0 0x80800bfa BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00

    pci bus 0x0000 cardnum 0x01 function 0x01: vendor 0x1039 device 0x5513
    SiS Device unknown
    STATUS 0x0000 COMMAND 0x0007
    CLASS 0x01 0x01 0x8a REVISION 0xd0
    BIST 0x00 HEADER 0x80 LATENCY 0x20 CACHE 0x00
    BASE0 0x0000e401 addr 0x0000e400 I/O
    BASE1 0x0000e001 addr 0x0000e000 I/O
    BASE2 0x0000d801 addr 0x0000d800 I/O
    BASE3 0x0000d401 addr 0x0000d400 I/O
    BASE4 0x0000d001 addr 0x0000d000 I/O
    MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0e
    BYTE_0 0x301a301 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00

    pci bus 0x0000 cardnum 0x09 function 0x00: vendor 0x1317 device 0x0985
    Device unknown
    CardVendor 0x1317 card 0x0574 (Card unknown)
    STATUS 0x0290 COMMAND 0x0017
    CLASS 0x02 0x00 0x00 REVISION 0x11
    BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x08
    BASE0 0x0000b801 addr 0x0000b800 I/O
    BASE1 0xe5800000 addr 0xe5800000 MEM
    MAX_LAT 0x80 MIN_GNT 0x40 INT_PIN 0x01 INT_LINE 0x0a

    pci bus 0x0000 cardnum 0x0c function 0x00: vendor 0x5333 device 0x5631
    S3 ViRGE
    STATUS 0x0200 COMMAND 0x0007
    CLASS 0x03 0x00 0x00 REVISION 0x06
    BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00
    BASE0 0xe0000000 addr 0xe0000000 MEM
    MAX_LAT 0xff MIN_GNT 0x04 INT_PIN 0x01 INT_LINE 0x0b

    pci bus 0x0000 cardnum 0x13 function 0x00: vendor 0x1039 device 0x0200
    SiS 5597
    STATUS 0x0200 COMMAND 0x0003
    CLASS 0x03 0x00 0x00 REVISION 0x65
    BASE0 0xe7000008 addr 0xe7000000 MEM PREFETCHABLE
    BASE1 0xdf800000 addr 0xdf800000 MEM
    BASE2 0x0000b401 addr 0x0000b400 I/O
    BASEROM 0xe6ff0000 addr 0xe6ff0000 not-decode-enabled

    puffy#

    Damn, that SiS stuff is all over the place. (The unknown card
    at 0x09 is my NIC.) Looks like it's time to pull that motherboard
    and give it a good hard looking at...

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!


  7. Re: Trident TGUI9680 and general X woes

    Charlie Gibbs wrote:
    > In article rjshaw@iprimus.com.au
    > (Russell Shaw) writes:
    >

    ....
    > pci bus 0x0000 cardnum 0x13 function 0x00: vendor 0x1039 device 0x0200
    > SiS 5597
    > STATUS 0x0200 COMMAND 0x0003
    > CLASS 0x03 0x00 0x00 REVISION 0x65
    > BASE0 0xe7000008 addr 0xe7000000 MEM PREFETCHABLE
    > BASE1 0xdf800000 addr 0xdf800000 MEM
    > BASE2 0x0000b401 addr 0x0000b400 I/O
    > BASEROM 0xe6ff0000 addr 0xe6ff0000 not-decode-enabled
    >
    > puffy#
    >
    > Damn, that SiS stuff is all over the place. (The unknown card
    > at 0x09 is my NIC.) Looks like it's time to pull that motherboard
    > and give it a good hard looking at...


    If you know the board vendor and number (sometimes shown at bootup)
    google will probably find a data sheet on the vendors web page.

    It's probably a mainboard with a SiS chipset.


  8. Re: Trident TGUI9680 and general X woes

    In article rjshaw@iprimus.com.au
    (Russell Shaw) writes:

    > Charlie Gibbs wrote:
    >
    >> In article rjshaw@iprimus.com.au
    >> (Russell Shaw) writes:
    >>

    >...
    >> pci bus 0x0000 cardnum 0x13 function 0x00: vendor 0x1039 device 0x0200
    >> SiS 5597
    >> STATUS 0x0200 COMMAND 0x0003
    >> CLASS 0x03 0x00 0x00 REVISION 0x65
    >> BASE0 0xe7000008 addr 0xe7000000 MEM PREFETCHABLE
    >> BASE1 0xdf800000 addr 0xdf800000 MEM
    >> BASE2 0x0000b401 addr 0x0000b400 I/O
    >> BASEROM 0xe6ff0000 addr 0xe6ff0000 not-decode-enabled
    >>
    >> puffy#
    >>
    >> Damn, that SiS stuff is all over the place. (The unknown card
    >> at 0x09 is my NIC.) Looks like it's time to pull that motherboard
    >> and give it a good hard looking at...

    >
    > If you know the board vendor and number (sometimes shown at bootup)
    > google will probably find a data sheet on the vendors web page.
    >
    > It's probably a mainboard with a SiS chipset.


    Yup, turns out that's exactly what it is. I pulled the motherboard
    out of the case and inspected it closely. I couldn't read the
    markings on one VLSI chip because it had a heat sink glued to it,
    but the board was marked "5598/5582" right next to it. There's
    also a 16-pin header labeled VGACON over near the floppy and IDE
    connectors, and jumpers labeled VGA_SEL, INT.VGA SEL, and VGA_SEL1
    nearby, with markings on where to set things to disable them.
    I tried a couple of guesses, but wasn't able to keep the SiS chip
    from being detected both at boot and by X.

    I guess that's the nice part about Windows' "Plug & Pray" not really
    working - when this box ran Windows it had no trouble using the VGA
    card, being blissfully ignorant of the onboard VGA.

    Next time I dive back into this (I have about 10 hours into it
    so far - I can only afford to work on it once a week or so because
    I have real work to do) I might try to look on the Web for a data
    sheet. But I'm not looking forward to that. I HATE the Web -
    IMHO it's glorified television, existing solely for the purposes
    of advertising and entertainment. My attempts to find technical
    data usually end in failure after a lot of time and frustration.
    Most of the vendors' sites I've tried in the past offer nothing
    more than sales blurbs on their very latest products, with no
    data sheets for anything at all. But I realize I'm somewhat
    old-fashioned, insisting on content and all...

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!


  9. Re: Trident TGUI9680 and general X woes

    In article <2685.311T2747T9436060@kltpzyxm.invalid>
    cgibbs@kltpzyxm.invalid (Charlie Gibbs) writes:

    Well, I finally got it. Going to the ASUS web site was the exercise
    in frustration that I fully expected - lots of half-megabyte downloads
    of fluff (through my dial-up connection) with no way to find anything
    useful. Fortunately, a bit of googling gave me a back door into
    their site which yielded a 960K PDF file: a detailed manual for
    my motherboard. I set the jumpers the way it indicated and >poof<
    the on-board VGA chipset disappeared. (Which is a good thing -
    I was getting ready to do the job with a chisel and a blowtorch.)

    So once again I tried configuring X and firing it up. The screen
    went blank, two seconds later the cursor disappeared... and that
    was it. Nothing more, no matter how long I waited, aside from a
    few beeps as I blindly tried to back out with control-alt-backspace.

    At this point, steam was beginning to come out of my ears again.
    But I still had the old NT box open, so just for the heck of it
    I tried pulling out its S3 ViRGE card again and dropping it into
    the OpenBSD box in place of its Trident card. Another config,
    then startx once more... blank screen... two seconds later the
    cursor disappeared... then an agonizing delay, and just as I was
    about to hit the reset button again, up came fvwm in all its glory.

    The Trident card went into the NT box, which is dumb enough to
    not know the difference.

    So it looks like I'm on my way. Thanks, guys, for all your help.
    I've learned a couple of important lessons here:

    1. Beware of on-board VGA.

    2. Stay away from Trident cards.

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!


+ Reply to Thread