KVM/Scroll Lock behavior

2012-01-18 Thread Todd Pytel
Hi all,

I'm digging around at a quirk involving Scroll Lock and KVM switching
that I think X is responsible for and hoping someone here can explain
it. At this point I can work around it myself. But I'd really like to
understand it, or perhaps provoke a change to make it work better for
others less inclined to dig at this than I am.

Like many other KVM's out there, mine triggers switches through double
Scroll Lock taps. This has often required some fiddling to get working
properly in the past, usually by adding Scroll_Lock to mod3 using
xmodmap. But sometime recently, (I think) something changed in X11's key
handling. A while back, my GNOME desktop stopped switching on Scroll
Lock (even with the xmodmap) but still switched on Num Lock. Then it
stopped working entirely in GNOME, XFCE, or Openbox.

What I found after poking around some more tonight is that I can get the
KVM trigger working by twiddling the LED's with xset...

xset led 3 && sleep 0.2 && xset -led 3

That toggles the LED's and triggers the KVM.

In some sense, this solves my problem. I can put that in a script and
bind it to a key. But I'd like to actually understand what's going on.
Also, since Scroll Lock is the most common KVM trigger, it would be nice
to fix this so that it "just works" for people with less enthusiasm for
this sort of detective work. It seems like this shouldn't be an
earth-shaking architectural change, but I admit I don't know jack about
the internals of X.

Specifically, here's what I see on Debian Sid...

1) In the console, Scroll Lock and KVM switching work properly with no
tweaks.

2) In an untweaked X session, the Num Lock LED works while the Scroll
Lock one does not. Both keys register in xev output.

3) After "xmodmap -e 'add mod3 = Scroll_Lock'", the Scroll Lock LED
works. But it still doesn't trigger the KVM.

4) Even without the xmodmap line, twiddling the LED's via xset both
toggles the LED's and triggers the KVM.

What I'd really like to understand is what's different internally
between toggling the LED via xset and doing it through an xmodmap'd
Scroll Lock. Clearly the KVM is seeing those events differently and I
don't know enough about X to understand why. 

If it's not too much of an undertaking, I'd also suggest that Scroll
Lock should work as expected, or at least have an easy xorg.conf option
to make it work as expected. A little Googling will show a decade's
worth of posts across the web from KVM users trying to get their boxes
to switch properly. And since the old xmodmap solution doesn't work
anymore, it would be helpful to have a solution that doesn't involve
hacky scripts and keybinding.

Cheers!
Todd

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com


Re: KVM/Scroll Lock behavior

2012-01-18 Thread Todd Pytel
On Wed, 2012-01-18 at 20:21 -0800, milk wrote:
> As far as I know, the KVM switching should be hardware triggered. It
> should not be related to X at all

Well, that may be how it *should* work. But since switching works in the
console, but not in several different WM's/desktops, it sure looks it
actually works differently. 

--Todd

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com


Re: KVM/Scroll Lock behavior

2012-01-19 Thread Todd Pytel
On Thu, 2012-01-19 at 10:34 +0100, Samuel Thibault wrote:
> These are extremely surprising. I'd have thought that KVM uses the
> keyboard *keypresses*, not the LED changes, to achieve the switch...

Especially since it's not *just* the LED's that matter - otherwise it
would work after xmodmap. So, it's not just the LED's and not just the
keypresses. Very strange indeed.

It would be interesting to know whether this is standard KVM behavior.
They pretty much all use Scroll Lock, but I imagine that they could be
built on a variety of cheap, undocumented chips that exhibit different
quirks like these.


> I guess if you use setleds in the Linux console, the KVM switches too?

Yes, just checked it out. I forgot about setleds before.


> You could try to use strace to check the system call difference between
> lighting scroll lock through the key and through xset, but in principle
> there is none, thus the surprise with 3) vs 4) above.

I've straced binaries before, though the output tends to be over my
head. I could do that with xset, but what process would I strace to
follow the keypress? X? That seems likely to produce an insane amount of
output.

--Todd

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com