works from startup, and works with XFree86 via /dev/sysmouse, it should
be started at boot and left running.
Pointed out by: Sujal Patel <smpatel@umiacs.umd.edu>
and xdm, possibly in general.
What was happening was that the server was doing a tcsetattr(.. TCSADRAIN)
on the mouse fd after a write. Since /dev/sysmouse had a null t_oproc,
the drain failed with EIO. Somehow this spammed XFree86 (!@&^#%*& binary
release!!), and the driver was left in a bogus state (ie: switch_in_progress
permanently TRUE).
The simplest way out was to implement a dummy scmousestart() routine to
accept any characters from the tty system and toss them into the void.
It would probably be more correct to intercept scwrite()'s to the mouse
device, but that's executed for every single write to the screen.
Supplying a start routine to eat the characters is only executed for the
mouse port during startup/shutdown, so it should be faster.
-I- to CFLAGS. <sb.h> must currently be used to give the version
of sb.h in the current directory, while "sb.h" in the buggy version
gave the (wrong) version in the source directory. Searching in the
source directory first is normal, but is the reverse of the order
suggested by the 4.4Lite2 #include style. -I- will remove the
ambiguities.
I could find. This change does the following:
- s/usage()/break;/ in handling the -s switch.
- use err/warn instead of fprintf(stderr, ... strerror()); exit(1);
- implement Hitachi PUMA HitTablet support from the XFree86 code,
whatever the hell that is. :-)
- correctly implement baud rate setting, too much was cut from the
XFree86 code, the critical parts were a sweep over all likely
mouse powerup baud rates to switch it to the reqested rate.
- logitech support was busted (at least on mine, which is autosensing
and runs in either mmseries or logitech mode depending on the handshake
code at startup. Among other things, you talk to it at 1200, then
switch to the target baud later.
Some remaining problems.. samplerate setting is missing, but I've not
found where this is meant to be set yet. I presume this is resolution
setting of some kind.
In case you're wondering, the gcc-2.7.2.1 import uses this to generate
code. The size of the generated code is bigger than the entire bison
release, making this a saving. The bison doc is pretty good apparently.
conflict with the other declarations in other files. tputs() is
traditionally declared to return int, not void. curses.h has it as int.
ncurses has int and actually sets the return value. This problem has
been causing the ircII port to not compile.
(I've only minimally tested this, I do not have libtermcap on my systems)
Sorry if this makes it harder to merge in lite2 stuff but hey..
At least I can figure out what is going on whenever I end up going through those
files again..
do we have a policy regarding commenting existing code?
the real buffer size. Note that the strncpy(domain, ...) doesn't need to
be a strncpy(), since it is copying from itself to itself, but belts
and suspenders don't hurt and this is not time-critical code.
Fixes the half of PR bin/1581 that wasn't fixed in rev 1.7
Submitted by: Karl <karl@codebase.mcs.net>
Submitted-By: "David E. O'Brien" <obrien@Nuxi.cs.ucdavis.edu>
Incorporate new development section, since Satoshi seems to have wandered
off for a bit and I have too much stuff stacking up in my handbook directory.
Submitted-By: asami
