Subject: Linux-Development Digest #722
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sun, 15 May 94 23:13:11 EDT

Linux-Development Digest #722, Volume #1         Sun, 15 May 94 23:13:11 EDT

Contents:
  Programming for DPMS monitors - working!! (Christoph Rimek)
  Solaris 2.x for intel binaries. (Matthias Sattler)
  dld for linux? (Reuben Sumner)
  Re: WINE gotta have it (please!!!) (Bob Amstadt)
  Splitvt 1.5.2 moved! (Whistler)
  EISA/PCI Specs? (The Silk Road Group Ltd.)
  Re: Stupid Question (maybe) PCI? (Archie Cobbs)
  Re: Elm 2.4 compilre problem (Sami-Pekka Hallikas)
  seg fault in mkswap with 1.1.11 (Tibor Polgar)

----------------------------------------------------------------------------

Date: 15 May 1994 23:02:00 +0100
From: chrimek@rimki.toppoint.de (Christoph Rimek)
Subject: Programming for DPMS monitors - working!!
Reply-To: chrimek@tpki.toppoint.de

Hello

In my last posting (of 30-apr-94) I published the raw code to support the
new generation of monitors that know the VESA Power Saving Protocol (PSP).
Recently I found the time to code and can now present:

Patch (based on Linux Kernel revision 1.0) for handling the Power Saving
feature of the new monitor generation. The code works on all these monitors
(mine is a Smile 1506) and should run on *all* video adapter cards (change
some i/o-adresses), although tested only on two different VGA-cards: a  
cheap Cirrus Logic (5428) and a miro Crystal 8S (S3-805).

The only affected module is driver/char/console.c and within this the
two functions blank_screen and unblank_screen and a few new variable  
definitions. If activated, the function memsetw is no longer needed.

The file config.in in the main kernel source directory has got two new
variables to define: CONFIG_VESA_PSPM (Power Saving Protocol Monitor)
and CONFIG_PSPM_FORCE_OFF. I have placed these lines into the character
device section right after the SELECTION part. You can choose from two
options:

(1) CONFIG_VESA_PSPM YES to activate these patches.
    The code will save the current setting of your video adapters'
    register settings and then program the controller to turn off
    the vertical sycnchronisation pulse. For details how this is
    achived refer to the code fragments following.

(2) CONFIG_PSPM_FORCE_OFF
    If your monitor locally has an Off_Mode timer then you should not
    force your video card to send the OFF-signal - your monitor will
    power down by itself.
    If your monitor cannot handle this and needs the Off-signal directly,
    or if you like your monitor to power down immediately when the
    blank_timer times out, then you chose this option.

On the other hand I'd recommend to not chose this second option unless
it is absolutely necessary. Powering down a monitor to the Off_State with
an approx. power consumption of 3-5 Watts is a rather strong action for
the CRT and it should not be done every now and then. If the software only  
sends the signal to enter Standby mode, you have the chance to interfere
before the monitor powers down. Do not set a too short period, if you love
your hardware :-)) .

Another advantage of leaving the power down handling to the monitor is
that your always can use the same kernel and change the OFF timeout
locally at your monitor. My model lets me chose the timeout in steps
of five minutes: 0-5-10-15-...


If requested, in the future it may be possible to install another timer
to provide a configurable delay between the two stages Standby and Off
similar to the "setterm -blank"-feature.

After all blah-blah now the diff-outputs for the patches.


================================cut here================================
--- config.in.orig      Mon May  9 17:16:34 1994
+++ config.in   Sun May 15 14:17:41 1994
@@ -116,4 +116,21 @@
 bool 'ATIXL busmouse support' CONFIG_ATIXL_BUSMOUSE n
 bool 'Selection (cut and paste for virtual consoles)' CONFIG_SELECTION y
+:
+:  The following item should only be set to YES (y) if your monitor knows
+:  the VESA Power Saving Protocol and if you have an EGA/VGA card (other
+:  video adapters are untested, but should work too).
+:  ATTENTION: setting this to YES when not appropriate can destroy your
+:             monitor and/or video adapter card !
+:
+bool 'VESA Power Saving Protocol Monitor support' CONFIG_VESA_PSPM n
+if [ "$CONFIG_VESA_PSPM" = "y" ]
+:
+: Some VESA PSP Monitors have a local timer and switch to Power_Off state
+: after a defined period (e.g. 5 minutes) in Standby mode. If your monitor
+: does not have such a timer or if you want to force your monitor to directly
+: go to Power_Off_State, set the following variable to YES (y).
+:
+bool 'Force OFF signal to be sent to VESA PSP Monitor' CONFIG_PSPM_FORCE_OFF y

================================cut here================================
--- console.c.orig      Wed Feb 23 07:52:24 1994
+++ console.c   Sun May 15 19:32:14 1994
@@ -78,6 +78,49 @@
 static char sel_buffer[SEL_BUFFER_SIZE] = { '\0' };
 #endif /* CONFIG_SELECTION */

+#ifdef CONFIG_VESA_PSPM
+/*
+ * This section(s) handles the VESA Power Saving Protocol that let a   *
+ * monitor be powered down whenever not needed for a longer time.      *
+ * VESA protocol defines:                                              *
+ *                                                                     *
+ *  Mode/Status                HSync   VSync   Video                           *
+ *  ----------------------------------------------                     *
+ *  "On"               on      on      active                          *
+ *  "Suspend" {either} on      off     blank                           *
+ *            {  or  } off     on      blank                           *
+ *  "Off"               off    off     blank   <<  PSPM_FORCE_OFF      *
+ *                                                                     *
+ * Original code taken from the Power Management Utility (PMU) of      *
+ * Huang shi chao, delivered together with many new monitor models     *
+ * capable of the VESA Power Saving Protocol.                          *
+ * Adapted to Linux by Christoph Rimek (chrimek@toppoint.de)  15-may-94        *
+ */
+
+#define seq_port_reg   (0x3c4)         /* Sequencer register select port       */
+#define seq_port_val   (0x3c5)         /* Sequencer register value port        */
+#define video_misc_rd  (0x3cc)         /* Video misc. read port        */
+#define video_misc_wr  (0x3c2)         /* Video misc. write port       */
+
+/* structure holding original VGA register settings */
+static struct {
+       unsigned char   SeqCtrlIndex;           /* Sequencer Index reg.   */
+       unsigned char   CrtCtrlIndex;           /* CRT-Contr. Index reg.  */
+       unsigned char   CrtMiscIO;              /* Miscellaneous register */
+#ifdef CONFIG_PSPM_FORCE_OFF
+       unsigned char   HorizontalTotal;        /* CRT-Controller:00h */
+       unsigned char   HorizDisplayEnd;        /* CRT-Controller:01h */
+       unsigned char   StartHorizRetrace;      /* CRT-Controller:04h */
+       unsigned char   EndHorizRetrace;        /* CRT-Controller:05h */
+#endif
+       unsigned char   Overflow;               /* CRT-Controller:07h */
+       unsigned char   StartVertRetrace;       /* CRT-Controller:10h */
+       unsigned char   EndVertRetrace;         /* CRT-Controller:11h */
+       unsigned char   ModeControl;            /* CRT-Controller:17h */
+       unsigned char   ClockingMode;           /* Seq-Controller:01h */
+} vga;
+#endif /* CONFIG_VESA_PSPM */
+
 #define NPAR 16

 extern void vt_init(void);
@@ -1330,6 +1373,9 @@
        }
 }

+#ifndef CONFIG_VESA_PSPM
+/* This function only needed for fast screen buffer filling in */
+/* blank_screen, may be spared if hardware blanks screen.  /CR */
 void * memsetw(void * s,unsigned short c,int count)
 {
 __asm__("cld\n\t"
@@ -1340,6 +1386,7 @@
        :"cx","di");
 return s;
 }
+#endif

 void console_print(const char * b)
 {
@@ -1551,10 +1598,80 @@
        if (console_blanked)
                return;
        timer_table[BLANK_TIMER].fn = unblank_screen;
+
+#ifdef CONFIG_VESA_PSPM
+       /* save original values of VGA controller registers */
+       cli();
+       vga.SeqCtrlIndex = inb_p(seq_port_reg);
+       vga.CrtCtrlIndex = inb_p(video_port_reg);
+       vga.CrtMiscIO = inb_p(video_misc_rd);
+       sti();
+#ifdef CONFIG_PSPM_FORCE_OFF
+       outb_p(0x00,video_port_reg);                    /* HorizontalTotal */
+       vga.HorizontalTotal = inb_p(video_port_val);
+       outb_p(0x01,video_port_reg);                    /* HorizDisplayEnd */
+       vga.HorizDisplayEnd = inb_p(video_port_val);
+       outb_p(0x04,video_port_reg);                    /* StartHorizRetrace */
+       vga.StartHorizRetrace = inb_p(video_port_val);
+       outb_p(0x05,video_port_reg);                    /* EndHorizRetrace */
+       vga.EndHorizRetrace = inb_p(video_port_val);
+ #endif
+       outb_p(0x07,video_port_reg);                    /* Overflow */
+       vga.Overflow = inb_p(video_port_val);
+       outb_p(0x10,video_port_reg);                    /* StartVertRetrace */
+       vga.StartVertRetrace = inb_p(video_port_val);
+       outb_p(0x11,video_port_reg);                    /* EndVertRetrace */
+       vga.EndVertRetrace = inb_p(video_port_val);
+       outb_p(0x17,video_port_reg);                    /* ModeControl */
+       vga.ModeControl = inb_p(video_port_val);
+       outb_p(0x01,seq_port_reg);                      /* ClockingMode */
+       vga.ClockingMode = inb_p(seq_port_val);
+
+       /* assure that video is enabled */
+       /* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
+       cli();
+       outb_p(0x01,seq_port_reg);
+       outb_p(vga.ClockingMode | 0x20,seq_port_val);
+       sti();
+#else
        get_scrmem(fg_console);
        hide_cursor();
+#endif /* CONFIG_VESA_PSPM */
+
        console_blanked = 1;
+
+#ifdef CONFIG_VESA_PSPM
+       cli();
+       /* test for vertical retrace in process.... */
+       if ((vga.CrtMiscIO & 0x80) == 0x80)
+               outb_p(vga.CrtMiscIO & 0xef,video_misc_wr);
+
+       /*  Set <End of vertical retrace> to minimum (0) and            *
+        *  <Start of vertical Retrace> to maximum (incl. overflow)     *
+        *  Result: turn off vertical sync (VSync) pulse                */
+       outb_p(0x10,video_port_reg);            /* StartVertRetrace */
+       outb_p(0xff,video_port_val);            /* maximum value */
+       outb_p(0x11,video_port_reg);            /* EndVertRetrace */
+       outb_p(0x40,video_port_val);            /* minimum (bits 0..3)  */
+       outb_p(0x07,video_port_reg);            /* Overflow */
+       outb_p(vga.Overflow | 0x84,video_port_val);     /* bits 9,10 of  */
+                                                       /* vert. retrace */
+#ifdef CONFIG_PSPM_FORCE_OFF
+       /*  Set <End of horizontal retrace> to minimum (0) and  *
+        *  <Start of horizontal Retrace> to maximum            *
+        *  Result: turn off horizontal sync (HSync) pulse      */
+       outb_p(0x04,video_port_reg);            /* StartHorizRetrace */
+       outb_p(0xff,video_port_val);            /* maximum */
+       outb_p(0x05,video_port_reg);            /* EndHorizRetrace */
+       outb_p(0x00,video_port_val);            /* minimum (0) */
+#endif
+       /* restore both index registers */
+       outb_p(vga.SeqCtrlIndex,seq_port_reg);
+       outb_p(vga.CrtCtrlIndex,video_port_reg);
+       sti();
+#else
        memsetw((void *)video_mem_base, 0x0020, video_mem_term-video_mem_base );
+#endif /* CONFIG_VESA_PSPM */
 }

 void unblank_screen(void)
@@ -1567,9 +1684,41 @@
                timer_active |= 1<<BLANK_TIMER;
        }
        console_blanked = 0;
+
+#ifdef CONFIG_VESA_PSPM
+       /* restore original values of VGA controller registers */
+       cli();
+       outb_p(vga.CrtMiscIO,video_misc_wr);
+#ifdef CONFIG_PSPM_FORCE_OFF
+       outb_p(0x00,video_port_reg);            /* HorizontalTotal */
+       outb_p(vga.HorizontalTotal,video_port_val);
+       outb_p(0x01,video_port_reg);            /* HorizDisplayEnd */
+       outb_p(vga.HorizDisplayEnd,video_port_val);
+       outb_p(0x04,video_port_reg);            /* StartHorizRetrace */
+       outb_p(vga.StartHorizRetrace,video_port_val);
+       outb_p(0x05,video_port_reg);            /* EndHorizRetrace */
+       outb_p(vga.EndHorizRetrace,video_port_val);
+#endif
+       outb_p(0x07,video_port_reg);            /* Overflow */
+       outb_p(vga.Overflow,video_port_val);
+       outb_p(0x10,video_port_reg);            /* StartVertRetrace */
+       outb_p(vga.StartVertRetrace,video_port_val);
+       outb_p(0x11,video_port_reg);            /* EndVertRetrace */
+       outb_p(vga.EndVertRetrace,video_port_val);
+       outb_p(0x17,video_port_reg);            /* ModeControl */
+       outb_p(vga.ModeControl,video_port_val);
+       outb_p(0x01,seq_port_reg);              /* ClockingMode */
+       outb_p(vga.ClockingMode,seq_port_val);
+
+       /* restore index/control registers */
+       outb_p(vga.SeqCtrlIndex,seq_port_reg);
+       outb_p(vga.CrtCtrlIndex,video_port_reg);
+       sti();
+#else
        set_scrmem(fg_console);
        set_origin(fg_console);
        set_cursor(fg_console);
+#endif /* CONFIG_VESA_PSPM */
 }

 void update_screen(int new_console)
@@ -1841,8 +1990,10 @@
 #define colourmap ((char *)0xa0000)
 #define blackwmap ((char *)0xb0000)
 #define cmapsz 8192
+#ifndef seq_port_reg   /* avoid re-definition */
 #define seq_port_reg (0x3c4)
 #define seq_port_val (0x3c5)
+#endif
 #define gr_port_reg (0x3ce)
 #define gr_port_val (0x3cf)
================================cut here================================


That's all.
I'm not sure whether it is necessary to encapsule the saving of the video
adapter registers in a cli/sti-pair, while this code comes to execution
only when the machine (keyboard) is idle. When setting the registers I
think it is better not to allow any interruption of the sequences.

Please let me know about your experiences with this code.

-cr


--
Christoph Rimek, Kiel, Germany  (+49 431 18307)      chrimek@toppoint.de

------------------------------

From: sattler@unix-ag.uni-kl.de (Matthias Sattler)
Subject: Solaris 2.x for intel binaries.
Date: Fri, 13 May 1994 19:33:39 GMT

Is someone out there working on binary support for Solaris 2.x for intel?
It should be possible as solaris uses the elf binary format that is already
supported by the kernel as far as I know.

                                        Matthias

-- 


******************************************************************************
******************************************************************************

... The things love can drive a man to -- the ecstasies, 
the miseries, the broken rules, the desperate chances, the glorious
failures and the glorious victories.
                -- McCoy, "Requiem for Methuselah", stardate 5843.7

******************************************************************************
******************************************************************************

Matthias Sattler 
email: sattler@unix-ag.uni-kl.de
Phone: GERMANY 06333/65079 (always)
          "    06333/63175 (at reasonable times only)


And always remember:
                        When all else fails, read the instructions.


------------------------------

From: rasumner@undergrad.math.uwaterloo.ca (Reuben Sumner)
Subject: dld for linux?
Date: Sun, 15 May 1994 22:29:42 GMT

More than once I have seen mention here of using dld to accomplish
dynamic linking.  However sunsite does not have dld and the version
on prep.ai.mit.edu does not support linux.  Has anyone ported it?
I doubt if I know enough to port it but I might give it a try.
What I wanted to do with it was to create a terminal program
(or extend minicom) to use .o files as compiled scripts which
would ten interact with functions provided by the terminal
program.  I would hope to have the same flexibility as including
a stack based simulator in the program but with much greater
speed and less programming effort.

Reuben

------------------------------

From: bob@hh.sbay.org (Bob Amstadt)
Subject: Re: WINE gotta have it (please!!!)
Date: 10 May 1994 07:55:57 -0700

In <2qluo5$2jn@eagle.lerc.nasa.gov> mshann@hyperthink.lerc.nasa.gov (Ray Hann) writes:
>Does WINE really exists?

Yes, Wine really exists.  Unfortunately (or perhaps fortunately) the project
began from public dicussions.  As a result, people have wanted it since it
was first announced that we were going to try doing it.  The project will
be only a year old next month.  We have accomplished much, but not enough
to run any of the popular applications.

We do welcome any help.

------------------------------

Crossposted-To: comp.os.linux.misc
From: slouken@cs.ucdavis.edu (Whistler)
Subject: Splitvt 1.5.2 moved!
Date: Sun, 15 May 1994 23:53:16 GMT


        The newest version of splitvt has moved!
It can now be found on sunsite.unc.edu in the /pub/Linux/utils/terminal
directory.

Files with the .shz extension can be decoded with the command

        gzip -cd file.shz | sh


Here is the original announcement for splitvt:

Announcing Splitvt version 1.5.2 !

What it is:

        Splitvt is a UNIX utility designed to split your screen in
half, running a shell (or the program of your choice) in each half.
This can be very handy if you want to see the results of two programs
at the same time, but don't have X, or, if you want to work in two
windows at the same time over a modem.
Some people even like to run splitvt in X, just to have two programs
running in the same window.
Splitvt is a complementary utility to that great program 'screen',
and can be used in combination with it to have a variety of split
virtual screens.

What's New:

        Splitvt has a few new features since version 1.5.
There is now a -norc option to suppress startup from your custom
.splitvtrc startup file.
The top and bottom bars have been removed to give your screen
more real estate.
Splitvt now supports some obscure features of xterm that allow you 
to click your mouse in the window of your choice, eliminating the 
need for you to hit those pesky control keys to switch windows.
(Note: this feature is only available to true xterms)

Where you can get it:

        You can get this program via anonymous ftp from
sunsite.unc.edu in the directory /pub/Linux/utils/terminal. 
The file is in a gzipped-shar archive, and can be uncompressed
with the following command line:

        gzip -cd file.shz | sh

If for some reason, you cannot ftp it, then feel free to send
me email at slouken@cs.ucdavis.edu and I will be happy to send
it to you.


Troubleshooting:

        You shouldn't have any problems compiling splitvt
if you are on a UNIX system that supports pseudo-terminals.
If you are on a UNIX box, chances are good that you can 
compile it.  Look in the README file in the archive for a list
of systems splitvt is known to work on.

        By far the most common problem people have had is
splitvt not being able to open enough pseudo-terminals (ttys).
This can be caused by many things.  If your system isn't one
in the README, it might be that your system handles pseudo-
terminals differently than any I know.  Often, not being able
to open enough ptys is caused by too many users on the system
or too many pty-intensive applications running (these include
xterm, screen, telnetd, expect, etc).  If this happens, try
waiting a while and try again.  Another problem that can occur
on some systems is pty hanging.  This can happen when applications
quit and go into a zombie state, or if the kernel gets confused
about the state of the pty.  Generally, if you can, try to
reboot.  This clears all of the hung ptys.
A good telltale to whether or not lack of ptys is splitvt's
problem is to rlogin a few times to your local system.  If you
are able to log in properly (without a message like 
"rlogind: out of ptys"), then the problem is probably with splitvt.

        That said, most people have very few problems with
splitvt, and I hope you are among them that enjoy my fine utility.

Oh, the idea for this utility came from the brain of Daveola Ljung.
Thanks Dave!

If you have any questions, comments, complaints, cash, ;-)
send me email at slouken@cs.ucdavis.edu

Enjoy!

        -Sam


------------------------------

From: bass@cais.com (The Silk Road Group Ltd.)
Subject: EISA/PCI Specs?
Date: 16 May 1994 00:29:52 GMT


As a EE turned into a Unix person for the past 5 years, I am dreaming about
building H/W devices for LINUX and writing the drivers.  Anyone one
know a good book that discusses the EISA bus or/and PCI bus specs and
how to build cool boards that will interface to my new LINUX/P60 PCI/EISA
system?

E-mail me at bass@silkroad.com and I will summarize...

Tim


------------------------------

From: archie@qin.CS.Berkeley.EDU (Archie Cobbs)
Subject: Re: Stupid Question (maybe) PCI?
Date: 13 May 94 20:27:55 GMT

stevek@panix.com (Steve Kann) writes:

>I know this is probably a FAQ by now, but is there any support by the
>kernel for PCI busses?

Yes, PCI works transparently as far as Linux is concerned.
Check out the PCI-Howto...

-Archie


------------------------------

From: semi@dream.nullnet.fi (Sami-Pekka Hallikas)
Subject: Re: Elm 2.4 compilre problem
Date: Sun, 15 May 1994 04:54:23 GMT

Thomas Quinot (thomas@melchior.frmug.fr.net) wrote:
> Sami-Pekka Hallikas (semi@dream.nullnet.fi) wrote:
>> ld -dll-verbose -m486 -s -o ../bin/elm -L/usr/lib/gcc-lib/i486-linux/2.4.5 \
> Remove "-s". May or may not work... Please report :-)

Nope.. Problem was that make didn't run ranlib for that elm lib[something].a
and that's why it "crash". So I fixed that part and elm works really fine.

--
+--------------------------+----------+-------------------------------------+
| semi@dream.nullnet.fi    |  OH1KYL  | MAIL MEDIA. Do Not Expose to Flame! |
| samip@freeport.uwasa.fi  +----------+-------------------------------------|
| semi@freenet.hut.fi      |  Dream World BBS * 358-21-4389843 * 24H * 9600 |
+---------------------------------------------------------------------------+
+-         Linux version 1.0.8 (semi@dream.nullnet.fi) #1 16-Apr-94        -+
+-   Linux.  A copylefted Unix-like operating system for the 386 and 486   -+
+---------------------------------------------------------------------------+

------------------------------

From: tlp00@mtlyell.spg.amdahl.com (Tibor Polgar)
Subject: seg fault in mkswap with 1.1.11
Date: Fri, 13 May 1994 19:03:45 GMT

I don't have the "oopps" output, just wondering if others have had trouble in
1.1.11 with  mkswap.  i have the buslogic scsi driver, procps patches.  running
with 1.0.9 works fine.  I'll try and back off to a lower patch level to see if
its level specific.

-- 
Tibor Polgar
tlp00@spg.amdahl.com, Amdahl Corp, ph.(408) 944-3500

-- all disclaimers apply  --

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
