This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: The processing of Input from USB keyboard on Linux

Part Number: AM5728

Tool/software: Linux

Hi,


My customer uses AM5728 with WEC7 OS at present. And they are planning to use new Sitara processor with Linux OS in next generation system.


So customer does not have any experiences for Linux.


Customer have special keyboard for own system. So customer would like to make USB keyboad driver of Linux. So they would like to know the processing of the input from USB keyboard.


The below is the processing of input from USB keyboard in Windows.


1) The input information from keyboard is received temporary by Windows OS.


2) Windows OS judges that the recieved data should be sent to which application. And the message structure is made from the recieved data, the MSG structure is stored in message queue of each application.

3) In each application, the processing called "message roop"  is running.

4) "message roop" retrieves MSG structure one by one from own message queue. And analyze the data, then call event handler.  Also "message roop" generate character code for pushed key.

Note:

Message --- the information included in "scan code", "virtual key code", and "key stroke".

I attached a picture for this explanation. Please see it.

How about Linux OS? Does Linux execute same processing as Windows OS?

Please advise me.

I appreicate your quick reply.

Best regards,

Michi

  • That description ignores all the processing done by the Windows drivers.

    Anyway, what is special about that keyboard? Does it not use the USB HID protocol? Does it use strange key codes?
  • Dear Clemens-san,

    Thank you for your quick reply.

    Customer's new keyboard has special keys that does not have in general USB keyboard. Special keys are assigned to "Usage ID".
    "Usage ID" is not used in general USB keyboard. (Please refer to " www.usb.org/.../Hut1_12v2.pdf " for Usage ID.)

    Also customer uses USB HID protocol.

    BTW, you said "That description ignores all the processing done by the Windows driver.". What do you mean about this?
    Does this mean Linux USB HID driver can use customer's special keyboard without problem?
    Please let me know.

    I appreciate your quick reply.

    Best regards,
    Michi
  • In Windows, the kbdhid.sys driver handles the HID protocol, and kbdclass.sys then handles all keyboard events and generates the messages to be sent to applications.

    If Windows already sends messages for the custom keys, then it's likely that Linux does the same without a separate driver.

    Connect the keyboard to some Linux PC. Check that it shows up in /dev/input/by-id/. Run the evtest tool on that input device to check whether you get events for the custom keys.
  • Dear Clemens-san,

    Thank you for your continous support.

    I tested to connect generic usb keyboard to Ubuntu14.04 on VMWare under Windows7 PC. But I can't see it anything in /dev/input/by-id/.

    BTW, I don't understand you said "If Windows already sends messages for the custom keys, then it's likely that Linux does the same without a separate driver.".
    In Linux OS, are there kbdhid.sys and kbdclass.sys driver same as windows OS. And do those Linux's keyboard driver send only generic keys to application?

    I am not familiar with USB familiar. Please advise me.

    I appreciate your continuous support.

    Best regards,
    Michi
  • The linux kernel will not see the keyboard as a USB device unless you tell VMWare to pass through that device to the VM. Did you do that?

    In Linux, the equivalent drivers would be usbhid.ko, hid-core.ko, and input-core.ko.

    As far as I know, the HID and input driver should provide all key codes for the application. However, your application would typically use libraries like Qt or GTK+ on top of that, and I do not know how those behave.

    Anyway, the first step is to check if you get the /dev/input input device, and if you can see the events for the custom keys.