Discussion:
is it just me?
(too old to reply)
hymie!
2018-07-25 20:15:53 UTC
Permalink
I really hope this isn't UI.

We just had a bit of a discussion at my orkplace.

I had a KVM used to access a bunch of machines that are network-segregated.
$OldKVM had a neat feature -- you could tap RightCtl RightCtl followed
by a zero-padded two-digit number and $OldKVM would switch to that
numbered port. $OldKVM died.

I bought a new KVM. $NewKVM has the same feature, but set up somewhat
differently. You could press-and-hold LeftShift [1] , type a one- or two-
digit number, and release LeftShift, and $NewKVM will switch to that
numbered port.

Well, it almost works like that. In actuality, you can press-and-hold
LeftShift, type a one- or two- digit number, which will send the
appropriate punctuation characters to the currently-selected port, and
then release LeftShift, and $NewKVM will switch to that numbered port.

I maintain that this is broken behavior. $NewKVM should NOT be sending
to the port a set of keystrokes that are clearly designed to be
interpreted by the KVM.

But I was the only one who felt that way. The other people in my
discussion group (and $NewKVM's technical support team) believed that
it was more important to make sure that any key combination COULD be sent
to the port, even if you don't want to, rather than create a situation
where a key combination CANNOT be sent. $NewKVM manufacturer described
this as "intended behavior / WONTFIX" and suggested I pick a different
key that "does not affect the target".

I'm hoping to find somebody who agrees with me, that the negative potential
for sending unwanted characters to a server should be the bigger
concern -- in the most extreme case, I don't want to access a machine's
console and find that a ! character is waiting for the command I plan to
type. Failing that, maybe somebody can convince me why I'm wrong.

--hymie! http://lactose.homelinux.net/~hymie ***@lactose.homelinux.net

[1] I could also have configured the KVM to use LeftCtl or LeftAlt.
I'm using LeftShift specifically to demonstrate the problem. But the
problem affects all three key combinations.
Stephen Harris
2018-07-25 20:30:23 UTC
Permalink
Post by hymie!
type. Failing that, maybe somebody can convince me why I'm wrong.
It wouldn't suprise me if your old one also sent key-down key-up events
for RightCtrl; you just never noticed it because the trigger sequence
(RightCtrl RightCtrl) had no impact, and the characters after that
weren't sent through.

Correct behaviour is probably to have the key sequence cached and sent
to the target device if it's not successfully completed as a "switch
input" sequence, similar to how "~" may be deferred in ssh (or tip
or...) after a RETURN, just in case the next character is a command
("RETURN ~ .")

If you do a successful switch then the sequence doesn't get sent.

So if you do a Shift-Down 1 A then the "A" would terminate the sequence
and the 4 events (shift-Down 1-Down 1-up A-down) would be sent.

If you do a Shift-Down 1 Shift-Up then no sequence would be sent and
the input would switch.
--
rgds BOFHnet search: https://bofh.spuddy.org/
Stephen (Contact me if you want access)
m***@att.net
2018-08-11 06:48:27 UTC
Permalink
Post by hymie!
$OldKVM had a neat feature -- you could tap RightCtl RightCtl
followed by a zero-padded two-digit number and $OldKVM would switch
to that numbered port.
IME, it's almost never useful to press and then immediately release
Control or Alt. The only times I can think of doing it are 1) when I'm
trying to cancel the screen-saver or 2) when I'm running a diagnostic
program that makes sure that all of the keys work. So, using that as a
key sequence to control the KVM seems reasonable to me.
Post by hymie!
$NewKVM has the same feature, but set up somewhat differently. You
could press-and-hold LeftShift [1] , type a one- or two- digit number,
and release LeftShift, and $NewKVM will switch to that numbered port.
Sometimes holding Shift and hitting the number keys is something you
actually want to do; it will make the software do something useful.
So I can understand the argument of making it possible to send that
sequence through.

I think it would be OK if $NewKVM didn't pass through the symbols for
hold-left-shift;number;number, and *did* pass through the symbols for
hold-right-shift;number;number. That lets you use left-shift to talk
to the KVM, and right-shift to talk to the connected machine. (In
other words, I think it's not very common at all for software to care
about *which* Shift key you're using.)
Post by hymie!
I maintain that this is broken behavior. $NewKVM should NOT be
sending to the port a set of keystrokes that are clearly designed to
be interpreted by the KVM.
I agree with this idea. You ought to have control over what keystrokes
you do and don't send to the connected machine. The old KVM gave you
that, but the new one doesn't seem to.
Post by hymie!
The other people in my discussion group (and $NewKVM's technical
support team) believed that it was more important to make sure that
any key combination COULD be sent to the port, even if you don't want
to, rather than create a situation where a key combination CANNOT be
sent.
In-band signaling is hard. A well-known System that was designed by
geniuses (to be operated by idiots) had a bunch of trouble with it, back
in the day. Unlrf got it right, but some of the knockoffs didn't.
Post by hymie!
$NewKVM manufacturer described this as "intended behavior / WONTFIX"
and suggested I pick a different key that "does not affect the
target".
It's probably less common for alt-(number) or control-(number) to do
something useful to the software, so configuring $NewKVM to use that
key would be a little better. I would still argue that it is more
common for alt-(number) or control-(number) to do something useful,
than it is for the tap-tap-numbers sequence of $OldKVM.

On the other hand, I haven't been paid to play with wacky fun computars
for around a year now, so take this with an appropriate amount of salt.

Matt Roberds

Loading...