Board cursor switches should be separate from keyboard arrow keys

[cjb]

Hi Ray,

The cursor switches on the board (SW3-SW10) generate the same keycodes as the arrow keys on the keyboard, so we cannot distinguish between the switches on the board and the switches on the keyboard; we'd like to be able to.

This is not important for B-Test-1.

[jg]

To keep the terminology right, scancodes, not keycodes.

Keycodes are what X reports to clients, and may or may not bear any resemblance to scan codes.

[ray.tseng@…]

Anyone will define these eight scancodes? then Quanta follows

[mfoster]

Hi, Ray,

I defined the 9 scancodes for the 9 keys today, and Ted modified the EC code, but two problems showed up. First, the EC keycode scanning is very broken, presenting "ghost" keycodes when just two of the (proper) keys are held down simultaneously. Second, we have a hardware problem where there are no anti-ghosting diodes on the game button keys, which is quite important for a game controller. Let us focus this Trac on getting the EC key scanning logic fixed, and I'll open another Trac tomorrow to add the anti-ghosting diodes to the game keys.

Best Regards, MarkF

[ted.juan]

Hi Mark, Please help to define the gamepad key which combination should have the function. That we can re-design the key matrix and avoid the ghost key.

Best regards, Ted

[ted.juan]

Quanta will add the feature in next EC verison soon.

[ted.juan]

EC PQ2A71 fixed the problem.

[jg]

Richard, please test this and close this one out if it done; on second thought, we better leave this open until we verify on the BTest-2 hardware as well.

[warp]

I'm not sure who should have this now, but the hardware has been working properly for a while now.

Currently setolpckeys.c maps both sets of board cursor keys to the number pad keys, however that is solely due to a lack of imagination in picking HID symbols to map them to.

Ideally, they should be mapped to symbols that make sense for them, are not on the keyboard at the moment, and the left and right ones should be mapped to different symbols.

The only thing stopping this from working with current firmware on both B1 and B2 is needing to come up with the symbols, so...

[rsmith]

Hardware works. This is now a kernel/X thing

[jg]

I think this has been fixed; will verify Monday.

[warp]

Yes, this is fixed.

One set is KP8/2/4/6. (up, down, left, right)

The other set is KP9/3/7/1. (pgup, pgdn, home, end)

The keyboard never generates these, so at most some X apps might either not notice the difference, or we might want to make some X keysyms for that.

In either case, that's both a different bug and a Trial-3 thing.