Date: Sat, 8 Mar 1997 16:16:12 +0100 (MET) From: Søren Schmidt <sos@ravenock.cybercity.dk> To: brian@awfulhak.demon.co.uk (Brian Somers) Cc: brian@freefall.freebsd.org, CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-usrsbin@freefall.freebsd.org Subject: Re: cvs commit: src/usr.sbin/vidcontrol decode.h Makefile decode.c vidcontrol.1 vidcontrol.c Message-ID: <199703081516.QAA09032@ravenock.cybercity.dk> In-Reply-To: <199703081445.OAA01635@awfulhak.demon.co.uk> from Brian Somers at "Mar 8, 97 02:45:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Brian Somers who wrote:
> > What's the idea of this ?? vidcontrol uses stdin which is the
> > current vty :)
> > Also I'd like you to have me review patches to code under my wings.
> > I'll look it over (later) and see whats actually going on.
> >
>
> Sorry, I didn't mean to stomp on anyones toes. This was IMO the best
> place for this, and I think it's required. The description, unfortunately
> leaves a bit to be desired.
Yeah, maybe but the wrong procedure...
> The change essentially allows the user to change the active vty via a
> call to ioctl(0,VT_ACTIVATE,"1..12"). You still have to either be on
> a vty or redirect stdin from one (ie, be root). The reason this is
> necessary is because a few people have complained on usenet that they've
> had lock-ups on machines with PS/2 mice configured. They have ended up
> rebooting their machines from a telnet/serial connection.
There has been alot of changes in the way the system handles ps/2
mice lately. Are you absolutely sure that this problem still exists ??
How are the supposed to issue the vidcontrol command if the machine
is locked up ??
> I noticed this some time ago and mentioned it (on usenet), only to be
> told that I had a bad keyboard. It was happening on 3 or 4 machines, so
> I decided to "take a look". I couldn't find the problem - mostly because
> it's a non-reproducable problem and is very intermittent, but I found
> that switching vtys would solve it. I wrote a program called "setcon"
> which I put on ftp.freebsd.org/~brian and my own web page. When some
> people recently complained about the problem, I figured that something
> more solid should be done.....
Like finding out WHY this is happening ??
> Anyway, take a look at the changes. They aren't too obtuse and don't
> affect any of the rest of the code. When I -Wall'd the code, I found
> that there were several calls to close(FILE*) - probably as well that
> these have been fixed.
Well, besides the close->fclose it is mostly cosmetical, but
whatever, that is not the point. The point is that I think you have
implemented a solution to hide the problem, instead of finding
out why the problem exists. This may all be well and good, but
its the wrong method, as you should try hard to find out what is
the problem and then solve it, or we will will have the system full
of kludges in no time.
Other that that I guess we could use a way to switch screen other
that issueing the right esc sequence :).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703081516.QAA09032>