Android low-level Linux input subsystem to determine the system sleep state escalation key value

Android Bottom -up Linux input subsystem should not judge the system sleep state escalation key value

Off-topic: a problem study to the end, the first half of the document over there is basically useless, even wrong. At the end of the point, the front is just some hypothetical speculation.

http://blog.csdn.net/kangear/article/details/40072707

When debugging the infrared remote control input driver, the direct use of a semi-finished driver on the top of the implementation of their own device matching, but also encountered some doubts about input subsystem.

Buttons generally have "press and lift" two states are generally used 0 and 1 to indicate respectively. It is common to report key key values as follows to complete the collection of "press and lift" two states.

Input_event (Ddata->input, Ev_key, Key_power, 1);

Input_sync (Ddata->input);

But recently, a strange problem is that the key_wakeup wake-up key in the kernel uses the above method to chime, the user space can only detect state 0, the second keystroke will have a state 1 . This causes the Android system to not wake up normally and requires two times to wake the system.

The current workaround is to change the floor of the previously escalated Key_wakeup to the key_power key value. But curiosity leads me to find out what's going on with them.

Experience out of this inside reported as follows continuous escalation 1/0 state can be in user space normal detection 1/0 state.

Input_event (Ddata->input, Ev_key, Key_wakeup, 1);

Input_sync (Ddata->input);

Input_event (Ddata->input, Ev_key, Key_wakeup, 0);

Input_sync (Ddata->input);

Intuition tells me can be because I do not understand this two API , the comparison is the cause of everything.

In addition to Key_wakeup a different key value to try. As a result, as with KEY_WAKEUPG, you can infer that a non - POWER button is not possible. This can be related to where the code is located:

}else if ((Get_suspend_state ()) && (Ddata->keycode==key_power)) {

Input_event (Ddata->input, Ev_key, Key_power, 1);

Input_sync (Ddata->input);

}

Further testing in the non- pm_suspend_on power mode, all the keys are how. The test result is that all non- POWER keys have problems with the keys not syncing. However , it is not possible to use the physical keys attached to a GPIO Without this problem, so the input subsystem is excluded from being manipulated. The problem is the processing of the pair in the Remote control driver.

Find out the problem, it is in the Remote control driver, the report key value of the PM status is judged, if

static void Remotectl_timer (unsigned long _data)

if (ddata->press! = ddata->pre_press) {

ddata->pre_press = ddata->press = 0;

if (get_suspend_state () ==0) {

Input_event (Ddata->input, Ev_key, Ddata->keycode, 1);

Input_sync (Ddata->input);

Input_event (Ddata->input, Ev_key, Ddata->keycode, 0);

Input_sync (Ddata->input);

}else if ((Get_suspend_state ()) && (ddata->keycode==key_power)) {

Input_event (Ddata->input, Ev_key, Key_wakeup, 1);

Input_sync (Ddata->input);

Input_event (Ddata->input, Ev_key, Key_wakeup, 0);

Input_sync (Ddata->input);

}

}

         Remove filter conditions, and gpio The same effect as the physical keys connected, that is, regardless of the state of the system processing, hibernation or wake-up state have uploaded the key value. At the same time, this also brings me a doubt, the key driver should not be suspend Experience all the states are to be uploaded, the response is not to respond to the decision to look at the upper system, but if the normal embedded linux system is not necessarily, if the input subsystem in the system sleep when the key value is uploaded, then the corresponding application layer can be directly to respond to the key value. Which method to use, this is a paradox ! The macros that combine android

Diff--git A/drivers/input/remotectl/rkxx_remotectl.c B/drivers/input/remotectl/rkxx_remotectl.c

Index db91516: 201C5DD 100644

---a/drivers/input/remotectl/rkxx_remotectl.c

+ + B/DRIVERS/INPUT/REMOTECTL/RKXX_REMOTECTL.C

@@ -306,6 +306,10 @@ -306,6 static void remotectl_do_something (unsigned Long data)

if ((ddata->scandata&0x0ff) = = ((~ddata->scandata >> 8) &0x0ff) {

if (Remotectl_keycode_lookup (Ddata)) {

ddata->press = 1;

+ #ifdef config_android//ANDROID OS needs input event whatever suspend state

+ input_event (ddata->input, Ev_key, Ddata->keycode, 1);

+ Input_sync (ddata->input);

+ #else

if (Ddata->keycode==key_power | | get_suspend_state () ==pm_suspend_on) {

Input_event (Ddata->input, Ev_key, Ddata->keycode, 1);

Input_sync (Ddata->input);

@@ -314,6 +318,7 @@ -314,6 void remotectl_do_something (unsigned Long data)

}

Input_event (Ddata->input, Ev_key, Ddata->keycode, ddata->press);

Input_sync (Ddata->input);

+ #endif//config_android

Ddata->state = rmc_sequence;

}else{

Ddata->state = Rmc_preload;

@@ -437,6 +442,10 @@ -437,6 void Remotectl_timer (unsigned long _data)

if (ddata->press! = ddata->pre_press) {

ddata->pre_press = ddata->press = 0;

+ #ifdef config_android//ANDROID OS needs input event whatever suspend state

+ input_event (ddata->input, Ev_key, Ddata->keycode, 0);

+ Input_sync (ddata->input);

+ #else

if (Get_suspend_state () ==0) {

Input_event (Ddata->input, Ev_key, Ddata->keycode, 1);

Input_sync (Ddata->input);

@@ -448,6 +457,7 @@ -448,6 void Remotectl_timer (unsigned long _data)

Input_event (Ddata->input, Ev_key, Key_wakeup, 0);

Input_sync (Ddata->input);

}

+ #endif//config_android

}

#ifdef CONFIG_PM

Remotectl_wakeup (_data);

In the case of an Android system, the key values are escalated in real time regardless of the sleep state that kernel handles. This ensures that the audio size can be controlled when the music is played in hibernation. This is the way Android phones are now implemented .

http://blog.csdn.net/kangear/article/details/40072707

Another point: the button in the shape 0, not Input_sync (ddata->input); emitted, it only emits the current value. It's just a "sync," meaning that the data is ready to be sent. There is still no clear understanding of the drive plus some of their own blind imagination misled themselves. The kernel input driver is not distinguished by the POWER key,WAKEUP key; There is a difference, the problem must be in their own driver code.

Android low-level Linux input subsystem to determine the system sleep state escalation key value