Thomas, I had a somewhat similar problem with the CAPS Lock key but mine was not happening in mid-stream as yours appears to be doing. It may give you some ideas, though. This was back in 2008 so that particular problem may already have been addressed.
---------------------------- - Reboot the thin client. It's now at the stage where you are offered the choice of launching Windows ["Invoke Windows (WTS)"]. - Hit the CAPS Lock so the light goes on. - Click "Invoke Windows" - When you now type, the light is on even though CAPS Lock is off. The way to undo it is to reboot the thin client. The problem appears to be the following: the Windows connector assumes the CAPS Lock key is off. When it makes the connection to Windows, it must ignore the setting of the CAPS Lock key. Thus, CAPS Lock is actually disengaged even though the LED is on [and vice versa]. I've experimented several times and this is the outcome every time. It appears to be operating on a relative basis ["Assume CAPS Lock is off. When I get a toggle, turn the CAPS Lock on; when I get another toggle, turn it off", etc] instead of an absolute basis ["What is the current setting of the CAPS Lock key?"]. I found at least one article that concurs. The problem is that this is happening before the user even gets in to Windows so the suggested fix involving Outlook won't help. http://www.mail-archive.com/[email protected]/msg08092.html http://sunsolve.sun.com/search/document.do?assetkey=1-21-119067-09-1 4201153 can't get/set Caps Lock LED state via XGetKeyboardControl() and Xchang http://sunsolve.sun.com/search/document.do?assetkey=1-1-4201153-1 [Even though the below deals with SunPCi, it sounds very similar.] SunPCi needs to be able to ascertain and modify the keyboard LED state of the Caps, Scroll, and Num lock keys programatically, as the PC stores the state of these keys independently from the X server. For example, if you are in the SunPCi window and turn on the Caps lock key the PC stores the fact that it's down internally. If you move outside the window and turn off the Caps Lock then return to the SunPCi window X now thinks that Caps lock is off, but the PC thinks it's still on, so the LED state no longer matches the keyboard state. In the old SunPC product we had to open /dev/kbd and use ioctl's to change the LED states, but this breaks if running remotely, or if /dev/kbd can't be opened. Date Modified: 2004-06-11 05:50:40 GMT+00:00 ------------------------------ From: [email protected] [mailto:[email protected]] On Behalf Of Fuerle, Thomas Sent: Sunday, September 04, 2011 1:14 AM To: [email protected] Subject: EXT :[SunRay-Users] weird behaviour of NumLock ... We have a weird issues with the NumLock running an uttsc kiosk on VDI 3.3 (utrelease Sun Ray Software 5.2.2) bash-3.00# utkiosk -e session KIOSK_SESSION=uttsc KIOSK_SESSION_TIMEOUT_DETACHED=12000 KIOSK_SESSION_LOCALE=de_DE KIOSK_SESSION_ARGS=-l de_DE -E wallpaper -E theming -E fontsmoothing ts2008 KIOSK_ENABLED=yes So NumLock is by default Off (would be nice if we get this as a Firmware Option some day ...). After logging in to the Terminal Server (WTS2008 R2) User klicks on the NumLock Key and start working. Users report while working the behaviour of NumLock "magically" switches to Cursor Function while the NumLock Led is still on. This happens mostly so far with Outlook or Excel. Anybody aware of such a issue ? With our current Thin Client, that are running on rdesktop 1.5, this behaviour is not reported, so it sound's like an uttsc thing. As we want to exchange around 300 devices in the next months, I'm quite worried about this thing, because their main job is to type numbers into excel. Have also created a ticket at Oracle, but I'm interested, anybody has also seen this. kind regards, thomas _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
