Author Topic: 122-Key keyboard  (Read 1471 times)

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 28
  • Posts: 253
    • View Profile
Re: 122-Key keyboard
« Reply #30 on: October 09, 2018, 01:31:29 pm »
Hi Lars,

Any chance you could send me the modified USBKBD.SYS so I can test it with my USB keyboards with extra keys?

ivan10 at free dot fr

Thanks
If I can get anything to work at all, I am also going to send it to you.

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 27
  • Posts: 818
    • View Profile
Re: 122-Key keyboard
« Reply #31 on: October 09, 2018, 10:41:16 pm »
Thanks Lars,

Would the output from LSUSB of the various keyboards be helpful?

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 28
  • Posts: 253
    • View Profile
Re: 122-Key keyboard
« Reply #32 on: October 09, 2018, 11:44:57 pm »
Thanks Lars,

Would the output from LSUSB of the various keyboards be helpful?

That won't be necessary yet (you did already attach lsusb Output for one of your PS/2 to USB Adapters, that's a starting point). The LSUSB Output only Shows the report descriptor which is the structural description of the received data packet(s) but not more.
First I need to find out if the keypresses reach USBKBD.SYS (that is, USBKBD.SYS receives a report with the USB keycode of the key on the keyboard). Then I need to find out if the mapping from USB keycode to PS/2 scancode(s) is done correctly. What happens underneath is that USBKBD.SYS calls the legacy mouse driver (amouse.sys, mouse.sys) with the PS/2 scancodes for "make" (key press) and "break" (key release) for the key. Not all USB keycodes have a defined mapping to PS/2 scancode so let's see where this Ends up ...

Andreas Schnellbacher

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 16
  • Posts: 330
    • View Profile
Re: 122-Key keyboard
« Reply #33 on: October 10, 2018, 12:21:27 am »
Hi Lars,

one comment to your last post:

Scan codes are hardware-specific. Via scan code defined keys require user action (and a tool that is prepared for scan code configuration) to work. Of more interest would be char codes, if they exist at all for the to-be-added key definitions.

Checking for scan codes might be a good start. (I hope that I haven't written something that you already know.)

Lars

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 28
  • Posts: 253
    • View Profile
Re: 122-Key keyboard
« Reply #34 on: October 10, 2018, 07:25:36 am »
That's not how it works. The only thing that USBKBD.SYS does it to transform a USB keycode (that's just a number for a key on the keyboard) to the corresponding "make" and "break" scancodes as defined by some Microsoft table and then send this sequence of scancodes to the legacy mouse driver (AMOUSE.SYS, MOUSE.SYS) which in turn send that to IBMKBD.SYS (I think, I would need to check the code).

It is the job of upper layers to map these scancodes to a keycode (for example by using the KEYBOARD.DCP table).

And that might also be the problem. It is possible that the legacy mouse driver and/or IBMKBD.SYS do not know what to do with the scancodes or the KEYBOARD.DCP table contains no entry for these scancodes.

Fortunately, for PM virtual keys VK_F13 to VK_F24 are defined which gives me some hope that the OS/2 keyboard subsystem at least knows that these keys exist on some keyboards.