akbd.c:akbd_capslockwrapper() kills remapping of capslock

[Matthias Kilian]

Hi,

last weekend, I noticed that after a

$ wsconsctl keyboard.map+=keysym Caps_Lock = Control_L

on my PowerBook G4 the capslock key did *not* any longer behave
like a control key. Instead it just has *no* effect at all, which
isn't very surprising when looking at akbd_capslockwrapper() in
akbd.c.

Isn't there any reliable way to detect *what* kind of keyboard is
in use and then decide wether the hack in akbd_capslockwrapper()
is necessary or not?

Ciao,
Kili

dmesg:
[ using 339044 bytes of bsd ELF symbol table ]
console out [ATY,Jasper_A]console in [keyboard] USB and ADB found, using USB
using parent ATY,JasperParent:: memaddr b800 size 800, : consaddr 
b8008000, : ioaddr b002, size 2: memtag 8000, iotag 8000: width 1280 
linebytes 1280 height 854 depth 8
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 3.9-current (GENERIC) #139: Fri Mar 10 22:32:10 CET 2006
[EMAIL PROTECTED]:/var/compile/GENERIC
real mem = 1073741824 (1048576K)
avail mem = 978173952 (955248K)
using 1254 buffers containing 53686272 bytes (52428K) of memory
mainbus0 (root): model PowerBook5,4
cpu0 at mainbus0: 7447A (Revision 0x101): 1333 MHz: 512KB L2 cache
memc0 at mainbus0: uni-n
hw-clock at memc0 not configured
ki2c0 at memc0 offset 0xf8001000
iic0 at ki2c0
adt0 at iic0 addr 0xae: adt7460 (ADT7460) rev 62
lmu-controller at iic0 addr 0x42 not configured
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 Apple UniNorth AGP rev 0x00
vgafb0 at pci0 dev 16 function 0 ATI Radeon Mobility M10 NP rev 0x00, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 Apple UniNorth PCI rev 0x00
Broadcom BCM4306 rev 0x03 at pci1 dev 18 function 0 not configured
cbb0 at pci1 dev 19 function 0 Texas Instruments PCI1510 CardBus rev 0x00: 
irq 53
macobio0 at pci1 dev 23 function 0 Apple Intrepid rev 0x00
openpic0 at macobio0 offset 0x4: version 0x4614
macgpio0 at macobio0 offset 0x50
modem-reset at macgpio0 offset 0x1d not configured
modem-power at macgpio0 offset 0x1c not configured
macgpio1 at macgpio0 offset 0x9 irq 47
programmer-switch at macgpio0 offset 0x11 not configured
cpu-vcore-select at macgpio0 offset 0x6b not configured
gpio4 at macgpio0 offset 0x1e not configured
gpio5 at macgpio0 offset 0x6f not configured
gpio6 at macgpio0 offset 0x70 not configured
extint-gpio4 at macgpio0 offset 0x5c not configured
gpio11 at macgpio0 offset 0x75 not configured
extint-gpio15 at macgpio0 offset 0x67 not configured
escc-legacy at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
aoa0 at macobio0 offset 0x1: irq 30,1,2
audio0 at aoa0
timer at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 3 targets
akbd0 at adb0 addr 2: iBook keyboard with inverted T (ISO layout)
wskbd0 at akbd0 mux 1
wskbd0: connecting to wsdisplay0
ams0 at adb0 addr 3: EMP trackpad tpad 4-button, 400 dpi
wsmouse0 at ams0 mux 0
abtn0 at adb0 addr 7: brightness/volume/eject buttons
apm0 at adb0: battery flags 0x5, 99% charged
pi2c0 at adb0
iic1 at pi2c0
battery at macobio0 offset 0x0 not configured
backlight at macobio0 offset 0xf300 not configured
ki2c1 at macobio0 offset 0x18000
iic2 at ki2c1
wdc0 at macobio0 offset 0x2 irq 24: DMA
atapiscsi0 at wdc0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: MATSHITA, CD-RW CW-8123, CA0T SCSI0 5/cdrom 
removable
cd0(wdc0:0:0): using BIOS timings, DMA mode 2
ohci0 at pci1 dev 24 function 0 Apple Intrepid USB rev 0x00: irq 0, version 
1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci1 dev 25 function 0 Apple Intrepid USB rev 0x00: irq 0, version 
1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ohci2 at pci1 dev 26 function 0 Apple Intrepid USB rev 0x00: irq 29, version 
1.0, legacy support
usb2 at ohci2: USB revision 1.0
uhub2 at usb2
uhub2: Apple OHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ohci3 at pci1 dev 27 function 0 NEC USB rev 0x43: irq 63, version 1.0
usb3 at ohci3: USB revision 1.0
uhub3 at usb3
uhub3: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub3: 3 ports with 3 removable, self powered
ohci4 at pci1 dev 27 function 1 NEC USB rev 0x43: irq 63, version 1.0
usb4 at ohci4: USB revision 1.0
uhub4 at usb4
uhub4: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub4: 2 ports with 2 removable, self powered
ehci0 at pci1 dev 27 function 2 NEC USB rev 0x04: irq 63

Re: akbd.c:akbd_capslockwrapper() kills remapping of capslock

[Miod Vallat]

 Hi,
 
 last weekend, I noticed that after a
 
 $ wsconsctl keyboard.map+=keysym Caps_Lock = Control_L
 
 on my PowerBook G4 the capslock key did *not* any longer behave
 like a control key. Instead it just has *no* effect at all, which
 isn't very surprising when looking at akbd_capslockwrapper() in
 akbd.c.
 
 Isn't there any reliable way to detect *what* kind of keyboard is
 in use and then decide wether the hack in akbd_capslockwrapper()
 is necessary or not?

No. But what about this diff?

Miod

Index: akbd.c
===
RCS file: /cvs/src/sys/dev/adb/akbd.c,v
retrieving revision 1.4
diff -u -p -r1.4 akbd.c
--- akbd.c  2006/02/12 21:49:08 1.4
+++ akbd.c  2006/03/11 13:23:07
@@ -128,6 +128,7 @@ akbdattach(struct device *parent, struct
sc-handler_id = aa_args-handler_id;
 
sc-sc_leds = (u_int8_t)0x00;   /* initially off */
+   sc-sc_caps = 0;
 
adbinfo.siServiceRtPtr = (Ptr)akbd_adbcomplete;
adbinfo.siDataAreaAddr = (caddr_t)sc;
@@ -453,6 +454,30 @@ akbd_rawrepeat(void *v)
 #endif
 
 /*
+ * The ``caps lock'' key is special: since on earlier keyboards, the physical
+ * key stays down when pressed, we will get a notification of the key press,
+ * but not of the key release. Then, when it is pressed again, we will not get
+ * a notification of the key press, but will see the key release.
+ *
+ * This is not exactly true. We see the missing release and press events both
+ * as the release of the power (reset) key.
+ *
+ * To avoid confusing them with real power key presses, we maintain two
+ * states for the caps lock key: logically down (from wscons' point of view),
+ * and ``physically'' down (from the adb messages point of view), to ignore
+ * the power key. But since one may press the power key while the caps lock
+ * is held down, we also have to remember the state of the power key... this
+ * is quite messy.
+ */
+
+/*
+ * Values for caps lock state machine
+ */
+#defineCL_DOWN_ADB 0x01
+#defineCL_DOWN_LOGICAL 0x02
+#defineCL_DOWN_RESET   0x04
+
+/*
  * Given a keyboard ADB event, decode the keycodes and pass them to wskbd.
  */
 void
@@ -468,10 +493,24 @@ akbd_processevent(struct akbd_softc *sc,
 * 0x on release, and we ignore it.
 */
if (event-bytes[0] == event-bytes[1] 
-   ADBK_KEYVAL(event-bytes[0]) == ADBK_RESET)
-   break;
-   akbd_capslockwrapper(sc, event-bytes[0]);
-   akbd_capslockwrapper(sc, event-bytes[1]);
+   ADBK_KEYVAL(event-bytes[0]) == ADBK_RESET) {
+   if (event-bytes[0] == ADBK_KEYDOWN(ADBK_RESET))
+   SET(sc-sc_caps, CL_DOWN_RESET);
+   else {
+   if (ISSET(sc-sc_caps, CL_DOWN_RESET))
+   CLR(sc-sc_caps, CL_DOWN_RESET);
+   else if (ISSET(sc-sc_caps, CL_DOWN_ADB)) {
+   akbd_input(sc, ISSET(sc-sc_caps,
+   CL_DOWN_LOGICAL) ?
+ ADBK_KEYDOWN(ADBK_CAPSLOCK) :
+ ADBK_KEYUP(ADBK_CAPSLOCK));
+   sc-sc_caps ^= CL_DOWN_LOGICAL;
+   }
+   }
+   } else {
+   akbd_capslockwrapper(sc, event-bytes[0]);
+   akbd_capslockwrapper(sc, event-bytes[1]);
+   }
break;
default:
 #ifdef DIAGNOSTIC
@@ -486,22 +525,11 @@ akbd_processevent(struct akbd_softc *sc,
 void
 akbd_capslockwrapper(struct akbd_softc *sc, int key)
 {
-   /*
-* Caps lock is special: since on earlier keyboards, the physical
-* key stays down when pressed, we will get a notification of the
-* key press, but not of the key release. Then, when it is pressed
-* again, we will not get a notification of the key press, but will
-* see the key release.
-* For proper wskbd operation, we should report each capslock
-* notification as both events (press and release).
-*/
-   if (ADBK_KEYVAL(key) == ADBK_CAPSLOCK) {
-   akbd_input(sc, ADBK_KEYDOWN(ADBK_CAPSLOCK));
-   akbd_input(sc, ADBK_KEYUP(ADBK_CAPSLOCK));
-   } else {
-   if (key != 0xff)
-   akbd_input(sc, key);
-   }
+   if (ADBK_KEYVAL(key) == ADBK_CAPSLOCK)
+   sc-sc_caps ^= CL_DOWN_ADB;
+
+   if (key != 0xff)
+   akbd_input(sc, key);
 }
 
 int adb_polledkey;
Index: akbdvar.h
===
RCS file: /cvs/src/sys/dev/adb/akbdvar.h,v
retrieving revision 1.1
diff -u -p -r1.1 akbdvar.h
--- akbdvar.h   2006/01/18 23:21:17 1.1

Re: akbd.c:akbd_capslockwrapper() kills remapping of capslock

[Matthias Kilian]

On Sat, Mar 11, 2006 at 01:26:25PM +, Miod Vallat wrote:
  Isn't there any reliable way to detect *what* kind of keyboard is
  in use and then decide wether the hack in akbd_capslockwrapper()
  is necessary or not?
 
 No. But what about this diff?

As you note, quite messy, but it works for me. However, I didn't test
the behaviour of the reset key wrt status of caps lock.

Ciao,
Kili