Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

hello monks i would like to find out if there are any perl modules for separatly controlling two different monitors linked to a dual monitor video card we currently have a system where a program entirely written in C controls one monitor through STDOUT and an old style terminal through the serial port (pretty old school i know but we only need to send text to the serial port) our system works fine and has done for years but it has occured to us that one of these days the old terminal is going to give up the ghost and its going to be pretty hard to find a replacement (we have one fairly flaky spare) so we figured that if there is a way to separatly control dual monitors from perl sending the STDOUT to one and our other text to the other we could imbed the perl interpreter in our original C and future proof our archaic system! is this even vaguely a good idea? possible? is it really that easy to embed perl in C? i don't know enough about perl to answer any of these questions but would like to know

Replies are listed 'Best First'.
Re: contolling two screens
by samizdat (Vicar) on Aug 23, 2005 at 12:37 UTC
    You didn't say whether this is on Doze or X Window System on some flavor of UNIX. If it is 'NIX, then you can tell your Window manager which display to write to when you pop a window open. Once it's open, it's a filehandle like any other. You'll need to use a windowing toolkit with your Perl (or C, for that matter). and CPAN has a whole slew of helpful modules (look under User Interfaces) that you can use to talk directly to X and to the Windowing toolkit of your choice (Tk, Gtk, Qt, etc.) on top of it. A reasonably simple one to look at is X11::Fvwm, which talks directly to a simple X window manager with Display-shifting ability.

    Someone else will have to help you if it's a Doze system; you can set up multiple monitor cards in Windows and I suspect the place to start would be the ActiveState docs.

    In any case, your goal is a good one, and welcome to the Perl community!
Re: contolling two screens
by robot_tourist (Hermit) on Aug 23, 2005 at 11:13 UTC

    A better list of requirements would be good. I don't know why you need two screens when you can use a terminal emulator in Windows (or your OS of choice)

    How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
    Robot Tourist, by Ten Benson

      Have you ever had to run a debugger or see some real-time status information while the main screen is filled with a graphics window? Say you're writing a 3D first-person game or an immersive flight simulator, or making improvements to the X11 renderer, and you can't display one of your fancy terminal emulators at the moment. You want to print out a portion of the scene graph, or you need to single-step through some tricky logic. Solution: a second screen, often one which doesn't depend on cooperation from the GUI subsystems.

      Though my example may not be the original poster's intention, there are are many good reasons to have a barebones display on a separate screen. There's a reason those terminal programs are called emulators-- they only strive for the ideal.

      --
      [ e d @ h a l l e y . c c ]

        So, if you don't care about the GUI subsystems and I guess anonymous doesn't care in this case if he or she is using an old-skool terminal, use your preferred multiple screen enabled GUI and multiple output enabled video card.

        And if you do care, then I assume you have to do it low-level on your video card. Although I am unaware if anyone has done this before, but it seems logical to assume that someone has, if anonymous wants to do some research.

        How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
        Robot Tourist, by Ten Benson

Re: contolling two screens
by anonymized user 468275 (Curate) on Aug 23, 2005 at 11:55 UTC
    The short answer is 'yes' but in my opinion the term 'embedded' means different things to different people. However, here is some extensive documentation perlembed

    One world, one people

Re: contolling two screens
by mattr (Curate) on Aug 23, 2005 at 16:52 UTC
    IO::Tty maybe in unix or cygwin?

    Need more info. Your description is unfortunately confusing. Is it the case that you have a dual-headed video card of which you are only using one of the heads to show a text-based screen, and you also have a secondary dumb vt100 terminal hooked up to serial output?

    If you are talking about throwing out the vt100 terminal and using modern displays on both heads then you just need to start up your program on the other display. If you are running two unix curses displays maybe the IO::Tty module is what you want. Or read the X server comment above.

    Incidentally I have not used it but you might want to check Ultramon a (free I believe) multimonitor window manager for windows, if that's what you are using. My understanding is that basically you get a single desktop spanning the two monitors, not like with two separate X sessions (could be both are possible with XP..), and that you can set an app to open on a given monitor (or perhaps use a script if you have ultramon). In which case perl would think it is just a window on your desktop, and you could move the window to a certain position with a gui library (like Wx::Perl I suppose). Possibliy you could read Ultramon's library and script in Perl though they talk about Jscript and Basic stuff. Please describe setup and exactly what you want to do if this doesn't help.

Re: contolling two screens
by danmcb (Monk) on Aug 23, 2005 at 18:39 UTC

    It sounds like overkill. It is no problem to replace an old style terminal that displays characters coming over an RS232 interface. You just need a PC with a terminal program, such as Hyperterminal, or whatever the Linux equivalent is called. Unless I am misunderstanding your requirements hugely. Any old 486 or less PC that someone will almost pay you to take away will do it.

    (Serial ports and monitors are more future proof than you think ... at least for now ;-)