OpenSolaris

Printable Version Enter a New Search
Bug ID 6373433
Synopsis 4491526 breaks keymapping for control-shift-f1 and -f2 on SPARC systems
State 10-Fix Delivered (Fix available in build)
Category:Subcategory xserver:input_devices
Keywords 108652 | function | keys
Responsible Engineer Alan Coopersmith
Reported Against
Duplicate Of
Introduced In solaris_8
Commit to Fix s8_patch
Fixed In s8_patch
Release Fixed solaris_8(s8_patch) , solaris_nevada(snv_38) (Bug ID:2136306) solaris_10u3(s10u3_01) (Bug ID:2136307,) solaris_9(s9patch) (Bug ID:2136308,)
Related Bugs 4491526
Submit Date 17-January-2006
Last Update Date 16-January-2007
Description
In our application using Sun Blade 2500 and operating system SunOS 5.8, the X-Window System (openwin) shows a problem in passing key events to the application. It applies to:
 
        * <control><shift>F1
        * <control><shift>F2
        * <control>F11
        * <control>F12
        * and several other modifier/function key combinations.
 
To reproduce it, make sure that patch 108652 is at a revision higher then 76. A simple scenario is to use a xterm, and check the echoed codes when pressing these keys. For example: check the echoed codes when pressing (while keeping <control><shift> pressed): F5 F4 F3 F2 F1. You will notice the completely different echos for F2 and F1. On machines that work correctly, the codes returned are in a nice sequence.
 
It is also reproducable using a blade-2500, with a clean Solaris 8 installation.
Use CDE, and start the Hotkey editor. When adding <control> <shift> F1,
<control> <shift> F2 hotkeys, you will notice the different behaviour
comparedto <control> <shift> F3 etcetera.
 
On Ultra-60 machines the <control> <shift> F1 and <control> <shift> F2 problems do not occur.
 
To analyse this problem, we investigated the input to the X-server
(using truss), and saw that the codes read by /dev/keyboard when
pressing the F1 and F2 keys are the same, irrespective of pressing the
<control> and <shift> keys (so the input to the X-server seems correct,
while the output from the X-server is incorrect).
 
When analysing this behaviour, we saw that the problem occured in an
operational environment using a window manager and some xterm windows on
one machine (sunc1374 108652-89), but did not occur with the same operational
environment on another (sunc1450 108652-47). Both machines are blade-100's,
the problem seems dependent on patch level. 

I tested this here at Sun on S8 05/03 with patch 108652-66 the problem did not occur.
I then patched to 108652-76 and was able to reproduce the problem. This is with no modification to the keyboard maps.
Work Around
back out patch 108652-67 or higher.
Comments
N/A