I use GNU/Linux (Ubuntu, specifically) on my desktop, as well as the servers I run. The 2161DS-2 kvm-over-ip serves up a Java program (with java web start, etc. etc.) that runs on the client computer, and that connects back to the kvm switch on TCP/2068. Anyway, when I use the client on my laptop, which I've upgraded to Ubuntu's upcoming release (Intrepid, using xorg 7.4, xserver-xorg-core 1.5.0), the arrow keys send the wrong keyboard scancodes to the remote system (via the USB SIP). e.g. pressing up arrow will launch the GNOME screenshot applet if the remote system is running a GNOME desktop (e.g. netbooted nfsroot Ubuntu desktop liveCD). A lot of things work fine with ^n and ^p instead of up/down arrow (in GNU/Linux, and syslinux's pxelinux menus), but I was having real problems with some BIOS menus that only sort of seemed to work using tab to advance to the next item... I've confirmed with showkey that different scancodes are being received on the remote system than what a local keyboard generates on a local system. Right arrow doesn't generate any keysyms at all on the remote system.
BTW, before I upgraded to Ubuntu Intrepid, my X server was using the kbd keyboard driver and everything was fine. Xorg is switching from kbd to evdev for keyboard drivers, and this means the arrows keys now send different keycodes than they used to. Keysyms are the same of course, since they map 1:1 with key names like Up. Eventually even RedHat and Suse will ship Xorg server 1.5, so it's not like this is an Ubuntu-only problem. It's a recent-xorg problem.
evdev:
$ setxkbmap -print
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)+ctrl(nocaps)" }; xkb_geometry { include "pc(pc105)" };};
evdev: left = 113 right = 114 up = 111 down = 116
kbd:
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_symbols { include "pc+us+ctrl(nocaps)" };
left = 100 right = 102 up = 98 down = 104
I assume the Java program looks at the keycodes directly to generate scancodes for the remote system, instead of using keysyms and having a reverse X keymap as well as a reverse scancode -> keycode map. Or maybe this is the JVM's fault. The Java Web Start file that the 2161ds-2 sends the browser specifically calls for jre1.5.0_11 (which gets installed to ~/.java/deployment/cache by the Sun Java6 jre that downloaded it) so that's what I'm using. Maybe it's the JVM that's not portable to systems with evdev keyboards, not the viewer program... I tried editting viewer.jnlp to require java 1.6.0_07 (the version of Ubuntu Intrepid's java package) before running javaws on it. It connects, but the keyboard is completely non-functional. Keystrokes sent using the menu do get through, though. And everything else seems to work.
So, please fix the 2161ds-2 firmware to serve up a viewer that works on modern GNU/Linux systems. In the meantime, just don't use evdev, or live without arrow keys. X really really wants to use it, though, and will enable it and have it take over all your input devices if there's any input device that's not in your config file or something. I don't know how to do it on my laptop with a built-in touchpad, but my desktop is ok using kbd.
BTW, is this forum the right place for this? I didn't see a bug report link anywhere on Dell's support web site. And I didn't write down the service tag on the kvm switch when I was in the machine room. Besides, I'd rather not go through the hassle of official support channels, if it's anything like what I've seen from other vendors. I know what's wrong (at least I'm pretty sure); I'm telling you so you can fix it.
It would be nice if the Java viewer program didn't ever get stuck with a key down. e.g. I fairly frequently see it press ESC repeately after I press it just once. It stops when I press another key. This is annoying in BIOS menus, although fortunately on the PE1950 servers I have this just flashes the "save and exit" menu on and off. The tab key also sometimes stops working until the viewer loses focus and then regains it again. I usual run the viewer windowed, not fullscreen, because it's so slow to update its screen that I don't want to browse the web inside it. So I'm always switching to a local web browser and terminal window, in case that matters.
It would also be nice to have a menu items to hold control or alt until the menu item was unticked. vncviewer from realvnc does that well: pressing F8 brings up a menu. Another F8 sends F8 to the remote system. Otherwise, you can click items on the menu to hold alt or control. It's easy to send alt-tab or whatever to the remote system that way. Or if your window manager ignores alt-tab if you do it while also pressing Super, the remote side will get an alt-tab. (the Windows keys are usually mapped to Super on recent GNU/Linux on PC keyboards.)
I'd also like to be able to switch between servers without exitting one viewer and launching another. It takes probably 10 seconds on this P4-2.8GHz laptop! The 2161ds-2's broadcast feature also doesn't seem to be available remotely. It was very useful for setting the BIOS settings on all the machines when I used it locally.
Is there alternate client software for the 2161ds-2? I've never used OpenManage or any software from Dell, just the web interface. I got the impression that the web interface could do everything, but if there's another way to access it that uses different client software, it might do the key mapping more portably.
--
Thanks,
Peter Cordes