linuxconsole-dev

[Linuxconsole-dev] 40K posting limit.

[James S. <jsi...@ac...>]

I just tried to post a pretty good size patch. Their is a 40K limit to let
you know.

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] console_codes(4) is updated

[James S. <jsi...@ac...>]

  James Simmons <jsi...@ac...> writes:

> Post your patch please. Do you have any links to your work ?

We have a web page at www.braille.uwo.ca/speakup which has links to
the various files and programs that comprise speakup.  I will include
below the patches for speakup-0.08 which is the latest official
release.  I have many more drivers and things I am working on but I
would like to commit that stuff once I have more of the bugs squashed
a newer features built-in.  There will be some stuff in these which I
can also clean out because it is basically commented out cruft and
debugging code.

  Kirk

------------------------------------------------------------------------
diff -urN linux-2.3.8/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.3.8/Documentation/Configure.help	Thu Jun 17 04:11:35 1999
+++ linux/Documentation/Configure.help	Wed Jun 23 14:58:03 1999
@@ -8961,7 +8961,63 @@
   If you are asked this question, something is wrong with config scripts.
   Zilog serial driver is always enabled in sparc architecture.
 
-Double Talk PC internal speech card support
+Speakup console speech output for Linux
+CONFIG_SPEAKUP
+  Choosing this Option will include support for console speech output.
+
+  Speakup provides access to Linux for the visually impaired community.
+  It does this by sending console output to a number of different
+  hardware speech synthesizers.  It provides access to Linux by Making
+  screen review functions available such as are used in comercial screen
+  review packages for the MSDOS and MSWINDOWS world.
+
+  The drivers supplied under this option are not standard devices in the
+  /dev/ sence of the meaning.  They can be thought of as a video card
+  for the blind.  They are used by speakup and only speakup.
+
+  For more information about speakup and its drivers check out
+  http://www.braille.uwo.ca/speakup, or read the Documentation in
+		linux/Documentation/speakup.
+
+  The current synthesizers supported are:
+     DoubleTalk PC Internal synthesizer,
+     LiteTalk/DoubleTalk-LT external serial synthesizers,
+     Speakout external synthesizer,
+     Accent PC internal synthesizer.
+
+  If you do not have one of these synths, say 'N' to this option.
+
+DoubleTalk driver for speakup.
+CONFIG_SPEAKUP_DTLK
+  The DoubleTalk synthesizer is made by RC Systems.  It is an internal
+  ISA card which uses no interrupts.  Do not confuse this driver with
+  the standard DoubleTalk driver included in the kernel.
+
+  If you don't have a DoubleTalk card say 'N' here.
+
+LiteTalk/DoubleTalk-LT driver for speakup.
+CONFIG_SPEAKUP_LTLK
+  This driver is for the LiteTalk synthesizer made by MicroTalk or the
+  DoubleTalk-LT synthesizer made by RC Systems.  These are serial
+  drivers for those external synths.
+
+  If you don't have a LiteTalk or DoubleTalk-LT, say 'N' here.
+
+Speakout driver for speakup.
+CONFIG_SPEAKUP_SPKOUT
+  This driver is for the Speakout external serial synthesizer made by
+  GW Micro.  
+
+  If you don't have a Speakout, say 'N' here.
+
+Accent PC driver for speakup.
+CONFIG_SPEAKUP_ACNTPC
+  This driver is for the Accent PC internal synthesizer made by Aicom
+  Corp.
+
+  If you Don't have an Accent PC, say 'N' here.
+
+Double Talk PC internal speech card support 
 CONFIG_DTLK
   This driver is for the DoubleTalk PC, a speech synthesizer
   manufactured by RC Systems (http://www.rcsys.com/).  It is also
diff -urN linux-2.3.8/Documentation/speakup/DefaultKeyAssignments linux/Documentation/speakup/DefaultKeyAssignments
--- linux-2.3.8/Documentation/speakup/DefaultKeyAssignments	Wed Dec 31 19:00:00 1969
+++ linux/Documentation/speakup/DefaultKeyAssignments	Tue Sep 21 08:51:40 1999
@@ -0,0 +1,43 @@
+This file is intended to give you an overview of the default keys used
+by speakup for it's review functions.  You may change them to be
+anything you want but that will take some familiarity with key
+mapping.
+
+We have remapped the insert or zero key on the keypad to act as a
+shift key.  Well, actually as an altgr key.  So in the following list
+InsKeyPad-period means hold down the insert key like a shift key and
+hit the keypad period.
+
+KeyPad-8		Say current Line
+InsKeyPad-8		say from top of screen to reading cursor.
+KeyPad-7		Say Previous Line (UP one line)
+KeyPad-9		Say Next Line (down one line)
+KeyPad-5		Say Current Word
+InsKeyPad-5		Spell Current Word
+KeyPad-4		Say Previous Word (left one word)
+InsKeyPad-4		say from left edge of line to reading cursor.
+KeyPad-6		Say Next Word (right one word)
+InsKeyPad-6		Say from reading cursor to right edge of line.
+KeyPad-2		Say Current Letter
+InsKeyPad-2		say current letter phonetically
+KeyPad-1		Say Previous Character (left one letter)
+KeyPad-3		Say Next Character (right one letter)
+KeyPad-plus		Say Entire Screen
+InsKeyPad-plus		Say from reading cursor line to bottom of screen.
+KeyPad-Minus		Park reading cursor (toggle)
+InsKeyPad-minus		Say character hex and decimal value.
+KeyPad-period		Say Position (current line, position and console)
+InsKeyPad-period	say colour attributes of current position.
+InsKeyPad-9		Move reading cursor to top of screen (insert pgup)
+InsKeyPad-3		Move reading cursor to bottom of screen (insert pgdn)
+InsKeyPad-7		Move reading cursor to left edge of screen (insert home)
+InsKeyPad-1		Move reading cursor to right edge of screen (insert end)
+KeyPad-Enter		Shut Up (until another key is hit) and sync reading cursor
+InsKeyPad-Enter	Shut Up (until toggled back on) and sync cursors
+InsKeyPad-star n<x|y> go to line (y) or column (x). Where 'n' is any
+		allowed value for the row or column for your current screen.
+
+Hitting any key while speakup is outputting speech will quiet the
+synth until it has caught up with what is being printed on the
+console.
+
diff -urN linux-2.3.8/Documentation/speakup/INSTALLATION linux/Documentation/speakup/INSTALLATION
--- linux-2.3.8/Documentation/speakup/INSTALLATION	Wed Dec 31 19:00:00 1969
+++ linux/Documentation/speakup/INSTALLATION	Tue Nov 23 08:04:38 1999
@@ -0,0 +1,104 @@
+This document assumes you have had some experience with kernel
+compilation and installation.  If you have not, I recommend you get
+the kernel source and read the README and various documents in the
+linux/Documentation directory.  In particular the Changes file to make
+sure you have the appropriate utilities needed for installing a 2.2.xx
+or 2.3xx kernel.  It isn't as difficult as you might think.  The
+kernel README is intimidating the first time but once you get the
+steps down, it's really pretty easy.  Getting through the "make
+config" is the tedious bit.
+
+The first thing to do is to place a copy of the patch in the /usr/src
+directory which is the directory the linux tree is located in as well.
+To apply the patch if you are using speakup-0.08-patch say, type the
+following at your shell prompt:
+
+patch -p0 <speakup-0.08-patch
+
+Note the less-than sign before the patch file name.  The patch program
+will give a running commentary on the patch hunks being applied.  It
+will give a summary of the hunks which succeeded or failed in being
+applied.  Hopefully all hunks will succeed.  Depending on how
+experienced you are with kernel compiling and hacking will determine
+whether you should bother looking at any failed patches.  If this
+happens, you should probably write to the speakup mailing list for
+help or myself.
+
+If all of the patch hunks apply successfully then just continue with
+the standard steps to compile the kernel with:
+
+make mrproper
+make config
+
+When you get to the section console speech output, answer 'y' to the
+CONFIG_SPEAKUP prompt.  You will be given a submenu with the list of
+synthesizers which are currently supported.  You can only choose one
+of the synths, so just type dtlk or whatever is the correct string for
+the synthesizer you have.
+
+I have placed the speakup configuration options in make config just
+before the DoubleTalk PC driver included by Jim Van Zandt.  I recommend
+you say no to that option after returning from the speakup menu.  I
+have not tried configuring them both in, but I wouldn't be at all
+surprised if it didn't work.
+
+If all goes well up to this point you can continue with the compiling
+process by doing:
+
+make dep >dep.file 2>&1 &
+make zImage >cc.file 2>&1 &
+
+I always redirect output to the files dep.file and cc.file so I can
+look over the compilation record to make sure there are no errors and
+warnings.
+
+Okay, you are ready to install the newly compiled kernel.  Make sure
+you make an linux.old entry in your lilo.conf file so you can recover
+if it blows up.  next move the zImage from
+/usr/src/linux/arch/i386/boot to wherever your kernel lives.  Also
+move the System.map from /usr/src/linux to where your System.map
+lives.  On our systems we use debian so we create an vmlinuz-speakup
+and System.map-speakup in our /boot directory and set the symbolic
+links vmlinuz and System.map in the root (/) directory to point to the
+images.  Now type lilo to tell lilo to build the new booter file and
+install it.
+
+As of version 0.07, the keymap for speakup is automatically built in
+at compile time.  If you have other keymaps installed at boot time,
+you might want to consider removing them before you reboot the system.
+Also if you have compiled the kernel prior to applying the speakup
+patch, you have to remove the defkeymap.c file which is in the
+linux/drivers/char directory.  This file is not rebuilt if one already
+exists.  So if you find you have no review functions upon rebooting,
+you know where to check first.
+
+If everything has gone OK up until now, cross your fingers and type:
+
+shutdown -r now
+
+Your system should start talking to you as soon as it starts booting.
+It will talk and talk and ... well, you might want to hit the
+keypad-enter key to tell it to shut up.  You should also read the
+DefaultKeyAssignments file to learn the various review functions
+available.
+
+As of Speakup-0.05, there are accompanying utilities which will allow
+you to load and dump speakups configuration information.  These
+utilities are in the subdirectory load_spk-version and have their own
+README and INSTALL files.  You should read through these files before
+building the utilities and installing them.  The utilities are based
+on the idea of loadkeys so they work somewhat the same.  The
+configuration file commands are a little weird to get used to at
+first, but once you understand them you'll hopefully realize they are
+very flexible.
+
+I have probably managed to overlook a whole whack of things because
+this is the, enter version number here, draft.  Don't worry we'll get
+it right eventually.  If you like the package you really should get on
+the mailing list and start participating in it's development.
+
+  Kirk
+
+email: ki...@br...
+phone: (519) 679-6845 (home)
+
diff -urN linux-2.3.8/Documentation/speakup/README-0.08 linux/Documentation/speakup/README-0.08
--- linux-2.3.8/Documentation/speakup/README-0.08	Wed Dec 31 19:00:00 1969
+++ linux/Documentation/speakup/README-0.08	Tue Nov 23 08:34:31 1999
@@ -0,0 +1,94 @@
+Welcome to the speakup project for the Speakup speech package for Linux.
+
+Speakup is written by Kirk Reiser and Andy Berdan.  It is licensed
+under the GPL.  If you don't already know, the GPL stands for the GNU
+Public License.  Which basically states that this code is free to
+copy, modify and distribute to anyone interested in playing with it.
+The one thing you may not do is turn any part of it into proprietary
+or commercial code without the permission of the author.  That's me.
+
+If you are interested in being involved with the development of speech
+output for Linux you can subscribe to the Speakup mailing list by
+sending a message to lis...@br... with the line:
+
+subscribe speakup (YourFirstName YourLastName)
+
+in the body of the message.
+
+We are at a very early stage in the development of this package.
+Hopefully changes will happen often and many.  The current files in
+this directory are:
+
+BUGS				# the currently known bugs
+COPYING 			# The GPL
+Changes				# The fixes and goodies since last release
+DefaultKeyAssignments		# speakup's default review keys
+INSTALLATION			#  for installing speakup
+README				# this file
+speakupmap.map			# keyboard map for speakup functions.
+keymap-tutorial			# a tutorial on how to layout the keyboard
+load_spk-0.6			# directory with the loadspk and dumpspk utilities.
+speakup-0.08-patch	# patches to kernel versions 2.2.7 and above.
+speakup-0.08-announcement the announcement for the current release
+
+Read the INSTALLATION file to learn how to apply the patches and the
+default.map for the keyboard.  You should also read the Changes file.
+It really has any new things I've added since last time.
+
+There is no documentation in any of these files to instruct you what
+to do if something goes wrong with the patching or compilation.  If
+you would like that information you will need to subscribe to the
+mailing list and ask for help, or write me ki...@br... for
+help.  I suggest the mailing list because I will probably tire quickly
+of answering the same questions over and over.  You could always
+decide to wait until this package gets out of the alpha stage and
+there will be more documentation by that time.
+
+There also is a speakup reflector for the Speak Freely package, which
+many of us hang out on and discuss all sorts of topics from speakup
+problems to ALSA driver installation and just about anything else
+you'd like to talk about.  The reflector is at lwl.braille.uwo.ca:4074
+with it's lwl page at lwl.braille.uwo.ca/speakup.html.  Come and join
+us, it's fun!
+
+Acknowledgements:
+
+I am really very new at kernel hacking and screen review package
+writing, so I have depended heavily on other folks kindness to help me
+a long.  No doubt I will continue to abuse them freely and others
+before this is a really good speech solution for Linux.  (Oh Well!,
+somebody's got to do it.)
+
+Theodore Ts'o.  He gave me a good discussion of unicode and UTF and
+the like.  He doesn't even remember writing me about it.
+
+Alan Cox.  He has answered many questions about scheduling and wait
+queues and timers along with code fragments and so on.  I just wish I
+understood it all totally.
+
+Martin Mares.  He pointed me in the right direction to figuring out
+the colour attributes and other useful tidbits.
+
+Paul McDermott.  He really is the catalyst for me to actually get
+this all working.  Besides I like seeing him bounce around and get all
+excited every time I have something new working.
+
+John Covici, He was the first person to actually attempt writing
+another synthesizer driver for speakup.  It was the Speakout driver so
+it was also the first serial driver.
+
+Brian Borowski, he was the first person to actually write a speakup
+function other than Andy and I.
+
+Gene Collins, he was very helpful debugging the current release prior
+to its public showing.  He has also worked hard educating others on
+the list and writing the ALSA mini howto.
+
+There are probably many more I am forgetting right now.  I guess I'll
+just have to add you all later.
+
+
+Happy Hacking!
+
+  Kirk
+
diff -urN linux-2.3.8/Documentation/speakup/README.loadspk linux/Documentation/speakup/README.loadspk
--- linux-2.3.8/Documentation/speakup/README.loadspk	Wed Dec 31 19:00:00 1969
+++ linux/Documentation/speakup/README.loadspk	Wed Jun 23 14:58:04 1999
@@ -0,0 +1,80 @@
+Speakup v0.07 & Loadspk v0.03
+-----------------------------
+
+Speakup and Loadspk work very closely together.  Each one more or less depends
+on the other to work flawlessly.
+
+So, when changing any synth symbol headers, (symbol*.h), you must also change
+the corresponding headers in the loadspk source (same names).  They both
+include standard definitions which get translated into the kernel proper
+and/or into the client programs.
+
+Required defines (in both kernel and loadspk):
+----------------------------------------------
+	VERSION_x		where 'x' is one of the synth names displayed
+	NUM_STATIC_x		in symbols.h (DTLK,ACNTPC or SPKOUT)
+	NUM_XTEND_x
+	NUM_ALIAS_x
+
+	STATIC_STR_x
+	XTEND_STR_x
+	ALIAS_STR_x
+
+Required only in kernel:
+------------------------
+	DEFAULT_STATIC_x
+	DEFAULT_XTEND_x
+
+-------------------------------------------------------------------------
+
+All of these get built into the various larger structures, depending on
+which synth is specified/detected.  Take a look at symbols.h (in either the
+kernel or loadspk source) if you're curious.
+
+-------------------------------------------------------------------------
+
+The spk_variable Structure
+
+struct spk_variable {
+	char *id;	/* command as displayed in loadspk/dumpspk */
+	char *param;	/* value of the parameter to the command */
+	char *build;	/* a string, describing how to construct the 
+			 * string sent to the synth, with the character '_' 
+			 * to be filled in with the parameter.  eg.  "\x01_P"
+			 * will convert to "\x01+30P", if param is "+30"
+			 */
+	int flags;
+	char valid[33];	/* "-1"-terminated set of valid values for param 
+			 * an empty set { -1 }, signifies that it is a string
+			 *   literal variable
+			 */
+};
+
+Usage examples:
+---------------
+
+Example 1.
+
+{ "rate", "9", "\x1bR_", HARD_DIRECT, "0123456789ABCDEFGH\xff" }
+
+would allow loadspk to use the command:
+	rate = $
+where '$' was any of 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,H
+and, upon input, would immediately send "\x1bR$" to the hardware device,
+as well as setting the appropriate variable in Speakup.  If $ is empty,
+"\x1bR9" is sent to the synth.
+
+
+
+Example 2.
+
+{ "pitch", "50", "\x1_p", (NUMERIC | HARD_DIRECT | USE_RANGE), { 0, 99, -1 } }
+
+would correspond to loadspk using the command:
+	pitch = $
+where '$' was a string representing a numeric value in the range 0-99.  It would
+also be sent directly to the hardware as an ascii string (the NUMERIC flag
+ensures this).  If 'pitch=' was entered, then "01h 50p" would be sent to the
+synth (that is, ctrl-A followed by "50p").
+
+
diff -urN linux-2.3.8/Documentation/speakup/keymap-tutorial linux/Documentation/speakup/keymap-tutorial
--- linux-2.3.8/Documentation/speakup/keymap-tutorial	Wed Dec 31 19:00:00 1969
+++ linux/Documentation/speakup/keymap-tutorial	Thu Apr 29 12:24:18 1999
@@ -0,0 +1,140 @@
+		       Speakup Keymap Tutorial
+
+This is meant to be a basic tutorial on how to change the Linux keymap
+file to assign speakup review functions to desired keys.  It is not
+intended to be a replacement for the loadkeys(8) or keymap(5) man
+pages.
+
+The basic lay-out of the keymap file is a series of lines with the
+following fields.  The keyword keycode indicates this is the start of
+a new key assignment.  It is then followed by a number which
+represents the actual key on the keyboard.  That number is followed by
+the equals '=' operator and finally a list of keywords representing
+key names such as keypad5.  Each line can have quite a few key
+functions on it.  They are interpreted by loadkeys in order and
+assigned to key shift states depending on the order they are
+encountered.  So for example, the first value after the equals is the
+keys unshifted state, while the second is the keys shifted state.  If
+you wish to learn the order they are interpreted in read the
+loadkeys(8) and keymap(5) man pages.
+
+You can have subsequent lines which are indented and start with
+another keyword for the various shifted states.  This way you can
+assign some of the states without having to specify them all in order
+up until you get to the one you want to assign.
+
+In speakup, we have assigned the insert key on the number pad to the
+altgr keyword.  This is not required; you could choose any other
+shifted state keyword.  We used altgr because it typically represents
+the right hand alt key.  In Linux each shift key is separate and
+independent, so the left shift and the right shift keys are not
+necessarily the same.  The altgr key is not really used for anything
+important, so we steel it.
+
+Here are the default key assignments for the number eight on the
+keypad:
+
+keycode  72 = KP_8            
+	alt     keycode  72 = Ascii_8         
+
+As you can see, the first line starts with keycode followed by 72
+which is the actual number assigned to the key when the keyboard port
+is read.  The KP_8 after the equal sign, is the symbolic representation
+of the function called when that key is hit.
+
+The second line is the same format except it starts with the keyword
+alt which is indented.  That means that the function at the end of
+that line Ascii_8 is applied to the alt-shifted eight key.
+
+Now here are the speakup assignments for that key:
+
+keycode  72 = 0x0d0a
+	altgr keycode 72 = 0x0d20
+#keycode  72 = KP_8            
+	alt     keycode  72 = Ascii_8         
+
+Notice that the only thing which has changed on the first line is the
+function called when the key is struck.  It is a hexadecimal number
+identifying the function called in a look up table.  It is not a
+symbolic representation yet because that means we need to change the
+loadkeys program to understand our symbolic names.  We will do this in
+the future but for now it is more expedient to just use the table
+indices.  You will find a table at the bottom of this document
+listing the review functions and their corresponding hex lookups.
+
+The 0x0d0a in the first line above is speakup's say line function.
+The second line ends with 0x0d20 which is speakup's read from top of
+screen to reading cursor line.
+
+The third line is the original key assignment commented out with a
+number-sign '#' at the beginning.  I do that so I can easily find the
+keys I want to affect by symbolic name.  Otherwise I would need to
+keep a look up table for all the keycodes.  I recommend you do this as
+well or you'll be very sorry at some point in the future.
+
+The forth line is just the standard key assignment for the left hand
+alt key.
+
+Now let's say we want to design a different keyboard layout.  I'll use
+an example for the JAWS style keypad because I've specifically been
+asked to help with that.  JAWS uses the eight on the keypad to move up
+a line or the speakup function to read previous line.  JAWS also uses
+the keypad_8 key in a shifted mode to read the current line.  I
+apologize if these are not quite right.  It has been a long time since
+I used JAWS.  So we would have the following two lines:
+
+keycode  72 = 0x0d0b
+	altgr keycode 72 = 0x0d0a
+
+The hex value 0x0d0b in the first line is speakup's SAY_PREVIOUS_LINE
+function.  The 0x0d0a in the second line is the same say_line function
+as we had earlier.  So when the number eight is hit on the keypad
+speakup will read the previous line and when the number eight is
+shifted with the insert key on the keypad it will read the current
+line.
+
+As you can tell, it is not really very difficult to reassign the keys
+to different review functions.
+
+Once you have carefully edited the keymap file, called default.map in
+the speakup distribution, you copy it into the /etc/kbd directory.
+Make sure you back up the original default.map from that directory
+first, if there is one.  Then you run loadkeys to load the new map
+into the kernel:
+
+loadkeys /etc/kbd/default.map
+
+If you wish to build your new keyboard lay-out into the kernel, after
+testing it, copy the default.map file into the drivers/char directory,
+with the name defkeymap.map, of your Linux source tree.  Then rm the
+defkeymap.c file and recompile the kernel.  Because there is no
+defkeymap.c `make' will rebuild it on the next compile.
+
+Here is a list of the available speakup review functions at this point
+in time.
+
+SAY_CHAR 0x0d04 /* say this character */
+SAY_PREV_CHAR 0x0d05 /* say character left of this char */
+SAY_NEXT_CHAR 0x0d06 /* say char right of this char */
+SAY_WORD 0x0d07 /* say this word under reading cursor */
+SAY_PREV_WORD 0x0d08
+SAY_NEXT_WORD 0x0d09
+SAY_LINE 0x0d0a /* say this line */
+SAY_PREV_LINE 0x0d0b /* say line above this line */
+SAY_NEXT_LINE 0x0d0c
+TOP_EDGE 0x0d0d /* move to top edge of screen */
+BOTTOM_EDGE 0x0d0e
+LEFT_EDGE 0x0d0f
+RIGHT_EDGE 0x0d10
+SAY_PHONETIC_CHAR 0x0d11 /* say this character phonetically */
+SPELL_WORD 0x0d12 /* spell this word letter by letter */
+SAY_SCREEN 0x0d14
+SAY_POSITION 0x0d1b
+SPEECH_OFF 0x0d1c
+SAY_ATTRIBUTES 0x0d1d
+SPEAKUP_PARKED 0x0d1e
+SAY_FROM_TOP 0x0d20
+SAY_TO_BOTTOM 0x0d21
+SAY_FROM_LEFT 0x0d22
+SAY_TO_RIGHT 0x0d23
+
diff -urN linux-2.3.8/MAINTAINERS linux/MAINTAINERS
--- linux-2.3.8/MAINTAINERS	Thu Jun  3 11:26:42 1999
+++ linux/MAINTAINERS	Wed Jun 23 14:58:04 1999
@@ -728,6 +728,13 @@
 W:	http://www.geog.ubc.ca/s_linux.html
 S:	Maintained
 
+SPEAKUP Console speech output
+P: Kirk Reiser
+M: ki...@br...
+L: sp...@br...
+W: http://www.braille.uwo.ca/speakup
+S: Maintained
+
 SPECIALIX IO8+ MULTIPORT SERIAL CARD DRIVER
 P:	Roger Wolff
 M:	R.E...@Bi...
diff -urN linux-2.3.8/arch/alpha/config.in linux/arch/alpha/config.in
--- linux-2.3.8/arch/alpha/config.in	Tue Jun 22 13:46:52 1999
+++ linux/arch/alpha/config.in	Wed Jun 30 12:40:31 1999
@@ -262,6 +262,7 @@
     define_bool CONFIG_PCI_CONSOLE y
   fi
   source drivers/video/Config.in
+  source drivers/char/speakup/Config.in
   endmenu
 fi
 
diff -urN linux-2.3.8/arch/arm/config.in linux/arch/arm/config.in
--- linux-2.3.8/arch/arm/config.in	Thu Jun 17 04:11:35 1999
+++ linux/arch/arm/config.in	Wed Jun 30 12:41:13 1999
@@ -193,6 +193,7 @@
   fi
   bool 'Support Frame buffer devices' CONFIG_FB
   source drivers/video/Config.in
+  source drivers/char/speakup/Config.in
   endmenu
 fi
 
diff -urN linux-2.3.8/arch/i386/config.in linux/arch/i386/config.in
--- linux-2.3.8/arch/i386/config.in	Mon Jun  7 20:02:23 1999
+++ linux/arch/i386/config.in	Wed Jun 30 12:20:24 1999
@@ -188,6 +188,7 @@
     bool 'Support for frame buffer devices (EXPERIMENTAL)' CONFIG_FB
   fi
   source drivers/video/Config.in
+  source drivers/char/speakup/Config.in
   endmenu
 fi
 
diff -urN linux-2.3.8/arch/m68k/config.in linux/arch/m68k/config.in
--- linux-2.3.8/arch/m68k/config.in	Tue May 11 12:57:14 1999
+++ linux/arch/m68k/config.in	Wed Jun 30 12:41:49 1999
@@ -443,6 +443,7 @@
     define_bool CONFIG_FB y
   fi
   source drivers/video/Config.in
+  source drivers/char/speakup/Config.in
   endmenu
 fi
 
diff -urN linux-2.3.8/arch/mips/config.in linux/arch/mips/config.in
--- linux-2.3.8/arch/mips/config.in	Mon Feb  1 15:03:20 1999
+++ linux/arch/mips/config.in	Wed Jun 30 12:42:45 1999
@@ -194,6 +194,7 @@
 
 comment 'Console drivers'
 source drivers/video/Config.in
+source drivers/char/speakup/Config.in
 
 mainmenu_option next_comment
 comment 'Sound'
diff -urN linux-2.3.8/arch/ppc/config.in linux/arch/ppc/config.in
--- linux-2.3.8/arch/ppc/config.in	Tue Jun  8 13:52:26 1999
+++ linux/arch/ppc/config.in	Wed Jun 30 12:43:08 1999
@@ -173,6 +173,7 @@
 mainmenu_option next_comment
 comment 'Console drivers'
 source drivers/video/Config.in
+source drivers/char/speakup/Config.in
 endmenu
 
 source drivers/char/Config.in
diff -urN linux-2.3.8/arch/sparc/config.in linux/arch/sparc/config.in
--- linux-2.3.8/arch/sparc/config.in	Mon Mar 15 19:10:43 1999
+++ linux/arch/sparc/config.in	Wed Jun 30 12:43:26 1999
@@ -45,6 +45,7 @@
 	bool 'PROM console' CONFIG_PROM_CONSOLE
 	bool 'Support Frame buffer devices' CONFIG_FB
 	source drivers/video/Config.in
+	source drivers/char/speakup/Config.in
 	endmenu
 
 	# Global things across all Sun machines.
diff -urN linux-2.3.8/arch/sparc64/config.in linux/arch/sparc64/config.in
--- linux-2.3.8/arch/sparc64/config.in	Thu Apr 22 22:24:51 1999
+++ linux/arch/sparc64/config.in	Wed Jun 30 12:44:40 1999
@@ -31,6 +31,7 @@
 bool 'PROM console' CONFIG_PROM_CONSOLE
 bool 'Support Frame buffer devices' CONFIG_FB
 source drivers/video/Config.in
+source drivers/char/speakup/Config.in
 endmenu
 
 # Global things across all Sun machines.
diff -urN linux-2.3.8/drivers/char/Makefile linux/drivers/char/Makefile
--- linux-2.3.8/drivers/char/Makefile	Sat May 22 18:02:48 1999
+++ linux/drivers/char/Makefile	Wed Jun 23 14:58:04 1999
@@ -18,6 +18,11 @@
 #
 FONTMAPFILE = cp437.uni
 
+#
+# This file contains the default keymap
+#
+KEYMAPFILE = defkeymap.map
+
 L_TARGET := char.a
 M_OBJS   :=
 L_OBJS   := tty_io.o n_tty.o tty_ioctl.o mem.o random.o
@@ 

Re: [Linuxconsole-dev] comments on multi-heading/console

[Steffen S. <s.s...@ph...>]

James Simmons wrote:

> > But, there are more (security and ease-of-use) issues involved as
> > I had to learn.
> 
> Such as ? Can you a list of things you discovered about multihead and
> secuirty and easy-of-use.
> 
> > Most important I found no (reasonably simple) way to establish
> > proper protection/virtualization without introducting another process
> > attribute, the workplace ID. This should be set by the initial
> > login process like the user-ID. With that you can easily virtualize
> > console specific /dev entries as neccessary.
> > However, I did not implement it as there are much more issues,
> > especially login,xdm etc. need to be made aware of this.
> 
> A interesting idea. Well will look at your ideas once ruby developement
> starts to kick into gear.

Quite a lot of them aren't ideas any longer, but are already tested
and working code. I will try to get a detailed documentation of my
console system done, post it on gg...@kl... and CC it to this
list.

			Steffen

_______________________________________________________________________________
Steffen Seeger                             
mailto:se...@ph...

The difference between a "concept" and a "random collection of routines"
is that the concept will survive, and the routines won't. -- L. Torvalds

Re: [Linuxconsole-dev] Municon

[Jim P. <ji...@ag...>]

Eric S. Raymond wrote:
> > Still, I'm open to suggestions -
> 
> One of our goals is to turn the emulation code into a module.  Perhaps
> the right way to do Municon would be as a combination of a module and
> a userspace daemon, the module being tailored to mediate between the
> daemon and the underlying console framebuffer.

At the moment I'm looking at Municon as a client to whatever you can get
into the kernel.  One client of many - it certainly wouldn't be suitable for
many graphical applications.  If you are planning to unify the input stream
from diverse devices, I can certainly use that.  I'll also be using whatever
you come up regarding multi-heading.

Municon could exist as just a user-space application, if you like.  However,
if you're going to get multiple terminal emulations into the kernel through
modules, it would be really nice to get Municon in at this level, so, for
example, I could say:

   set_tty_type municon
   export TERM=municon
   
To switch to it, and to switch back:

   set_tty_type linux     # or vt420, or whatever
   export TERM=linux

Without that, Municon's set of consoles would all have to be displayed
through one single real console (one real /dev/tty), using some other
key-combination to switch consoles than the ones people are used to.

Yes - this approach of having terminal emulation in modules makes everything
much more flexible, and much more integrated.  It also is going to
seamlessly take care of applications running on a Municon console that want
to use GGI or /dev/fb or whatever, directly.  If it works for the `linux'
console, it would also work for `municon' automatically.

Good news.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk

RE: [Linuxconsole-dev] writeup

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: Brad Midgley [mailto:br...@tu...]
>
> I'd like to do a writeup with diagrams for the new console 
> system like I
> did before, including the terminology we all agree on. (Head, console,
> tty, etc.) Have we all agreed on what we call things? For 
> example, is a
> crt an example of a head or is a head the collection of 
> multiple displays
> and input devices used by a single person?

First, I'd like to thank you for your last writeup.

As I understand it (and have been corrected on), a head is a collection of
input and output devices grouped around a single "display" (I can't think of
a better word).  I believe a console would be the currently selected head.

That reminds me...  Can there be only ONE console?  In a multi-head
environment, does each head have a console, or does the primary have the
only console?

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

RE: [Linuxconsole-dev] Progress on Sapphire

[Brad D. <Br...@NE...>]

> -----Original Message-----
> From: Eric S. Raymond [mailto:es...@th...]
> 
> OK, I'll get us some publicity.  I'm good at that ;-).  
> Though, on second
> thought, maybe the time to make noise might be when we ship 
> Emerald and 
> Sapphire?  I kind of like putting working code on the table along with
> an announcement.

Personally, I'd wait.  I can't count how many times I've been pointed to
vaporware...  And at this point, everything is just that.  I've noticed that
people are much more comfortable with an announcement when there's something
behind it.  It gives much more credibility (not that it's an issue in this
case).

To sum it up, hype blows.

Brad Douglas
br...@ne...
http://www.linux-fbdev.org

Re: [Linuxconsole-dev] Progress on Sapphire

[Eric S. R. <es...@th...>]

James Simmons <jsi...@ac...>:
> Cool. Now that CVS is ready we can place it in there.

It's still really Dominik's patch -- I'll let him check it in.
I'm not sure how to handle the changes to console_codes(4).  Maybe
I'll just ship those direct to Andries.

> > BTW, have we done a public launch announcement for c.o.l.a yet?
> > If not, I'll write and ship one.
> 
> Not really. I announced it on lkml but that was it. 

OK, I'll get us some publicity.  I'm good at that ;-).  Though, on second
thought, maybe the time to make noise might be when we ship Emerald and 
Sapphire?  I kind of like putting working code on the table along with
an announcement.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Question with boldness even the existence of a God; because, if there
be one, he must more approve the homage of reason, than that of
blindfolded fear.... Do not be frightened from this inquiry from any
fear of its consequences. If it ends in the belief that there is no
God, you will find incitements to virtue in the comfort and
pleasantness you feel in its exercise...
	-- Thomas Jefferson, in a 1787 letter to his nephew

Re: [Linuxconsole-dev] UNICODE patch

[James S. <jsi...@ac...>]

It expands support for things like chinesee characters on the console. 

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

On Wed, 8 Mar 2000, Eric S. Raymond wrote:

> James Simmons <jsi...@ac...>:
> > Here is a old unicode support patch I have. 
> 
> I'm not sure how to deal with this.  I don't understand what it's doing, and
> I'm handed the Sapphire candidate over to Dominik.
> -- 
> 		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
> 
> Of all tyrannies, a tyranny exercised for the good of its victims may
> be the most oppressive. It may be better to live under robber barons
> than under omnipotent moral busybodies. The robber baron's cruelty may
> sometimes sleep, his cupidity may at some point be satiated; but those
> who torment us for our own good will torment us without end, for they
> do so with the approval of their consciences.
> 	-- C. S. Lewis
> 

Re: [Linuxconsole-dev] writeup

[James S. <jsi...@ac...>]

On Wed, 8 Mar 2000, Brad Midgley wrote:

> James,
> 
> Your emailer is linewrapping your patches. That's a good way to piss off
> maintainers.

This was a patch soemone posted that I grabed. That means the patch was
not properly created. I will have to go threw it :(

> I'd like to do a writeup with diagrams for the new console system like I
> did before, including the terminology we all agree on. (Head, console,
> tty, etc.) Have we all agreed on what we call things? For example, is a
> crt an example of a head or is a head the collection of multiple displays
> and input devices used by a single person?

Hey we are going to have to get this straight. Dominik posted some terms
to get straight in a earlier post. Its in the archives.

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] comments on multi-heading/console

[James S. <jsi...@ac...>]

> That is basically how my approach works internally to implement
> consoles.
> The video hardware drivers, input hardware drivers etc. only care about
> mapping a virtual representation (devices) to the actual hardware.

Yeap. That's the direction fbdev is heading in and Vojtech is doing the
same for the input suite.

> > Take
> > /dev/fb. You wouldn't want to be on a console and then all the sudden a X
> > session starts because someone ran X on anther station requestion that
> > head you are on. I really like to see the X server some day just using
> > /dev/input and /dev/fb instead of any VTs like its does now.
> 
> But, there are more (security and ease-of-use) issues involved as
> I had to learn.

Such as ? Can you a list of things you discovered about multihead and
secuirty and easy-of-use. 

> Most important I found no (reasonably simple) way to establish 
> proper protection/virtualization without introducting another process
> attribute, the workplace ID. This should be set by the initial
> login process like the user-ID. With that you can easily virtualize
> console specific /dev entries as neccessary.
> However, I did not implement it as there are much more issues,
> especially login,xdm etc. need to be made aware of this.

A interesting idea. Well will look at your ideas once ruby developement
starts to kick into gear. 



"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] Progress on Sapphire

[James S. <jsi...@ac...>]

> > The best thing to do is place these patches in CVS and announce it on 
> > linux-kernel so people can go test it. Have CVS with 3 top directorys for
> > each release. Sapphire, emrald, and ruby.
> 
> OK.  I gather the idea is that the base version of each file in the CVS is
> copied from the release we're going to ship the patch for?

The idea is to keep seperate the emarld, sapphire and ruby branch. People
don't want to download our work for 2.0.x, 2.2.x, and 2.3.X. This saved on
the download.  
 
> Sapphire is in good shape, I think.  I've handed a Sapphire candidate
> to Dominik.  I will test my copy later today, after I finish updating
> console_codes(4).

Cool. Now that CVS is ready we can place it in there.

> > So it would look like using just vc_data and expanding it would be the
> > best choose I think. Any opinons?
> 
> Not from here, I don't know that code.

Hum I will talk to linus about this. I don't want to do something that
linus doesn't like.
 
> BTW, have we done a public launch announcement for c.o.l.a yet?
> If not, I'll write and ship one.

Not really. I announced it on lkml but that was it. 

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

[Linuxconsole-dev] VS is ready

[James S. <jsi...@ac...>]

CVS is now ready. Its three seperate mdouels. So if you want to test it
out you need to grab one of the 3 modules. If you look at your CVS page
the modulename you want to use are emerald, sapphire, and ruby. 

Sapphire is the one under current developement. Its against a 2.2.X kernel
and it will be ported back to 2.0.X as well.

Emerald is related to sapphire except it is for the 2.3.X branch.

Ruby is the brach with the major changes for the linux console system. It
will start out with the 2.3.X branch and be developed for 2.4.X. It 
should be included into 2.5.X.

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] console_codes(4) is updated

[James S. <jsi...@ac...>]

On Wed, 8 Mar 2000, Eric S. Raymond wrote:

> I have updated console_codes(4) to reflect the changes in the Sapphire
> candidate patch I gave Dominik.
> 
> James, are you going to initialize the CVS setup any time soon?  

Yes. I assume everyone agrees on the CVS setup I posted earlier. 

CVS -> saphhire -> v2.0
                -> v2.2
                -> v2.3
    -> emrald   -> v2.0
                -> v2.2
                -> v2.3
    -> ruby     -> v2.3
                
> It's 
> about time for us to start checking in things so shared work can go forward.

Yep. Will do. 

> I'm going to test the Sapphire candidate on 2.2.12 today.  Other than that
> I'm out of things to do.

Oh there is more to do :)

"Look its a text editor, not its a OS, no it Emacs"
James Simmons                                           ____/| 
fbdev/gfx developer                                     \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U

Re: [Linuxconsole-dev] console_codes(4) is updated

[Kirk R. <ki...@br...>]

"Eric S. Raymond" <es...@th...> writes:

> Which files does this touch?  And do you have 2.3.x patches as well?

I have partial patches for 2.3.x.  Unfortunately I haven't had the
time to sift through all the changes yet quite a bit changed with the
advent of boot_malloc() (sp?) and the change over of the append
command line stuff in main.c.

The files which are affected are console.c, keyboard.c keyboard.h,
vt???.c and I'm not sure of what else.  I can check the diffs or post
the patches here if that might be useful.  There is also a new
directory added for all of the synths and speakup base code.

  Kirk

-- 
Kirk Reiser				The Computer Braille Facility
e-mail: ki...@br...		University of Western Ontario
phone: (519) 661-3061

Re: [Linuxconsole-dev] Municon

[Eric S. R. <es...@th...>]

Jim Peters <ji...@ag...>:
> Eric S. Raymond wrote:
> > One big one.  I fear some terminal emulation has to be in the kernel,
> > otherwise the user will lose badly in pathological situations where the
> > hypothetical daemon doesn't start up.  Never forget the run-level 1 case.
> 
> Definitely, yes, there has to be terminal emulation in the kernel.  I'm not
> interested in trying to put a vital function of the kernel into a user-space
> daemon.
> 
> It's just that for me, not being at all familiar with kernel-hacking, trying
> to get this into the kernel seems an unnecessarily hard way of doing it.  I
> can see how it is feasible in user-space, and I believe I can see how it can
> be done without hitting any major obstacles.
> 
> The other thing is that a Chinese user has a lot of glyphs in their
> character-set.  It may be better to keep these out of kernel memory.  Also,
> a lot more allocation and deallocation of memory will be going on - we're
> not working with a fixed grid of characters any more, when the font is
> proportional.  Things need to be more flexible.
> 
> It doesn't feel right for this to be in the kernel.
> 
> Still, I'm open to suggestions -

One of our goals is to turn the emulation code into a module.  Perhaps
the right way to do Municon would be as a combination of a module and
a userspace daemon, the module being tailored to mediate between the
daemon and the underlying console framebuffer.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Are we at last brought to such a humiliating and debasing degradation,
that we cannot be trusted with arms for our own defence?  Where is the
difference between having our arms in our own possession and under our
own direction, and having them under the management of Congress?  If
our defence be the *real* object of having those arms, in whose hands
can they be trusted with more propriety, or equal safety to us, as in
our own hands?
        -- Patrick Henry, speech of June 9 1788

Re: [Linuxconsole-dev] Municon

[Jim P. <ji...@ag...>]

Eric S. Raymond wrote:
> One big one.  I fear some terminal emulation has to be in the kernel,
> otherwise the user will lose badly in pathological situations where the
> hypothetical daemon doesn't start up.  Never forget the run-level 1 case.

Definitely, yes, there has to be terminal emulation in the kernel.  I'm not
interested in trying to put a vital function of the kernel into a user-space
daemon.

It's just that for me, not being at all familiar with kernel-hacking, trying
to get this into the kernel seems an unnecessarily hard way of doing it.  I
can see how it is feasible in user-space, and I believe I can see how it can
be done without hitting any major obstacles.

The other thing is that a Chinese user has a lot of glyphs in their
character-set.  It may be better to keep these out of kernel memory.  Also,
a lot more allocation and deallocation of memory will be going on - we're
not working with a fixed grid of characters any more, when the font is
proportional.  Things need to be more flexible.

It doesn't feel right for this to be in the kernel.

Still, I'm open to suggestions -

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk

Re: [Linuxconsole-dev] console_codes(4) is updated

[Eric S. R. <es...@th...>]

Kirk Reiser <ki...@br...>:
> Hi Folks:  Well I am not sure where to start.  I have a set of patches
> against the 2.2.x tree to provide speech output for blind users.  It
> is a full screen review system, or at least it will be once I get it
> all worked out.  Right now it is very usable as it is and I would like
> to get in the new console development before we get so far a long it
> is a major project to move it over.
> 
> What I would like to know is how is it best at this point to get it
> included in the safire development tree?

Which files does this touch?  And do you have 2.3.x patches as well?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Vojtech P. <vo...@su...>]

On Wed, Mar 08, 2000 at 12:30:08PM +0000, Jim Peters wrote:
> > > Make the terminal emulation a loadable module.  Have the console driver
> > > look for module "vte" and then you can use the alias mechanismen of
> > > modload to push the appropriate module.  If that fails fall back to dumb
> > > line mode (similiar to the framebuffer initialization).
> > > 
> > > Does that appear a workable solution?
> > 
> > Yes:)
> 
> Another idea - the terminal emulator can live in user-space (a terminal-
> emulator daemon ?), sitting on top of the normal Linux console code, or
> fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.
> 
> It doesn't need to go into the kernel.  If we take the GGI approach of only
> having hardware-banging stuff in the kernel, then there is no reason to have
> the terminal emulator live there as well.  If we can get all the services we
> need from the kernel one way or another, then the terminal emulator can live
> outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.
> 
> This may need to be a high-priority process to keep the display up-to-date
> in the face of high system loads.  This is a downside, but there is also the
> up-side that the application does not block whilst the display is updated
> (as with a kernel solution), but only when the pipe buffer is full.  A
> daemon updating once every frame or so could cut out a lot of unnecessary
> updates when applications have rolling counters or whatever.
> 
> Any objections to this idea ?

Emergency situations. Cases when the daemon is not started. Cases of
system crashing and kernel oopsing and writing data to the screen. While
a full vt100 isn't needed for these cases, *some* terminal is needed,
right in the kernel.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linuxconsole-dev] console_codes(4) is updated

[Kirk R. <ki...@br...>]

Hi Folks:  Well I am not sure where to start.  I have a set of patches
against the 2.2.x tree to provide speech output for blind users.  It
is a full screen review system, or at least it will be once I get it
all worked out.  Right now it is very usable as it is and I would like
to get in the new console development before we get so far a long it
is a major project to move it over.

What I would like to know is how is it best at this point to get it
included in the safire development tree?

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: ki...@br...		University of Western Ontario
phone: (519) 661-3061

Re: [Linuxconsole-dev] Which tree and developers

[Dominik K. <dom...@un...>]

On Wed, Mar 08, 2000 at 05:19:22PM +0100, Dominik Kubla wrote:
> On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote:
> > P.S
> > 
> >   Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering
> > if you updated it already so we don't duplicate effort here. 
> 
> Working on it... But right now i have to check my defences: some cracker
> scanned our University and i have to make sure my external systems are
> secured.

Argh! Too much to do to even understand the mails i am replying to...
What i meant is: i am working on the 2.3.50 version of the vt100-related
stuff. I simply misread that this part of the mail was directed at
Vojtech.

*GRUMBLE*
  Dominik
-- 
  Networking Group,  Hospital of Johannes Gutenberg-University                  
  Obere Zahlbacher Straße 69, 55101 Mainz, Germany                              
  Tel: +49 (0)6131 17-2482   FAX: +49 (0)6131 17-5521                           

Re: [Linuxconsole-dev] Draft web page is up

[<jmc...@li...>]

Eric S. Raymond <es...@th...> wrote:
>>                                   Evstack (look in archive)

> The EvStack site at pepsi.visus.com has apparently disappeared.

	It's now at http://zhrodague.net/~jmcc/ggi/EvStack

	It has my entire CVS repository.

-- 
Jason McMullan, Senior Linux Consultant, Linuxcare, Inc.
412.422.8077 tel, 415.701.0792 fax
jmc...@li..., http://www.linuxcare.com/
Linuxcare. Support for the revolution.

[Linuxconsole-dev] Apologies, I sent out an incomplete patch.

[Eric S. R. <es...@sn...>]

Apologies, I sent out an incomplete patch that left some deltas off
the end.  Here is the full version, Dominik's 2.2.1 patch reconciled
with 2.2.12 and cleaned up to be minimal (down to 32K from 99K).

--- console.c	2000/03/08 01:42:00	1.1
+++ console.c	2000/03/08 18:33:00	1.10
@@ -66,6 +66,10 @@
  *
  * Resurrected character buffers in videoram plus lots of other trickery
  * by Martin Mares <mj...@at...>, July 1998
+ *
+ * ECMA-35 (ISO 2022), ECMA-48 (ISO 6429) and missing DEC VT-series functions
+ * by Dominik Kubla <ku...@un...>, February 1999
+ * Adapted for 2.2.12 by Eric S. Raymond <es...@th...>, March 2000.
  */
 
 #include <linux/module.h>
@@ -139,8 +143,8 @@
 		    unsigned int cols, int do_clear);
 static void blank_screen(void);
 static void gotoxy(int currcons, int new_x, int new_y);
-static void save_cur(int currcons);
-static void reset_terminal(int currcons, int do_clear);
+static void vte_decsc(int currcons);
+static void vte_ris(int currcons, int do_clear);
 static void con_flush_chars(struct tty_struct *tty);
 static void set_vesa_blanking(unsigned long arg);
 static void set_cursor(int currcons);
@@ -735,11 +739,11 @@
 		screenbuf_size = ss;
 		set_origin(currcons);
 
-		/* do part of a reset_terminal() */
+		/* do part of a vte_ris() */
 		top = 0;
 		bottom = video_num_lines;
 		gotoxy(currcons, x, y);
-		save_cur(currcons);
+		vte_decsc(currcons);
 
 		if (console_table[currcons]) {
 			struct winsize ws, *cws = &console_table[currcons]->winsize;
@@ -791,6 +795,18 @@
 #define VT100ID "\033[?1;2c"
 #define VT102ID "\033[?6c"
 
+/*
+ * ISO 6429 has its colors well defined:
+ *
+ * 0: black
+ * 1: red
+ * 2: yellow
+ * 3: green
+ * 4: blue
+ * 5: magenta
+ * 6: cyan
+ * 7: white
+ */
 unsigned char color_table[] = { 0, 4, 2, 6, 1, 5, 3, 7,
 				       8,12,10,14, 9,13,11,15 };
 
@@ -859,11 +875,15 @@
 	scrolldelta(lines);
 }
 
-static void lf(int currcons)
+/*
+ * LINE FEED (LF)
+ */
+static void vte_lf(int currcons)
 {
-    	/* don't scroll if above bottom of scrolling region, or
-	 * if below scrolling region
-	 */
+        /*
+         * Don't scroll if below top of scrolling region, or if above
+         * scrolling region.
+         */
     	if (y+1 == bottom)
 		scrup(currcons,top,bottom,1);
 	else if (y < video_num_lines-1) {
@@ -873,11 +893,15 @@
 	need_wrap = 0;
 }
 
-static void ri(int currcons)
+/*
+ * REVERSE LINE FEED (RI)
+ */
+static void vte_ri(int currcons)
 {
-    	/* don't scroll if below top of scrolling region, or
-	 * if above scrolling region
-	 */
+        /*
+         * Don't scroll if below top of scrolling region, or if above
+         * scrolling region.
+         */
 	if (y == top)
 		scrdown(currcons,top,bottom,1);
 	else if (y > 0) {
@@ -887,13 +911,19 @@
 	need_wrap = 0;
 }
 
-static inline void cr(int currcons)
+/*
+ * CARRIAGE RETURN (CR)
+ */
+static inline void vte_cr(int currcons)
 {
 	pos -= x<<1;
 	need_wrap = x = 0;
 }
 
-static inline void bs(int currcons)
+/*
+ * BACK SPACE (BS)
+ */
+static inline void vte_bs(int currcons)
 {
 	if (x) {
 		pos -= 2;
@@ -902,12 +932,62 @@
 	}
 }
 
-static inline void del(int currcons)
+/*
+ * CURSOR LINE TABULATION (CVT)
+ *
+ * NOTE:
+ * In accordance with our interpretation of VT as LF we will treat CVT as
+ * (par[0] * LF).  Not very creative, but at least consequent.
+ */
+static void vte_cvt(int currcons, int vpar)
+{
+        int i;
+
+        for (i = 0; i < vpar; i++) {
+		vte_lf(currcons);
+        }
+}
+
+/*
+ * CURSOR BACKWARD TABULATION (CBT)
+ */
+static void vte_cbt(int currcons, int vpar)
+{
+        int i;
+
+        for (i = 0; i < vpar; i++) {
+		pos -= (x << 1);
+		while (x > 0) {
+			x--;
+			if (tab_stop[x >> 5] & (1 << (x & 31)))
+			        break;
+		}
+		pos += (x << 1);
+        }
+}
+
+/*
+ * CURSOR FORWARD TABULATION (CHT)
+ */
+static void vte_cht(int currcons, int vpar)
 {
-	/* ignored */
+        int i;
+
+        for (i = 0; i < vpar; i++) {
+		pos -= (x << 1);
+		while (x < video_num_columns - 1) {
+			x++;
+			if (tab_stop[x >> 5] & (1 << (x & 31)))
+			        break;
+		}
+		pos += (x << 1);
+        }
 }
 
-static void csi_J(int currcons, int vpar)
+/*
+ * ERASE IN PAGE (ED)
+ */
+static void vte_ed(int currcons, int vpar)
 {
 	unsigned int count;
 	unsigned short * start;
@@ -951,7 +1031,10 @@
 	need_wrap = 0;
 }
 
-static void csi_K(int currcons, int vpar)
+/*
+ * ERASE IN LINE (EL)
+ */
+static void vte_el(int currcons, int vpar)
 {
 	unsigned int count;
 	unsigned short * start;
@@ -985,7 +1068,12 @@
 	need_wrap = 0;
 }
 
-static void csi_X(int currcons, int vpar) /* erase the following vpar positions */
+/*
+ * Erase character (ECH)
+ *
+ * NOTE:  This function is not available in DEC VT1xx terminals.
+ */
+static void vte_ech(int currcons, int vpar) /* erase the following vpar positions */
 {					  /* not vt100? */
 	int count;
 
@@ -1008,7 +1096,13 @@
 	color = def_color;
 }
 
-static void csi_m(int currcons)
+/*
+ * SELECT GRAPHIC RENDITION (SGR)
+ *
+ * NOTE: The DEC vt1xx series does only implement attribute values 0,1,4,5
+ *       and 7.
+ */
+static void vte_sgr(int currcons)
 {
 	int i;
 
@@ -1017,78 +1111,60 @@
 			case 0:	/* all attributes off */
 				default_attr(currcons);
 				break;
-			case 1:
+			case 1:	/* bold or increased intensity */
 				intensity = 2;
 				break;
-			case 2:
+			case 2:	/* faint or decreased intensity */
 				intensity = 0;
 				break;
-			case 4:
+			case 4:	/* singly underlined. */
 				underline = 1;
 				break;
-			case 5:
+			case 5:	/* slowly blinking (< 2.5 Hz) */
+			case 6:	/* rapidly blinking (>= 2.5 Hz) */
 				blink = 1;
 				break;
-			case 7:
+			case 7:	/* negative image */
 				reverse = 1;
 				break;
-			case 10: /* ANSI X3.64-1979 (SCO-ish?)
-				  * Select primary font, don't display
-				  * control chars if defined, don't set
-				  * bit 8 on output.
-				  */
+			case 10:	/*  primary (default) font */
 				translate = set_translate(charset == 0
 						? G0_charset
 						: G1_charset,currcons);
 				disp_ctrl = 0;
 				toggle_meta = 0;
 				break;
-			case 11: /* ANSI X3.64-1979 (SCO-ish?)
-				  * Select first alternate font, lets
-				  * chars < 32 be displayed as ROM chars.
-				  */
+			case 11:	/* first alternative font */
 				translate = set_translate(IBMPC_MAP,currcons);
 				disp_ctrl = 1;
 				toggle_meta = 0;
 				break;
-			case 12: /* ANSI X3.64-1979 (SCO-ish?)
-				  * Select second alternate font, toggle
-				  * high bit before displaying as ROM char.
-				  */
+			case 12:	/* second alternative font */
 				translate = set_translate(IBMPC_MAP,currcons);
 				disp_ctrl = 1;
 				toggle_meta = 1;
 				break;
-			case 21:
-			case 22:
+			case 22:	/* normal intensity (neither faint nor bold) */
 				intensity = 1;
 				break;
-			case 24:
+			case 24:	/* not underlined (neither singly nor doubly) */
 				underline = 0;
 				break;
-			case 25:
+			case 25:	/* steady (not blinking) */
 				blink = 0;
 				break;
-			case 27:
+			case 27:	/* positive image */
 				reverse = 0;
 				break;
-			case 38: /* ANSI X3.64-1979 (SCO-ish?)
-				  * Enables underscore, white foreground
-				  * with white underscore (Linux - use
-				  * default foreground).
-				  */
+			case 38:	/* foreground color (ISO 8613-6/ITU T.416) */
 				color = (def_color & 0x0f) | background;
 				underline = 1;
 				break;
-			case 39: /* ANSI X3.64-1979 (SCO-ish?)
-				  * Disable underline option.
-				  * Reset colour to default? It did this
-				  * before...
-				  */
+			case 39:	/* default display color */
 				color = (def_color & 0x0f) | background;
 				underline = 0;
 				break;
-			case 49:
+			case 49:	/* default background color */
 				color = (def_color & 0xf0) | foreground;
 				break;
 			default:
@@ -1112,24 +1188,71 @@
 	con_schedule_flip(tty);
 }
 
-static void cursor_report(int currcons, struct tty_struct * tty)
+/*
+ * Fake a DEC DSR for non-implemented features
+ */
+static void vte_fake_dec_dsr(struct tty_struct *tty, char *reply)
+{
+	char buf[40];
+	sprintf(buf, "\033[?%sn", reply);
+	respond_string(buf, tty);
+}
+
+/*
+ * CURSOR POSITION REPORT (CPR)
+ * DEC EXTENDED CURSOR POSITION REPORT (DECXCPR)
+ */
+static void vte_cpr(int currcons, struct tty_struct *tty, int ext)
 {
 	char buf[40];
 
-	sprintf(buf, "\033[%d;%dR", y + (decom ? top+1 : 1), x+1);
+	if (!ext) {
+		sprintf(buf, "\033[%d;%dR", y + (decom ? top + 1 : 1), x
+			+ 1);
+	} else {
+		/*
+		 * NOTE:
+		 * Since we don't implement any form of page memory, we will
+		 * always return the cursor position in page 1.
+		 */
+		sprintf(buf, "\033[?%d;%d;1R", y + (decom ? top + 1 : 1),
+			x + 1);
+	}
 	respond_string(buf, tty);
 }
 
-static inline void status_report(struct tty_struct * tty)
+/*
+ * DEVICE STATUS REPORT (DSR)
+ */
+static inline void vte_dsr(struct tty_struct * tty)
 {
 	respond_string("\033[0n", tty);	/* Terminal ok */
 }
 
-static inline void respond_ID(struct tty_struct * tty)
+/*
+ * DEVICE ATTRIBUTE (DA)
+ */
+static inline void vte_da(struct tty_struct * tty)
 {
 	respond_string(VT102ID, tty);
 }
 
+/*
+ * DEC REPORT TERMINAL PARAMETERS (DECREPTPARM)
+ *
+ * NOTE:  This function is only available on DEV VT1xx terminals.
+ *
+ * XXX: Resport should reflect actual parameters instead of being hard
+ *      coded.  -dbk
+ */
+static void vte_decreptparm(int currcons, struct tty_struct *tty)
+{
+	char buf[40];
+
+	sprintf(buf, "\033[%d;1;1;120;120;1;0x", par[0] + 2);
+	respond_string(buf, tty);
+}
+
 void mouse_report(struct tty_struct * tty, int butt, int mrx, int mry)
 {
 	char buf[8];
@@ -1147,6 +1270,10 @@
 	return report_mouse;
 }
 
+/*
+ * Set mode (SM / DECSM)
+ * Reset mode (RM / DECRM)
+ */
 static void set_mode(int currcons, int on_off)
 {
 	int i;
@@ -1279,7 +1406,12 @@
 	need_wrap = 0;
 }
 
-static void csi_at(int currcons, unsigned int nr)
+/*
+ * Insert character (ICH)
+ *
+ * NOTE:  This function is not available in DEC VT1xx terminals.
+ */
+static void vte_ich(int currcons, unsigned int nr)
 {
 	if (nr > video_num_columns - x)
 		nr = video_num_columns - x;
@@ -1288,7 +1420,10 @@
 	insert_char(currcons, nr);
 }
 
-static void csi_L(int currcons, unsigned int nr)
+/*
+ * Insert line (IL)
+ */
+static void vte_il(int currcons, unsigned int nr)
 {
 	if (nr > video_num_lines - y)
 		nr = video_num_lines - y;
@@ -1297,7 +1432,10 @@
 	insert_line(currcons, nr);
 }
 
-static void csi_P(int currcons, unsigned int nr)
+/*
+ * Delete character (DCH)
+ */
+static void vte_dch(int currcons, unsigned int nr)
 {
 	if (nr > video_num_columns - x)
 		nr = video_num_columns - x;
@@ -1306,7 +1444,10 @@
 	delete_char(currcons, nr);
 }
 
-static void csi_M(int currcons, unsigned int nr)
+/*
+ * Delete line (DL)
+ */
+static void vte_dl(int currcons, unsigned int nr)
 {
 	if (nr > video_num_lines - y)
 		nr = video_num_lines - y;
@@ -1315,7 +1456,18 @@
 	delete_line(currcons, nr);
 }
 
-static void save_cur(int currcons)
+/*
+ * Save cursor (DECSC)
+ *
+ * This saves the following states:
+ *  - cursor position
+ *  - graphic rendition
+ *  - character set shift state
+ *  - state of wrap flag
+ *  - state of origin mode
+ *  - state of selective erase (not implemented)
+ */
+static void vte_decsc(int currcons)
 {
 	saved_x		= x;
 	saved_y		= y;
@@ -1329,7 +1481,10 @@
 	saved_G1	= G1_charset;
 }
 
-static void restore_cur(int currcons)
+/*
+ * Restore cursor (DECRC)
+ */
+static void vte_decrc(int currcons)
 {
 	gotoxy(currcons,saved_x,saved_y);
 	intensity	= s_intensity;
@@ -1345,15 +1500,29 @@
 	need_wrap = 0;
 }
 
-enum { ESnormal, ESesc, ESsquare, ESgetpars, ESgotpars, ESfunckey,
-	EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
+enum { ESinit, ESesc, EScsi, ESgetpars, ESgotpars, ESfunckey,
+	ESscf, ESgzd4, ESg1d4, ESdocs, ESignore, ESosc,
 	ESpalette };
 
-static void reset_terminal(int currcons, int do_clear)
+/*
+ * Reset to initial state (RIS)
+ *
+ * On DEC terminals this causes the following:
+ *  - all set-up parameters are replaced by power-up defaults
+ *  - all communications lines are disconnected (should we send SIGHUP?)
+ *  - all user-defined keys are cleared (not implemented)
+ *  - the screen is cleared
+ *  - cursor is place to upper-left corner
+ *  - SGR state is set to normal
+ *  - selective erase attribute write state is set to "non-selective erase"
+ *    (not implemented)
+ *  - all character sets are set to default (not implemented)
+ */
+static void vte_ris(int currcons, int do_clear)
 {
 	top		= 0;
 	bottom		= video_num_lines;
-	vc_state	= ESnormal;
+	vc_state	= ESinit;
 	ques		= 0;
 	translate	= set_translate(LAT1_MAP,currcons);
 	G0_charset	= LAT1_MAP;
@@ -1399,9 +1568,54 @@
 	bell_duration = DEFAULT_BELL_DURATION;
 
 	gotoxy(currcons,0,0);
-	save_cur(currcons);
+	vte_decsc(currcons);
 	if (do_clear)
-	    csi_J(currcons,2);
+	    vte_ed(currcons,2);
+}
+
+/*
+ * TABULATION CLEAR (TBC)
+ *
+ * NOTE:
+ * In case of parameters 0 and 2 the number of lines affected depends on the
+ * setting of the Tabulation Stop Mode (TSM).  Since we don't implement TSM,
+ * this is silently ignored.
+ *
+ * Parameters 1 and 4 are similiar to 0 and 3, but affect only line tabulation
+ * stops, which are not implemented.
+ *
+ * Parameter 2 may only be interpreted, when we implement a tabulation stop map
+ * per display line.
+ */
+static void vte_tbc(int currcons, int vpar)
+{
+
+	switch (vpar) {
+	case 0:
+		/*
+		 * The character tabulation stop at the active
+		 * presentation position is cleared.
+		 */
+		tab_stop[x >> 5] &= ~(1 << (x & 31));
+		return;
+#if 0
+	case 2:
+		/*
+		 * All character tabulation stops in the active
+		 * line are cleared.
+		 */
+#endif
+	case 3:
+		/*
+		 * All character tabulation stops are cleared.
+		 */
+	case 5:
+		/*
+		 * All tabulation stops are cleared.
+		 */
+		tab_stop[0] = tab_stop[1] = tab_stop[2] = tab_stop[3] =
+		    tab_stop[4] = 0;
+	}
 }
 
 static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
@@ -1411,16 +1625,19 @@
 	 *  of an escape sequence.
 	 */
 	switch (c) {
-	case 0:
+	case 0x00:		/* NUL - Null */
+		return;
+        case 0x05:              /* ENQ - Enquiry */
+		/* XXX Fixme! should implement answerback */
 		return;
-	case 7:
+	case 0x07:		/* BEL - Bell */
 		if (bell_duration)
 			kd_mksound(bell_pitch, bell_duration);
 		return;
-	case 8:
-		bs(currcons);
+	case 0x08:		/* BS - Backspace */
+		vte_bs(currcons);
 		return;
-	case 9:
+	case 0x09:		/* HT - Character tabulation */
 		pos -= (x << 1);
 		while (x < video_num_columns - 1) {
 			x++;
@@ -1429,103 +1646,168 @@
 		}
 		pos += (x << 1);
 		return;
-	case 10: case 11: case 12:
-		lf(currcons);
+        case 0x0a:              /* LF - Line feed */
+        case 0x0b:              /* VT - Line tabulation */
+		/*
+		 * Since line tabulation is not implemented in the DEC VT
+		 * series (except VT131 ?), the DEC VT series treats any
+		 * VT as LF.
+		 */
+        case 0x0c:              /* FF - Form feed */
+		/*
+		 * DEC VT series processes FF as LF.
+		 */
+		vte_lf(currcons);
 		if (!is_kbd(lnm))
 			return;
-	case 13:
-		cr(currcons);
+	case 0x0d:		/* CR - Carriage return */
+		vte_cr(currcons);
 		return;
-	case 14:
+	case 0x0e:		/* SO - Shift out / LS1 - Locking shift 1 */
 		charset = 1;
 		translate = set_translate(G1_charset,currcons);
 		disp_ctrl = 1;
 		return;
-	case 15:
+	case 0x0f:		/* SI - Shift in / LS0 - Locking shift 0 */
 		charset = 0;
 		translate = set_translate(G0_charset,currcons);
 		disp_ctrl = 0;
 		return;
-	case 24: case 26:
-		vc_state = ESnormal;
+        case 0x18:              /* CAN - Cancel */
+        case 0x1a:              /* SUB - Substitute */
+		/*
+		 * NOTE:
+		 * On a DEC VT series terminal the reception of SUB will not
+		 * only end the current ESC, CSI or DCS sequence but also
+		 * display the error character, the mirrored (not upside-down!)
+		 * question mark.  Not (yet) implemented.
+		 */
+		vc_state = ESinit;
 		return;
-	case 27:
+	case 0x1b:		/* ESC - Escape */
 		vc_state = ESesc;
 		return;
-	case 127:
-		del(currcons);
+	case 0x7f:		/* DEL - Delete */
+		/*
+		 * This character is ignored, unless a 96-set has been mapped,
+		 * but this is not supported at the moment.
+		 */
+		return;
+	}
+
+	/*
+	 * C1 control functions (8-bit mode).
+	 *
+	 * XXX Fixme! Should only be interpreted if 8-bit controls are enabled.
+	 * XXX Fixme! Should have all C1 controls implemented (acc. to ECMA).
+	 */
+	switch (c) {
+	case 0x84:		/* IND - Line feed (DEC, dropped by ECMA/ISO) */
+		vte_lf(currcons);
+		return;
+	case 0x85:		/* NEL - Next line */
+		vte_lf(currcons);
+		vte_cr(currcons);
+		return;
+	case 0x88:		/* HTS - Character tabulation set */
+		tab_stop[x >> 5] |= (1 << (x & 31));
+		return;
+	case 0x8d:		/* RI - Reverse line feed */
+		vte_ri(currcons);
 		return;
-	case 128+27:
-		vc_state = ESsquare;
+	case 0x9b:		/* CSI - Control sequence introducer */
+		vc_state = EScsi;
 		return;
 	}
+
 	switch(vc_state) {
 	case ESesc:
-		vc_state = ESnormal;
+		vc_state = ESinit;
 		switch (c) {
-		case '[':
-			vc_state = ESsquare;
+		case '#':	/* SCF - Single control functions */
+			vc_state = ESscf;
 			return;
-		case ']':
-			vc_state = ESnonstd;
+		case '%':	/* DOCS - Designate other coding system */
+			vc_state = ESdocs;
 			return;
-		case '%':
-			vc_state = ESpercent;
+		case '(':	/* GZD4 - G0-designate 94-set */
+			vc_state = ESgzd4;
 			return;
-		case 'E':
-			cr(currcons);
-			lf(currcons);
+		case ')':	/* G1D4 - G1-designate 94-set */
+			vc_state = ESg1d4;
 			return;
-		case 'M':
-			ri(currcons);
+
+			/* ===== Private control functions ===== */
+
+		case '7':	/* DECSC - Save cursor */
+			vte_decsc(currcons);
 			return;
-		case 'D':
-			lf(currcons);
+		case '8':	/* DECRC - Restore cursor */
+			vte_decrc(currcons);
 			return;
-		case 'H':
-			tab_stop[x >> 5] |= (1 << (x & 31));
+		case '=':	/* DECKPAM - Keypad application mode */
+			set_kbd(kbdapplic);
 			return;
-		case 'Z':
-			respond_ID(tty);
+		case '>':	/* DECKPNM - Keypad numeric mode */
+			clr_kbd(kbdapplic);
 			return;
-		case '7':
-			save_cur(currcons);
+
+			/* ===== C1 control functions ===== */
+
+		case 'D':	/* IND - Line feed (DEC, but not ISO 6429) */
+			vte_lf(currcons);
 			return;
-		case '8':
-			restore_cur(currcons);
+		case 'E':	/* NEL - Next line */
+			vte_cr(currcons);
+			vte_lf(currcons);
 			return;
-		case '(':
-			vc_state = ESsetG0;
+		case 'H':	/* HTS - Character tabulation set */
+			tab_stop[x >> 5] |= (1 << (x & 31));
 			return;
-		case ')':
-			vc_state = ESsetG1;
+		case 'M':	/* RI - Reverse line feed */
+			vte_ri(currcons);
 			return;
-		case '#':
-			vc_state = EShash;
+		case 'Z':	/* DECID - Identify terminal */
+			/* XXX Fixme! This collides with ISO 6429! */
+			vte_da(tty);
 			return;
-		case 'c':
-			reset_terminal(currcons,1);
+		case '[':	/* CSI - Contro sequence introducer */
+			vc_state = EScsi;
 			return;
-		case '>':  /* Numeric keypad */
-			clr_kbd(kbdapplic);
+		case ']':	/* OSC - Operating system command */
+			/* XXX Fixme! Wrong sequence and sequence format! */
+			vc_state = ESosc;
 			return;
-		case '=':  /* Appl. keypad */
-			set_kbd(kbdapplic);
+
+			/* ===== Single control functions ===== */
+
+		case 'c':	/* RIS - Reset to initial state */
+			vte_ris(currcons,1);
 			return;
 		}
 		return;
-	case ESnonstd:
-		if (c=='P') {   /* palette escape sequence */
-			for (npar=0; npar<NPAR; npar++)
-				par[npar] = 0 ;
-			npar = 0 ;
+	case ESosc:
+		vc_state = ESinit;
+		switch (c) {
+		case 'P':	/* palette escape sequence */
+			/*
+			 * XXX Fixme! We should use the documented DEC
+			 * device control strings (DCS) instead.  OSC has
+			 * an entirely different meaning!
+			 */
+			for (npar = 0; npar < NPAR; npar++)
+				par[npar] = 0;
+			npar = 0;
 			vc_state = ESpalette;
 			return;
-		} else if (c=='R') {   /* reset palette */
+		case 'R':	/* reset palette */
+			/*
+			 * XXX Fixme! See comment above.
+			 */
 			reset_palette(currcons);
-			vc_state = ESnormal;
-		} else
-			vc_state = ESnormal;
+			vc_state = ESinit;
+			return;
+		}
 		return;
 	case ESpalette:
 		if ( (c>='0'&&c<='9') || (c>='A'&&c<='F') || (c>='a'&&c<='f') ) {
@@ -1539,12 +1821,12 @@
 				palette[i] = 16*par[j++];
 				palette[i] += par[j];
 				set_palette(currcons);
-				vc_state = ESnormal;
+				vc_state = ESinit;
 			}
 		} else
-			vc_state = ESnormal;
+			vc_state = ESinit;
 		return;
-	case ESsquare:
+	case EScsi:
 		for(npar = 0 ; npar < NPAR ; npar++)
 			par[npar] = 0;
 		npar = 0;
@@ -1566,15 +1848,20 @@
 			return;
 		} else vc_state=ESgotpars;
 	case ESgotpars:
-		vc_state = ESnormal;
+		vc_state = ESinit;
 		switch(c) {
-		case 'h':
+		case 'h':	/* SM - Set mode / DECSM - Set mode */
 			set_mode(currcons,1);
 			return;
-		case 'l':
+		case 'l':	/* RM - Reset mode / DECRM - Reset mode */
 			set_mode(currcons,0);
 			return;
 		case 'c':
+			/*
+			 * XXX Fixme!  Need to use final byte reserved for
+			 * private sequences instead of flag designating
+			 * private parameters!
+			 */
 			if (ques) {
 				if (par[0])
 					cursor_type = par[0] | (par[1]<<8) | (par[2]<<16);
@@ -1584,6 +1871,11 @@
 			}
 			break;
 		case 'm':
+			/*
+			 * XXX Fixme!  Need to use final byte reserved for
+			 * private sequences instead of flag designating
+			 * private parameters!
+			 */
 			if (ques) {
 				clear_selection();
 				if (par[0])
@@ -1594,12 +1886,35 @@
 			}
 			break;
 		case 'n':
-			if (!ques) {
-				if (par[0] == 5)
-					status_report(tty);
-				else if (par[0] == 6)
-					cursor_report(currcons,tty);
+			if (ques) {
+				switch (par[0]) {
+				case 6:	/* DECXCPR - Extended CPR */
+					vte_cpr(currcons, tty, 1);
+					break;
+				case 15:	/* DEC printer status */
+					vte_fake_dec_dsr(tty, "13");
+					break;
+				case 25:	/* DEC UDK status */
+					vte_fake_dec_dsr(tty, "21");
+					break;
+				case 26:	/* DEC keyboard status */
+					vte_fake_dec_dsr(tty, "27;1;0;1");
+					break;
+				case 75:	/* DEC data integrity */
+					vte_fake_dec_dsr(tty, "70");
+					break;
+				}
+			} else {
+				switch (par[0]) {
+				case 5:	/* DSR - Device status report */
+					vte_dsr(tty);
+					break;
+				case 6:	/* CPR - Cursor position report */
+					vte_cpr(currcons, tty, 0);
+					break;
+				}
 			}
+			ques = 0;
 			return;
 		}
 		if (ques) {
@@ -1607,83 +1922,118 @@
 			return;
 		}
 		switch(c) {
-		case 'G': case '`':
-			if (par[0]) par[0]--;
-			gotoxy(currcons,par[0],y);
+		case '@':	/* ICH - Insert character */
+			vte_ich(currcons,par[0]);
 			return;
-		case 'A':
+		case 'A':	/* CUU - Cursor up */
+		case 'k':	/* VPB - Line position backward */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,x,y-par[0]);
 			return;
-		case 'B': case 'e':
+		case 'B':	/* CUD - Cursor down */
+		case 'e':	/* VPR - Line position forward */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,x,y+par[0]);
 			return;
-		case 'C': case 'a':
+		case 'C':	/* CUF - Cursor right */
+		case 'a':	/* HPR - Character position forward */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,x+par[0],y);
 			return;
-		case 'D':
+		case 'D':	/* CUB - Cursor left */
+		case 'j':	/* HPB - Character position backward */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,x-par[0],y);
 			return;
-		case 'E':
+		case 'E':	/* CNL - Cursor next line */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,0,y+par[0]);
 			return;
-		case 'F':
+		case 'F':	/* CPL - Cursor preceeding line */
 			if (!par[0]) par[0]++;
 			gotoxy(currcons,0,y-par[0]);
 			return;
-		case 'd':
+		case 'G':	/* CHA - Cursor character absolute */
+		case '`':	/* HPA - Character position absolute */
 			if (par[0]) par[0]--;
-			gotoxay(currcons,x,par[0]);
+			gotoxy(currcons,par[0],y);
 			return;
-		case 'H': case 'f':
+		case 'H':	/* CUP - Cursor position */
+		case 'f':	/* HVP - Horizontal and vertical position */
 			if (par[0]) par[0]--;
 			if (par[1]) par[1]--;
 			gotoxay(currcons,par[1],par[0]);
 			return;
-		case 'J':
-			csi_J(currcons,par[0]);
+		case 'I':	/* CHT - Cursor forward tabulation */
+			if (!par[0]) par[0]++;
+			vte_cht(currcons,par[0]);
 			return;
-		case 'K':
-			csi_K(currcons,par[0]);
+		case 'J':	/* ED - Erase in page */
+			vte_ed(currcons,par[0]);
 			return;
-		case 'L':
-			csi_L(currcons,par[0]);
+		case 'K':	/* EL - Erase in line */
+			vte_el(currcons,par[0]);
 			return;
-		case 'M':
-			csi_M(currcons,par[0]);
+		case 'L':	/* IL - Insert line */
+			vte_il(currcons,par[0]);
 			return;
-		case 'P':
-			csi_P(currcons,par[0]);
+		case 'M':	/* DL - Delete line */
+			vte_dl(currcons,par[0]);
 			return;
-		case 'c':
+		case 'P':	/* DCH - Delete character */
+			vte_dch(currcons,par[0]);
+			return;
+		case 'W':	/* CTC - Cursor tabulation control */
+			switch (par[0]) {
+			case 0:	/* Set character tab stop at current position */
+				tab_stop[x >> 5] |= (1 << (x & 31));
+				return;
+			case 2:	/* Clear character tab stop at curr. position */
+				vte_tbc(currcons, 0);
+				return;
+			case 5:	/* All character tab stops are cleared. */
+				vte_tbc(currcons, 5);
+				return;
+			}
+			return;
+		case 'X':	/* ECH - Erase character */
+			vte_ech(currcons, par[0]);
+			return;
+		case 'Y':	/* CVT - Cursor line tabulation */
 			if (!par[0])
-				respond_ID(tty);
+				par[0]++;
+			vte_cvt(currcons, par[0]);
+			return;
+		case 'Z':	/* CBT - Cursor backward tabulation */
+			vte_cbt(currcons, par[0]);
 			return;
-		case 'g':
+		case ']':	/* setterm functions */
+			/* XXX Fixme! This collides with ISO 6429! */
+			setterm_command(currcons);
+			return;
+		case 'c':	/* DA - Device attribute */
 			if (!par[0])
-				tab_stop[x >> 5] &= ~(1 << (x & 31));
-			else if (par[0] == 3) {
-				tab_stop[0] =
-					tab_stop[1] =
-					tab_stop[2] =
-					tab_stop[3] =
-					tab_stop[4] = 0;
-			}
+				vte_da(tty);
 			return;
-		case 'm':
-			csi_m(currcons);
+		case 'd':	/* VPA - Line position absolute */
+			if (par[0]) par[0]--;
+			gotoxay(currcons,x,par[0]);
 			return;
-		case 'q': /* DECLL - but only 3 leds */
-			/* map 0,1,2,3 to 0,1,2,4 */
+		case 'g':	/* TBC - Tabulation clear */
+			vte_tbc(currcons, par[0]);
+			return;
+		case 'm':	/* SGR - Select graphic rendition */
+			vte_sgr(currcons);
+			return;
+
+			/* ===== Private control sequences ===== */
+
+		case 'q': /* DECLL - Load LEDs */
 			if (par[0] < 4)
 				setledstate(kbd_table + currcons,
 					    (par[0] < 3) ? par[0] : 4);
 			return;
-		case 'r':
+		case 'r':	/* DECSTBM - Set top and bottom margin */
 			if (!par[0])
 				par[0]++;
 			if (!par[1])
@@ -1696,25 +2046,13 @@
 				gotoxay(currcons,0,0);
 			}
 			return;
-		case 's':
-			save_cur(currcons);
-			return;
-		case 'u':
-			restore_cur(currcons);
-			return;
-		case 'X':
-			csi_X(currcons, par[0]);
-			return;
-		case '@':
-			csi_at(currcons,par[0]);
-			return;
-		case ']': /* setterm functions */
-			setterm_command(currcons);
+		case 'x':	/* DECREQTPARM - Request terminal parameters */
+			vte_decreptparm(currcons, tty);
 			return;
 		}
 		return;
-	case ESpercent:
-		vc_state = ESnormal;
+	case ESdocs:
+		vc_state = ESinit;
 		switch (c) {
 		case '@':  /* defined in ISO 2022 */
 			utf = 0;
@@ -1726,21 +2064,21 @@
 		}
 		return;
 	case ESfunckey:
-		vc_state = ESnormal;
+		vc_state = ESinit;
 		return;
-	case EShash:
-		vc_state = ESnormal;
+	case ESscf:
+		vc_state = ESinit;
 		if (c == '8') {
 			/* DEC screen alignment test. kludge :-) */
 			video_erase_char =
 				(video_erase_char & 0xff00) | 'E';
-			csi_J(currcons, 2);
+			vte_ed(currcons, 2);
 			video_erase_char =
 				(video_erase_char & 0xff00) | ' ';
 			do_update_region(currcons, origin, screenbuf_size/2);
 		}
 		return;
-	case ESsetG0:
+	case ESgzd4:
 		if (c == '0')
 			G0_charset = GRAF_MAP;
 		else if (c == 'B')
@@ -1751,9 +2089,9 @@
 			G0_charset = USER_MAP;
 		if (charset == 0)
 			translate = set_translate(G0_charset,currcons);
-		vc_state = ESnormal;
+		vc_state = ESinit;
 		return;
-	case ESsetG1:
+	case ESg1d4:
 		if (c == '0')
 			G1_charset = GRAF_MAP;
 		else if (c == 'B')
@@ -1764,10 +2102,10 @@
 			G1_charset = USER_MAP;
 		if (charset == 1)
 			translate = set_translate(G1_charset,currcons);
-		vc_state = ESnormal;
+		vc_state = ESinit;
 		return;
 	default:
-		vc_state = ESnormal;
+		vc_state = ESinit;
 	}
 }
 
@@ -1861,47 +2199,47 @@
 		  tc = translate[toggle_meta ? (c|0x80) : c];
 		}
 
-                /* If the original code was a control character we
-                 * only allow a glyph to be displayed if the code is
-                 * not normally used (such as for cursor movement) or
-                 * if the disp_ctrl mode has been explicitly enabled.
-                 * Certain characters (as given by the CTRL_ALWAYS
-                 * bitmap) are always displayed as control characters,
-                 * as the console would be pretty useless without
-                 * them; to display an arbitrary font position use the
-                 * direct-to-font zone in UTF-8 mode.
-                 */
-                ok = tc && (c >= 32 ||
-                            (!utf && !(((disp_ctrl ? CTRL_ALWAYS
-                                         : CTRL_ACTION) >> c) & 1)))
-                        && (c != 127 || disp_ctrl)
+		/* If the original code was a control character we
+		 * only allow a glyph to be displayed if the code is
+		 * not normally used (such as for cursor movement) or
+		 * if the disp_ctrl mode has been explicitly enabled.
+		 * Certain characters (as given by the CTRL_ALWAYS
+		 * bitmap) are always displayed as control characters,
+		 * as the console would be pretty useless without
+		 * them; to display an arbitrary font position use the
+		 * direct-to-font zone in UTF-8 mode.
+		 */
+		ok = tc && (c >= 32 ||
+			    (!utf && !(((disp_ctrl ? CTRL_ALWAYS
+			                 : CTRL_ACTION) >> c) & 1)))
+			&& (c != 127 || disp_ctrl)
 			&& (c != 128+27);
 
-		if (vc_state == ESnormal && ok) {
+		if (vc_state == ESinit && ok) {
 			/* Now try to find out how to display it */
 			tc = conv_uni_to_pc(vc_cons[currcons].d, tc);
 			if ( tc == -4 ) {
-                                /* If we got -4 (not found) then see if we have
-                                   defined a replacement character (U+FFFD) */
-                                tc = conv_uni_to_pc(vc_cons[currcons].d, 0xfffd);
+			        /* If we got -4 (not found) then see if we have
+			           defined a replacement character (U+FFFD) */
+			        tc = conv_uni_to_pc(vc_cons[currcons].d, 0xfffd);
 
 				/* One reason for the -4 can be that we just
 				   did a clear_unimap();
 				   try at least to show something. */
 				if (tc == -4)
 				     tc = c;
-                        } else if ( tc == -3 ) {
-                                /* Bad hash table -- hope for the best */
-                                tc = c;
-                        }
+			} else if ( tc == -3 ) {
+			        /* Bad hash table -- hope for the best */
+			        tc = c;
+			}
 			if (tc & ~charmask)
-                                continue; /* Conversion failed */
+			        continue; /* Conversion failed */
 
 			if (need_wrap || decim)
 				FLUSH
 			if (need_wrap) {
-				cr(currcons);
-				lf(currcons);
+				vte_cr(currcons);
+				vte_lf(currcons);
 			}
 			if (decim)
 				insert_char(currcons, 1);
@@ -2026,14 +2364,14 @@
 				cnt = 0;
 			}
 			if (c == 8) {		/* backspace */
-				bs(currcons);
+				vte_bs(currcons);
 				start = (ushort *)pos;
 				myx = x;
 				continue;
 			}
 			if (c != 13)
-				lf(currcons);
-			cr(currcons);
+				vte_lf(currcons);
+			vte_cr(currcons);
 			start = (ushort *)pos;
 			myx = x;
 			if (c == 10 || c == 13)
@@ -2274,7 +2612,7 @@
 	ulcolor		= 0x0f;   /* bold white */
 	halfcolor       = 0x08;   /* grey */
 	vt_cons[currcons]->paste_wait = 0;
-	reset_terminal(currcons, do_clear);
+	vte_ris(currcons, do_clear);
 }
 
 /*
@@ -2363,7 +2701,7 @@
 	set_origin(currcons);
 	save_screen(currcons);
 	gotoxy(currcons,x,y);
-	csi_J(currcons, 0);
+	vte_ed(currcons, 0);
 	update_screen(fg_console);
 	printk("Console: %s %s %dx%d",
 		can_do_color ? "colour" : "mono",
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand

Re: [Linuxconsole-dev] Which tree and developers

[Vojtech P. <vo...@su...>]

On Wed, Mar 08, 2000 at 11:03:42AM -0500, James Simmons wrote:

> Looks good. Should we go with vt_ or vc_ since in theory you could have
> virtual consoles on serial consoles as well?  Or have virtual terminal
> handling only for video terminals. I also assume this is for now. the
> "ruby" series will different for kb_ since this will be intergrated with
> Vojtech's work.   
> 
> 
> P.S
> 
>   Vojtech I tried your patch against 2.3.50-3. It bomded. I was wondering
> if you updated it already so we don't duplicate effort here. 

I did not yet. However, I have updated most of the drivers in it quite a
bit and I'll be releasing an updated patch rather soon hopefully.

-- 
Vojtech Pavlik
SuSE Labs

Re: [Linuxconsole-dev] Municon

[Eric S. R. <es...@th...>]

Jim Peters <ji...@ag...>:
> Any comments ?  Anyone spotted any design flaws ?

The one I pointed out earlier.  What about runlevel 1?
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance?  Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and tyrants.
	-- Thomas Jefferson, letter to Col. William S. Smith, 1787 

Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Eric S. R. <es...@th...>]

Jim Peters <ji...@ag...>:
> Another idea - the terminal emulator can live in user-space (a terminal-
> emulator daemon ?), sitting on top of the normal Linux console code, or
> fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.
> 
> It doesn't need to go into the kernel.  If we take the GGI approach of only
> having hardware-banging stuff in the kernel, then there is no reason to have
> the terminal emulator live there as well.  If we can get all the services we
> need from the kernel one way or another, then the terminal emulator can live
> outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.
> 
> This may need to be a high-priority process to keep the display up-to-date
> in the face of high system loads.  This is a downside, but there is also the
> up-side that the application does not block whilst the display is updated
> (as with a kernel solution), but only when the pipe buffer is full.  A
> daemon updating once every frame or so could cut out a lot of unnecessary
> updates when applications have rolling counters or whatever.
> 
> Any objections to this idea ?

One big one.  I fear some terminal emulation has to be in the kernel,
otherwise the user will lose badly in pathological situations where the
hypothetical daemon doesn't start up.  Never forget the run-level 1 case.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives
[only] moderate exercise to the body, it gives boldness, enterprise,
and independence to the mind.  Games played with the ball and others
of that nature, are too violent for the body and stamp no character on
the mind. Let your gun, therefore, be the constant companion to your
walks."
        -- Thomas Jefferson, writing to his teenaged nephew.