[PATCH] Resume TTY on SUSP and fix CRNL order in N_TTY line discipline

) behaves like INTR and QUIT in resuming a stopped TTY. 2) Adjust the order in which the IGNCR/ICRNL/INLCR processing is applied to be more logical and consistent with the behavior of other Unix systems. Signed-off-by: Joe Peterson <[EMAIL PROTECTED]> --- diff -puN drivers/char/n

Re: [PATCH] (*revised*) Fix IXANY and restart after signal (e.g. ctrl-C) in n_tty line discipline

Andrew Morton wrote: > What were the "couple of issues"? They are the same 2 issues described in the original version of the patch and included in the text of this one too (i.e. the text at the start of this latest patch version is the same as before). >> This patch should *replace* the old versi

[PATCH] (*revised*) Fix IXANY and restart after signal (e.g. ctrl-C) in n_tty line discipline

rupt signals were ignored in a stopped TTY until the TTY was resumed with the start char (typically ctrl-Q), which was inconsistent with the behavior of other Unix systems. Signed-off-by: Joe Peterson <[EMAIL PROTECTED]> --- diff -puN drivers/char/n_tty.c~fix-ixany-and-restart-after-sign

[PATCH] Fix IXANY and restart after signal (e.g. ctrl-C) in n_tty line discipline

sistent with the behavior of other Unix systems. Signed-off-by: Joe Peterson <[EMAIL PROTECTED]> --- diff -puN a/drivers/char/n_tty.c~tty-fix-ixany-and-restart-after-signal-in-the-n_tty-discipline a/drivers/char/n_tty.c --- a/drivers/char/n_tty.c~tty-fix-ixany-and-restart-after-signal-

[PATCH] Enabling the echo of ctrl-C (and the like)

Attached is a patch that turns on INTR/QUIT/SUSP echoing in the N_TTY line discipline (e.g. ctrl-C will appear as "^C" if stty echoctl is set and ctrl-C is set as INTR). Linux seems to be the only unix-like OS (recently I've verified this on Solaris, BSD, and Mac OS X) that does *not* behave this

[PATCH] echo ctrl characters on INTR/QUIT/SUSP

The stty setting, "echoctl", directs the tty to echo control characters as a normal letter prefixed by "^" (such as "^C" for the default INTR setting). Linux does not currently echo for the INTR/QUIT/SUSP signals, whereas all other "unix" variants I have used over the years do, to my recollection

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

Dave Neuer wrote: > On 8/15/05, Joe Peterson <[EMAIL PROTECTED]> wrote: > >>So, overall, I agree that we should not invent hacks to make up for >>another software package's problems... > > > but also wrote: > > >>If the kernel could h

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

Vojtech Pavlik wrote: I am using evtouch, but I had read that X itself has an issue with devices that are not "always there" and that X does not [yet] seem to be designed to handle hotplugging well (for example, device names need to be hard-coded in xorg.conf, so a changing device n

Re: [PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

Vojtech Pavlik wrote: > On Mon, Aug 15, 2005 at 11:27:56AM -0600, Joe Peterson wrote: > > >>I, and a growing number of others, have been having trouble with using >>touch screen devices in Linux, particularly the motorized ones that fit >>into car dashboards. The pr

[PATCH] to drivers/input/evdev.c to add mixer device "/dev/input/events"

12:15.0 -0600 +++ linux-2.6.12/drivers/input/evdev.c 2005-08-15 11:12:11.0 -0600 @@ -8,8 +8,17 @@ * the Free Software Foundation. */ +/* + * Modified 2005-8-12 Joe Peterson + * + * - Added persistent mixer device "/dev/input/events" + * (analogous to mou