Ticket #358 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

Board cursor switches should be separate from keyboard arrow keys

Reported by: cjb Owned by: jg
Priority: blocker Milestone: Trial-2
Component: keyboards Version:
Keywords: Cc:
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

  Changed 8 years ago by 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.

  Changed 8 years ago by ray.tseng@…

Anyone will define these eight scancodes? then Quanta follows

  Changed 8 years ago by 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

  Changed 8 years ago by ray.tseng@…

  • owner changed from ray.tseng@… to ted.juan

in reply to: ↑ description ; follow-up: ↓ 6   Changed 8 years ago by 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

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 8 years ago by ted.juan

Quanta will add the feature in next EC verison soon.

in reply to: ↑ 6   Changed 8 years ago by ted.juan

EC PQ2A71 fixed the problem.

  Changed 8 years ago by jg

  • owner changed from ted.juan to rsmith
  • priority changed from normal to high

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.

  Changed 7 years ago by jg

  • milestone changed from BTest-2 to BTest-3

  Changed 7 years ago by warp

  • component changed from hardware to keyboards

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...

  Changed 7 years ago by rsmith

  • owner changed from rsmith to jg
  • verified unset

Hardware works. This is now a kernel/X thing

  Changed 7 years ago by jg

  • priority changed from high to blocker

I think this has been fixed; will verify Monday.

  Changed 7 years ago by warp

  • status changed from new to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.