Two video cards ... separate text and graphical usage - X

This is a discussion on Two video cards ... separate text and graphical usage - X ; As an alternative to an issue I have that may be specific to the old video card I am using (and hence, gets little or no testing between releases), I am considering two other options: 1. Finding a NEW video ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Two video cards ... separate text and graphical usage

  1. Two video cards ... separate text and graphical usage

    As an alternative to an issue I have that may be specific to the old video
    card I am using (and hence, gets little or no testing between releases),
    I am considering two other options:

    1. Finding a NEW video card model that is well supported in Xorg and is
    also well supported in text mode with SVGATextMode. Unfortunately,
    SVGATextMode is no longer being maintained, so this option appears to
    be very unlikely.

    2. Use two video cards. The old card would be used for text mode and the
    new card would be used for X.

    Option number #2 seems most likely. I've seen several documents explaining
    how to use 2 video cards, but they are either directed at how to disable an
    on-the-main-board video chip in favor of a plugged in better video card, or
    how to use 2 (probably identical) video cards to either run a double sized
    desktop or two concurrent X displays. None of them explained how to use
    one for text mode (not frame buffer) and the other for X in graphical mode.

    I do see the complication that I'd have to switch video output between the
    two cards, while keyboard and mouse are unswitched in hardware, but would
    be switched in software. I'm wondering if maybe I could do this in the LCD
    display monitor by using analog for the text mode and DVI for the graphical
    mode (since all good cards have that these days). If the video gets turned
    off on the card not in use, maybe the monitor will detect that and switch.

    If anyone wants to suggest to use text under X instead of console text mode,
    would you be prepared to assist in making text under X work exactly the same
    under X as it does in console text mode? I'm not sure it is even possible.
    But if it is, it might involve a lot of work, such as rewriting xterm to use
    acceleration, and changing the mouse behaviour.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-01-27-1328@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: Two video cards ... separate text and graphical usage

    phil-news-nospam@ipal.net staggered into the Black Sun and said:
    > As an alternative to an issue I have that may be specific to the old
    > video card I am using, I am considering two other options:
    >
    > 1. Finding a NEW video card model that is well supported in Xorg and
    > is also well supported in text mode with SVGATextMode. Unfortunately,
    > SVGATextMode is no longer being maintained


    Yeah, forget this.

    > 2. Use two video cards. The old card would be used for text mode and
    > the new card would be used for X.


    3. Get a dual-head video card, set it up with separate Screens. Run
    your normal X junk on :0.0, run a maximized xterm (konsole, aterm,
    gnome-terminal...) on :0.1. It'd probably be easier and would certainly
    be more flexible, and you could convert it to Xinerama when you wanted
    to do that.

    > None of them explained how to use one for text mode (not frame buffer)
    > and the other for X in graphical mode.


    Hardly anyone wants to do that, because X is where it's at for 99.5% of
    the users. http://linuxconsole.sourceforge.net/ , however, might be
    worth looking at. It might require some non-n00b-friendly configuration
    to get it working the way you want it.

    > If anyone wants to suggest to use text under X instead of console text
    > mode, would you be prepared to assist in making text under X work
    > exactly the same under X as it does in console text mode? I'm not
    > sure it is even possible. But if it is, it might involve a lot of
    > work, such as rewriting xterm to use acceleration, and changing the
    > mouse behaviour.


    Why would xterm need to handle mouse acceleration? If you want to
    change the mouse behavior in X, that's what xset and multiple frontends
    that change the same accel/thresh numbers xset does are for. There's
    also the Resolution line in the input device stanzas for mice in
    xorg.conf, and xmodmap to remap mouse buttons.


    --
    Murphy's revenge: The more reliable you make a system, the longer it
    will take you to figure out what's wrong when it breaks.
    --Sean Donelan, Mon, 26 Nov 2001
    Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

  3. Re: Two video cards ... separate text and graphical usage

    On 27 Jan 2008 20:40:38 GMT Dances With Crows wrote:
    | phil-news-nospam@ipal.net staggered into the Black Sun and said:
    |> As an alternative to an issue I have that may be specific to the old
    |> video card I am using, I am considering two other options:
    |>
    |> 1. Finding a NEW video card model that is well supported in Xorg and
    |> is also well supported in text mode with SVGATextMode. Unfortunately,
    |> SVGATextMode is no longer being maintained
    |
    | Yeah, forget this.
    |
    |> 2. Use two video cards. The old card would be used for text mode and
    |> the new card would be used for X.
    |
    | 3. Get a dual-head video card, set it up with separate Screens. Run
    | your normal X junk on :0.0, run a maximized xterm (konsole, aterm,
    | gnome-terminal...) on :0.1. It'd probably be easier and would certainly
    | be more flexible, and you could convert it to Xinerama when you wanted
    | to do that.

    Actually, I have a dual-head card. The trouble is, it is AGP and my
    new computer has PCIe instead of AGP. I then got a dual-head card for
    PCIe, but it didn't do text mode right. I might consider using that
    PCIe card for the X side of things, but only if I get the mga driver
    bug in X fixed (separately posted). I'll consider buying yet another
    video card that is better supported in X (dual-head or not), but only
    if I can get the text mode to work via the old card at the same time.


    |> None of them explained how to use one for text mode (not frame buffer)
    |> and the other for X in graphical mode.
    |
    | Hardly anyone wants to do that, because X is where it's at for 99.5% of
    | the users. http://linuxconsole.sourceforge.net/ , however, might be
    | worth looking at. It might require some non-n00b-friendly configuration
    | to get it working the way you want it.

    I'll check it out.

    X is where it's at for graphical work, and I do use X a lot. But for
    heavy duty text work, the text console has still not been beaten by any
    program I've seen in X. Is there something better than xterm that does
    do better at text?


    |> If anyone wants to suggest to use text under X instead of console text
    |> mode, would you be prepared to assist in making text under X work
    |> exactly the same under X as it does in console text mode? I'm not
    |> sure it is even possible. But if it is, it might involve a lot of
    |> work, such as rewriting xterm to use acceleration, and changing the
    |> mouse behaviour.
    |
    | Why would xterm need to handle mouse acceleration? If you want to
    | change the mouse behavior in X, that's what xset and multiple frontends
    | that change the same accel/thresh numbers xset does are for. There's
    | also the Resolution line in the input device stanzas for mice in
    | xorg.conf, and xmodmap to remap mouse buttons.

    The acceleration I referred to is not the mouse acceleration. The mouse
    behaviour issue is how the mouse behaves in and around text characters.
    That differs between X with xterm (and generally all other text) and the
    text console with gpm.

    The acceleration of concern is with things like fast scrolling of text.
    The text console can do this very fast by avoiding copying of data and
    just changing the scan starting point. And what copying is being done
    to move new lines into the screen, is in characters, not pixels. So it
    can go very fast and minimizes blocking of programs that spew out a lot
    of output.

    Other issues are things like how the mouse point associated with the text
    on the screen. Very frequently when I am cutting and pasting with the
    mouse while in X, the ending, and sometimes the beginning, character gets
    lost. If I slow down and do it carefully, it's OK. It just doesn't make
    it easy to do it fast because of the careful positioning requirement.
    With gpm in text console mode, this problem does not happen.

    There are also other details like when doing double and triple clicking
    to highlight words or lines, this doesn't work as desired. The list of
    characters that are considered to end a word and not spread the highlight
    need to be changed. For example, the '/' character stops highlighting of
    a word in xterm, but not in gpm. About 40% of what I highlight are file
    paths.

    I hope you get a clearer understanding of what I am doing, now.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-01-27-1446@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: Two video cards ... separate text and graphical usage

    phil-news-nospam@ipal.net staggered into the Black Sun and said:
    > Dances With Crows wrote:
    >> phil-news-nospam@ipal.net staggered into the Black Sun and said:
    >>> 2. Use two video cards. The old card would be used for text mode
    >>> and the new card would be used for X.

    >> 3. Get a dual-head video card, set it up with separate Screens. Run
    >> your normal X junk on :0.0, run a maximized xterm (konsole, aterm,
    >> gnome-terminal...) on :0.1. It'd probably be easier

    > Actually, I have a dual-head card. The trouble is, it is AGP and my
    > new computer has PCIe instead of AGP.


    Oops. Keeping up with the new buses on boards can be a pain if you like
    to hang on to old peripherals. BTDTGTTS.

    >>> None of them explained how to use one for text mode (not frame
    >>> buffer) and the other for X in graphical mode.

    >> Hardly anyone wants to do that, because X is where it's at for 99.5% of
    >> the users. http://linuxconsole.sourceforge.net/ , however, might be
    >> worth looking at.

    > I'll check it out. X is where it's at for graphical work, and I do
    > use X a lot. But for heavy duty text work, the text console has still
    > not been beaten by any program I've seen in X. Is there something
    > better than xterm that does do better at text?


    I've never had any problem with any of the term emulators and their
    handling of text. Then again, I type a little slower than many hardcore
    people. konsole works well for me in everything, but YMMV.

    >>> would you be prepared to assist in making text under X work exactly
    >>> the same under X as it does in console text mode? I'm not sure it
    >>> is even possible. But if it is, it might involve a lot of work,
    >>> such as rewriting xterm to use acceleration, and changing the mouse
    >>> behaviour.

    >> Why would xterm need to handle mouse acceleration?

    > The acceleration I referred to is not the mouse acceleration.


    Ah. Your initial complaint was kinda vague.

    > The acceleration of concern is with things like fast scrolling of
    > text. The text console can do this very fast by avoiding copying of
    > data and just changing the scan starting point. And what copying is
    > being done to move new lines into the screen is in characters, not
    > pixels. So it can go very fast and minimizes blocking of programs
    > that spew out a lot of output.


    If your programs are writing lots of junk to stdout, why not redirect
    that stdout to a file? Also, the Athena widgets used in xterm are
    really, really lightweight, and scrolling/bitblitting should have been
    heavily optimized within the X module itself. From what I can tell, the
    vast amount of stdout produced by "emerge world" delivered through the
    much heavier konsole doesn't cause the CPU or graphics card much pain.
    I'm not exactly running a state-of-the-art box either (Athlon XP 3500,
    1G, GeForce 7100 GS.)

    > There are also other details like when doing double and triple
    > clicking to highlight words or lines, this doesn't work as desired.
    > The list of characters that are considered to end a word and not
    > spread the highlight need to be changed.


    "man xterm" and grep for "character classes" for how to change that
    behavior in xterm. That's in Settings->Configure konsole->General in
    konsole.

    > I hope you get a clearer understanding of what I am doing, now.


    A bit, but I've never had the problems you're having. HTH anyway,

    --
    I think, therefore I am.
    ...how the @#$%^ did *you* get here?
    --Joe Zeff
    Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

  5. Re: Two video cards ... separate text and graphical usage

    On 28 Jan 2008 01:45:14 GMT Dances With Crows wrote:

    | If your programs are writing lots of junk to stdout, why not redirect
    | that stdout to a file? Also, the Athena widgets used in xterm are
    | really, really lightweight, and scrolling/bitblitting should have been
    | heavily optimized within the X module itself. From what I can tell, the
    | vast amount of stdout produced by "emerge world" delivered through the
    | much heavier konsole doesn't cause the CPU or graphics card much pain.
    | I'm not exactly running a state-of-the-art box either (Athlon XP 3500,
    | 1G, GeForce 7100 GS.)

    I do want to see the output. I don't have to be able to read every line
    to be able to get an idea what it does.

    Actually, what I often do is run programs under screen and disconnect.


    |> There are also other details like when doing double and triple
    |> clicking to highlight words or lines, this doesn't work as desired.
    |> The list of characters that are considered to end a word and not
    |> spread the highlight need to be changed.
    |
    | "man xterm" and grep for "character classes" for how to change that
    | behavior in xterm. That's in Settings->Configure konsole->General in
    | konsole.

    I'd prefer a config file so I can keep the setting.


    |> I hope you get a clearer understanding of what I am doing, now.
    |
    | A bit, but I've never had the problems you're having. HTH anyway,

    One problem I have with X is that when I move the cursor over some text,
    and try to highlight some text, it usually misses the first character even
    though I clearly am on that character. I have to move the cursor to in
    front of the character to be able to highlight it. That I find to be very
    awkward. The cursor is a shape of a narrow and tall letter "I". I want a
    cursor that is a block that fully covers a character and is fully aligned
    with it (e.g. moves in steps of character cells). I would only need this
    kind of cursor on the terminal program windows.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-01-28-2207@ipal.net |
    |------------------------------------/-------------------------------------|

  6. Re: Two video cards ... separate text and graphical usage

    phil-news-nospam@ipal.net staggered into the Black Sun and said:
    > Dances With Crows wrote:
    >> If your programs are writing lots of junk to stdout, why not redirect
    >> that stdout to a file?

    > I do want to see the output. I don't have to be able to read every line
    > to be able to get an idea what it does.


    Pipe it through grep, then.

    >>> There are also other details like when doing double and triple
    >>> clicking to highlight words or lines, this doesn't work as desired.

    >> "man xterm" and grep for "character classes" for how to change that
    >> behavior in xterm.

    > I'd prefer a config file so I can keep the setting.


    xterm, like most old X apps, *has* a config file. It uses X resources
    to store information. X resource information is commonly found in
    ~/.Xdefaults , and is of the form $PROGRAM.$CATEGORY.$SUBCATEGORY:
    setting. This is not the way most new users want to do things, but it
    does work and has persisted through tradition and inertia.

    > One problem I have with X is that when I move the cursor over some
    > text, and try to highlight some text, it usually misses the first
    > character even though I clearly am on that character. I have to move
    > the cursor to in front of the character to be able to highlight it.
    > That I find to be very awkward.


    This is how practically every text-using app has worked since the days
    of MacOS in the 1980s. People like the I-beam and it's become a de
    facto standard.

    > The cursor is a shape of a narrow and tall letter "I". I want a
    > cursor that is a block that fully covers a character and is fully
    > aligned with it (e.g. moves in steps of character cells).


    It'll be easier for you to change your behavior than for you to change
    this aspect of the terminal emulator you're using.

    --
    "Which you then convert to gold, non-perishable food, firearms, good
    liquor & a secluded hideaway in the last of the internet official
    protocol standards" -- MegaHAL (trained on ASR), 1998-11-05
    Matt G|There is no Darkness in Eternity/But only Light too dim for us to see

  7. Re: Two video cards ... separate text and graphical usage

    On 29 Jan 2008 15:19:33 GMT Dances With Crows wrote:
    | phil-news-nospam@ipal.net staggered into the Black Sun and said:
    |> Dances With Crows wrote:
    |>> If your programs are writing lots of junk to stdout, why not redirect
    |>> that stdout to a file?
    |> I do want to see the output. I don't have to be able to read every line
    |> to be able to get an idea what it does.
    |
    | Pipe it through grep, then.

    Seeing the volume of output is often what is telling. Seeing patterns
    in all that output can be informative. Sometimes piping through grep
    for specific data is hopeful. Often not.

    Really, being about to let it "fly" is necessary many times. Today's
    text console is WAY faster than it used to be a decade and a half ago
    when I first started using Linux. And back then I noted that it was
    a lot faster on Linux than on Solaris (crippled by a frame buffer).

    Today, I'm sure in X it is faster than a text console was back then.
    And maybe it is adequately fast enough now. And maybe it can be made
    a bit faster with some optimization, or means to use GPU acceleration
    (e.g. use a GPU buffer copy to do scroll).


    |>>> There are also other details like when doing double and triple
    |>>> clicking to highlight words or lines, this doesn't work as desired.
    |>> "man xterm" and grep for "character classes" for how to change that
    |>> behavior in xterm.
    |> I'd prefer a config file so I can keep the setting.
    |
    | xterm, like most old X apps, *has* a config file. It uses X resources
    | to store information. X resource information is commonly found in
    | ~/.Xdefaults , and is of the form $PROGRAM.$CATEGORY.$SUBCATEGORY:
    | setting. This is not the way most new users want to do things, but it
    | does work and has persisted through tradition and inertia.

    I've always found that method hard to work with from an administrative
    position.


    |> One problem I have with X is that when I move the cursor over some
    |> text, and try to highlight some text, it usually misses the first
    |> character even though I clearly am on that character. I have to move
    |> the cursor to in front of the character to be able to highlight it.
    |> That I find to be very awkward.
    |
    | This is how practically every text-using app has worked since the days
    | of MacOS in the 1980s. People like the I-beam and it's become a de
    | facto standard.

    I might be able to get used to it *IFF* the character it is over when
    the highlighting begins is the first character to be highlighted. But
    it seems the logic is to have it start highlighting only when it hits
    the boundary between letters (and hence will miss the first letter I
    had it on unless I had it at exactly the left edge of that letter).

    Also, quite often the last character is missed. I've wanted it invert
    the characters as I highlight them, including the last, and then just
    unhighlight the last as I let off.


    |> The cursor is a shape of a narrow and tall letter "I". I want a
    |> cursor that is a block that fully covers a character and is fully
    |> aligned with it (e.g. moves in steps of character cells).
    |
    | It'll be easier for you to change your behavior than for you to change
    | this aspect of the terminal emulator you're using.

    Where is that aspect coded? Maybe that is not true. I do know many apps
    do change the shape of the pointer object when moved over that app. So it
    should be possible with a hacked xterm, too. I just need some assistance
    by someone that knows where these things are.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-01-29-2014@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread