About the keyboard devices in inputdriver in directfb

Source: Internet
Author: User
Tags 04x

I am trying to add my own keyboard device. It took almost two weeks to read the keyboard. C and/src/CORE/input. c: the head of the two files is too big. I found that directfb's keyboard device is for the standard keyboard. It seems that there is no additional interface for the custom keyboard, in addition, the key value acquisition, translation, transmission process and its complexity are quite confusing. I am asking some questions here. Can anyone who has read the source code of the directfb keyboard device give me some advice? In keyboard. C, it seems that both methods have obtained the keyboard value of the standard keyboard (instead of the scan value, mediumraw is used ).
Mode). One is to create a keyboardeventthread thread in driver_open_device, and then use the system call read () in the keyboardeventthread to read the key value from the device driver, the other is to obtain the key value by using IOCTL () called by the system in keyboard_read_value () of the driver_get_keymap_entry module, then, convert the value to a dfbinputdevicekeysymbol by using other functions... And so on...
Let's look back at the key value obtained through the read () method by calling dfb_input_dispatch -- fixup_key_event, and then calling the fixup_key_event function based on different situations.
Lookup_from_table ()
Find_key_code_by_id ()
Find_key_code_by_symbol ()
Id_to_symbol ()
Symbol_to_id ()
To get the corresponding new key value. What makes my head big is what is the relationship between key_code, key_id, and key_symbol In the event struct, there is an actual keyboard value corresponding to a key value that can be recognized by directfb. Why do we need key_id and key_symbol? What is the purpose of this complicated round-trip conversion? What is the difference and connection between the key value passed through read () and the new value obtained after conversion and the key value obtained through IOCTL? I want to add my own keyboard instead of the standard keyboard. Where should I start ??

Zhyuzhyu1985Published on

As described in the Code, key_id is the abstraction of the upper layer and has nothing to do with hardware. key_symbol is related to hardware. If you want to use your own keyboard, you can use key_symbol to read all the key values of your keyboard and then convert them to key_symbol, same principle as remote control. Its keyboard. C is used to implement the standard keyboard. Add a keyborad1.c file.

Tiansun7kPublished on

Thanks for the LS solution. I analyzed the source code carefully today. Could you give me some details:
1. If I re-write a keyboard. c myself, should the format be the same as that of the original keyboard. C, including implementation details? Do I still need the following macros and functions?
Dfb_input_driver (this macro is required, and its implementation is in input_driver.h)
Keyboard_get_symbol ()
Keyboard_get_identifier ()
Keyboard_read_value ()
Keyboard_set_lights ()
Keyboardeventthread ()
Driver_get_available ()
Driver_get_info ()
Driver_open_device ()
Driver_get_keymap_entry ()
Driver_close_device ()
2. keyboard. C is not isolated. Many of its functions are similar to the input in/src/core. c. If you re-write a keyboard. c must also have input. where the functions in C are related, input. c Not Required
Do you want to change it?

3. My own keyboard driver has been running in the kernel, and I have written a test program. On the terminal, I can directly capture the key value through the read method, in fact, I only need five keys to use (top, bottom, left, right, OK). I am on my own keyboard. in C, you must also use read to obtain the key value, and IOCTL is useless (I didn't implement the ioctl method in my own keyboard driver), and I am in my own keyboard. c, such
Driver_open_device (), IOCTL (dfb_fbdev-> VT-> FD, kdskbmode, k_mediumraw), IOCTL (data-> VT-> FD, kdgkbent, & entry) in keyboard_read_value) do you want to write more?

4 is the standard keyboard value obtained in the original keyboard. c obtained through read? Or through IOCTL? I have read the code: IOCTL (data-> VT-> FD, kdgkbent, & entry) does not seem to have a simple keyboard code, because the keyboard value is passed to the entry struct variable, but the entry has many Members: kb_table, kb_index, and kb_value. It can be determined that this kb_value must be a key value, but what is the use of table and index? If the passed key value is a byte, how does it fit in kb_value?

5. I personally think that the key value is obtained through the read in keyboardeventthread (), because the relevant code after reading can be clearly seen:

For (I = 0; I <readlen; I ++ ){
Dfbinputevent EVT; // defines an input event

EVT. type = (BUF [I] & 0x80 )? Diet_keyrelease: diet_keypress); // the maximum value of the standard keyboard key value (mediumraw mode) is 0 or 1 to distinguish the press and release keys.
EVT. Flags = dief_keycode; // indicates the key value, not the keyid or keysymbol.
EVT. key_code = Buf [I] & 0x7f; // The highest bit blocked. The standard keyboard value key_code is the minimum value of 7 characters.

Dfb_input_dispatch (data-> device, & EVT); // pass the key value and other information to dfb_input_dispatch () in the input. c file through the EVT pointer.
Keyboard_set_lights (data, EVT. Locks );
}
In dfb_input_dispatch (), the switch (Event-> type) is used to determine whether it is diet_keyrelease: diet_keypress. Then, the Caps Lock key of the standard keyboard is processed and fixup_key_event () is called directly (), in this function, the source code comments are divided into many items:/* Add missing flags */and/* use cached values for modifiers/locks if they are missing. * //,/*
Translation table */,/* without translation table */. ,/* update cached values for modifiers. */....... after reading these parts for a long time, I haven't figured out how to process the corresponding ID, symnol, and code, especially the modifiers. I don't know what it means, in the dfbinputevent struct, The key_id and key_symbol are interpreted as follows:
Key_id;/* Basic mapping, modifier independent */
Key_symbol;/* Advanced mapping, Unicode compatible, modifier dependent */

Is this modifier The "hardware" you said? According to the above explanation, key_id does not depend on modifier, while key_symbol depends on modifier.
I personally feel that if I want to use a custom keyboard, fixup_key_event () in the input. c file will also be greatly changed.

6. As you said in the reply, "you can use key_symbol to read all the key values of your keyboard and convert them to key_symbol. Then you can use it directly, the same principle as the remote control "is implemented on the keyboard. c implementation? How can I directly convert my own key value (assuming that the hexadecimal key value of the "confirm key" passed by the driver is 41 h) to key_symbol, can you write a short piece of code for example? Key_symbol seems to be defined by directfb. Each value corresponds to a symbol (I am not very clear). If you have added a custom keyboard, can you write your own keyboard. C and in the input. the changes made in C are sent to me for reference?

Thank you very much !!!!!!!!!!!!!

Sword_lzrPosted on

I have implemented it. Please refer to my changes.

Input. c
Void
Dfb_input_dispatch (coreinputdevice * device, dfbinputevent * event)
{
D_debug_at (core_input, "% s (% P, % P) \ n", _ FUNCTION __, device, event );

D_magic_assert (device, coreinputdevice );

D_assert (core_input! = NULL );
D_assert (device! = NULL );
D_assert (event! = NULL );

D_assume (device-> shared! = NULL );

/*
* 0. sanity checks & debugging...
*/
If (! Device-> shared ){
D_debug_at (core_input, "-> no shared data! \ N ");
Return;
}

D_assume (device-> shared-> reactor! = NULL );

If (! Device-> shared-> Reactor ){
D_debug_at (core_input, "-> No reactor! \ N ");
Return;
}

D_debug_at (core_inputevt, "-> (% 02x) % S % s \ n", event-> type,
Dfb_input_event_type_name (Event-> type ),
(Event-> flags & dief_follow )? "[Follow]": "",
(Event-> flags & dief_repeat )? "[Repeat]": "");

# If d_debug_enabled
If (Event-> flags & dief_timestamp)
D_debug_at (core_inputevt, "-> timestamp % lu. % 06lu \ n", event-> timestamp. TV _sec, event-> timestamp. TV _usec );
If (Event-> flags & dief_axisabs)
D_debug_at (core_inputevt, "-> axisabs % d at % d \ n", event-> AXIS, event-> axisabs );
If (Event-> flags & dief_axisrel)
D_debug_at (core_inputevt, "-> axisrel % d by % d \ n", event-> AXIS, event-> axisrel );
If (Event-> flags & dief_keycode)
D_debug_at (core_inputevt, "-> keycode % d \ n", event-> key_code );
If (Event-> flags & dief_keyid)
D_debug_at (core_inputevt, "-> keyid 0x % 04x \ n", event-> key_id );
If (Event-> flags & dief_keysymbol)
D_debug_at (core_inputevt, "-> keysymbol 0x % 04x \ n", event-> key_symbol );
If (Event-> flags & dief_modifiers)
D_debug_at (core_inputevt, "-> modifiers 0x % 04x \ n", event-> modifiers );
If (Event-> flags & dief_locks)
D_debug_at (core_inputevt, "-> locks 0x % 04x \ n", event-> locks );
If (Event-> flags & dief_buttons)
D_debug_at (core_inputevt, "-> buttons 0x % 04x \ n", event-> buttons );
If (Event-> flags & dief_global)
D_debug_at (core_inputevt, "-> Global \ n ");
# Endif

/*
* 1. fixup event...
*/
Event-> clazz = dfec_input;
Event-> device_id = device-> shared-> ID;

If (! (Event-> flags & dief_timestamp )){
Gettimeofday (& event-> timestamp, null );
Event-> flags | = dief_timestamp;
}

Switch (Event-> type ){
Case diet_buttonpress:
Case diet_buttonrelease:
D_debug_at (core_inputevt, "-> button 0x % 04x \ n", event-> button );

If (dfb_config-> lefty ){
If (Event-> button = dibi_left)
Event-> button = dibi_right;
Else if (Event-> button = dibi_right)
Event-> button = dibi_left;

D_debug_at (core_inputevt, "-> Lefty! => 0x % 04x <= \ n ", event-> button );
}
/* Fallthru */

Case diet_axismotion:
Fixup_mouse_event (device, event );
Break;

Case diet_keypress:
Case diet_keyrelease:
# If 0
If (dfb_config-> capslock_meta ){
If (device-> shared-> keymap. num_entries & (Event-> flags & dief_keycode ))
Lookup_from_table (device, event, (dief_keyid |
Dief_keysymbol )&~ Event-> flags );

If (Event-> key_id = diki_caps_lock | event-> key_symbol = diks_caps_lock ){
Event-> flags | = dief_keyid | dief_keysymbol;
Event-> key_code =-1;
Event-> key_id = diki_meta_l;
Event-> key_symbol = diks_meta;
}
}

Fixup_key_event (device, event );
# Endif
Printf ("Event-> key_code = % d \ n", event-> key_code );
Switch (Event-> key_code ){
Case 1:
Event-> key_symbol = diks_1;
Event-> key_id = diki_a;
Break;
Case 2:
Event-> key_symbol = diks_2;
Event-> key_id = diki_ B;
Break;
Case 3:
Event-> key_symbol = diks_3;
Event-> key_id = diki_c;
Break;
Case 4:
Event-> key_symbol = diks_4;
Event-> key_id = diki_d;
Break;
Case 5:
Event-> key_symbol = diks_5;
Event-> key_id = diki_e;
Break;
Case 6:
Event-> key_symbol = diks_6;
Event-> key_id = diki_f;
Break;


}
Break;

Default:
;
}

# If d_debug_enabled
If (Event-> flags & dief_timestamp)
D_debug_at (core_inputevt, "=> timestamp % lu. % 06lu \ n", event-> timestamp. TV _sec, event-> timestamp. TV _usec );
If (Event-> flags & dief_axisabs)
D_debug_at (core_inputevt, "=> axisabs % d at % d \ n", event-> AXIS, event-> axisabs );
If (Event-> flags & dief_axisrel)
D_debug_at (core_inputevt, "=> axisrel % d by % d \ n", event-> AXIS, event-> axisrel );
If (Event-> flags & dief_keycode)
D_debug_at (core_inputevt, "=> keycode % d \ n", event-> key_code );
If (Event-> flags & dief_keyid)
D_debug_at (core_inputevt, "=> keyid 0x % 04x \ n", event-> key_id );
If (Event-> flags & dief_keysymbol)
D_debug_at (core_inputevt, "=> keysymbol 0x % 04x \ n", event-> key_symbol );
If (Event-> flags & dief_modifiers)
D_debug_at (core_inputevt, "=> modifiers 0x % 04x \ n", event-> modifiers );
If (Event-> flags & dief_locks)
D_debug_at (core_inputevt, "=> locks 0x % 04x \ n", event-> locks );
If (Event-> flags & dief_buttons)
D_debug_at (core_inputevt, "=> buttons 0x % 04x \ n", event-> buttons );
If (Event-> flags & dief_global)
D_debug_at (core_inputevt, "=> Global \ n ");
# Endif

If (core_input_filter (device, event ))
{
Printf ("*****> filtered \ n ");
}
Else
{
Printf ("fusion_reactor_dispatch () \ n ");
Fusion_reactor_dispatch (device-> shared-> reactor, event, true, dfb_input_globals );

}
}

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.