HallMonitor icon indicating copy to clipboard operation
HallMonitor copied to clipboard

Published 20 hours ago • verified publisher icon durka

S4 Mini issues

Open VolMi opened this issue 11 years ago • 83 comments

This could serve as a thread for issues that are specific for the S4 Mini for which an S-View Cover exists, as well. AFAIK, there are at least three different versions of this device (LTE/3G/Dual SIM).

I have the LTE version which is officially known as the GT-I9195 and on Cyanogenmod as serranoltexx. I started with CM10.2, but now I am on the CM11 nightlies.

It turns out that HallMonitor is really useful on the Mini, too. However, the on and off trigger seems to be firing less reliable than on the big S4. The apk in the master branch is mostly unfunctional, but @Wallace0 has refined the detection so that the hit rate is much better now. Currently I use the apk in the merge branch.

To come up with some real numbers, I opened and closed the cover 20 times, with these results:

openclose
success14 (70%)7 (35%)
fail6 (30%)13 (65%)

The last change that introduced a further event refire after 500ms and that Wallace0 mentioned here did not affect the situation noticeably.

The hit rate is strongly dependent on the opening/closing speed: If i move the cover really calmly, everything is fine. Fast motion is especially difficult on close.

VolMi avatar Dec 09 '13 23:12 VolMi

Hi,

I investigated that stock kernel contains code for the magnetic switch included in the cover.

dmesg | grep flip

shows lines like this

<7>[12248.641932] [keys] flip_cover_work : 0 <7>[12248.641932] [keys] flip_cover_work : 1

maybe it's possible to get it working without the approx sensor. not sure how the kernel event is mapped to regular intents.

habeIchVergessen avatar Dec 10 '13 15:12 habeIchVergessen

Oh, nice find! I see that, too using CM11 and with HallMonitor disabled.

VolMi avatar Dec 10 '13 15:12 VolMi

Currently we are using the magnetic sensor value - we're picking it up from /sys/devices/virtual/sec/sec_key/hall_detect. There doesn't seem to be any intents associated with a state change in the value, so instead we use intents coming from the proximity sensor to trigger action, and then we check for the state of the magnetic sensor to be sure if the cover is closed or not. The 200ms delay which improved things on the S4 mini would simply have allowed for delays in the update to the hall_detect file to be accommodated - a problem that seems much more prevalent on the mini. The fact that it is still not working that great (and thanks @VolMi for the updated details) even with an additional 500ms delay means that probably something else is going on.

I'm a little busy this week, but I'll have a look as soon as I get the chance to see what else we should try to improve it. (though not owning an S4 mini doesn't help!).

Wallace0 avatar Dec 10 '13 15:12 Wallace0

Yep, I found that same event in the logcat during my initial research. As you said, I couldn't find any intents related to it. There must be some udev event (or something) associated with the hall effect sensor firing, because it shows up in the log, but I was unable to figure out how you subscribe to that. But that would most definitely make the triggering more reliable, if we figured out how to do it.

I'm back now from my crazy travel week, so I'll be able to do some more coding.

On Tuesday, December 10, 2013 at 10:59 AM, Wallace0 wrote:

Currently we are using the magnetic sensor value - we're picking it up from /sys/devices/virtual/sec/sec_key/hall_detect. There doesn't seem to be any intents associated with a state change in the value, so instead we use intents coming from the proximity sensor to trigger action, and then we check for the state of the magnetic sensor to be sure if the cover is closed or not. The 200ms delay which improved things on the S4 mini would simply have allowed for delays in the update to the hall_detect file to be accommodated - a problem that seems much more prevalent on the mini. The fact that it is still not working that great (and thanks @VolMi (https://github.com/VolMi) for the updated details) even with an additional 500ms delay means that probably something else is going on. I'm a little busy this week, but I'll have a look as soon as I get the chance to see what else we should try to improve it. (though not owning an S4 mini doesn't help!).

— Reply to this email directly or view it on GitHub (https://github.com/durka/HallMonitor/issues/12#issuecomment-30239775).

durka avatar Dec 10 '13 16:12 durka

I hope I am not only producing noise due to very superficial knowledge...

Did you already find

#ifdef CONFIG_SENSORS_HALL
        int gpio_flip_cover;
        int irq_flip_cover;
        bool flip_cover;
        struct delayed_work flip_cover_dwork;
#endif

in gpio_keys.c?

It looks like it should be possible to find a related event/intent in the source code itself for more savvy people.

edit: if you search for all those #ifdef CONFIG_SENSORS_HALL in that file it really looks like all the magic is in there.

VolMi avatar Dec 10 '13 16:12 VolMi

if i'm not mistaken then function hall_detect_show generates the output of /sys/devices/virtual/sec/sec_key/hall_detect.

habeIchVergessen avatar Dec 11 '13 15:12 habeIchVergessen

I think you're right about that, @habeIchVergessen (also nice to meet you!). The question is, what else happens on a sensor event besides that output being generated, and how do we hook into it? I have a feeling NDK will be required. Maybe grepping around for hall_detect_show can elucidate.

durka avatar Dec 12 '13 05:12 durka

kernel sided SW_FLIP is similar to SW_HEADPHONE_INSERT defined in input.h. android sided it's redefined in InputManagerService.java and implemented in WiredAccessoryManager.java. for me it doesn't look like NDK. but i know that my development experiences are very low with android.

this could be the hook IntentFilter(Intent.ACTION_USER_SWITCHED).

habeIchVergessen avatar Dec 12 '13 08:12 habeIchVergessen

We're getting closer... I'm fairly sure ACTION_USER_SWITCHED is not it, that's "switch logged-in user" as opposed to "user pushed hardware switch". One thing I can't figure out is how you actually get an instance of InputManagerService?

durka avatar Dec 12 '13 16:12 durka

deodex from stock

package com.android.server.input;

import ...;

public class InputManagerService extends IInputManager.Stub
  implements Watchdog.Monitor, DisplayManagerService.InputManagerFuncs
{
  ...
  public static final int SW_FLIP = 21;
  public static final int SW_FLIP_BIT = 2097152;
  public static final int SW_GLOVE = 22;
  public static final int SW_GLOVE_BIT = 4194304;
  ...
}

as assumed getSwitchState reads the magnetic switch

package com.android.server.wm;

import ...;

public class WindowManagerService extends IWindowManager.Stub
  implements DisplayManager.DisplayListener, WindowManagerPolicy.WindowManagerFuncs
, Watchdog.Monitor, DisplayManagerService.WindowManagerFuncs
{
  ...
  public int getCoverState()
  {
    int i = -1;
    try
    {
      int j = this.mInputManager.getSwitchState(-1, -256, 21);
      if (j > 0)
        i = 1;
      do
        return i;
      while (j != 0);
      return 0;
    }
    catch (Exception localException)
    {
      Log.e("WindowManager", "getCoverState(). Can't get cover state!");
    }
    return i;
  }
  ...
}

several files contain an IntentFilter "com.samsung.cover.OPEN". but i can't find any implementation that fires such Intent.

kernel sided /dev/input/event10 handles Volume-, Home-Button and HallSensor.

hexdump -n 16 -C /dev/input/event10

habeIchVergessen avatar Dec 14 '13 08:12 habeIchVergessen

Hi, I have been doing my own research in the SGS5 kernel source trying to spot any useful information concerning the cover open/close event and then I stumbled upon this discussion. As correctly mentioned earlier, the driver produces uevents, but the stock android code just ignores them, since the hall sensor is not something default for android phones. Since all the kernel->userspace event translation/forwarding is done through the InputManagerService, there is no clean way to consume the events. It seems our only option is to patch InputManagerService so that it produces the correct intents and at least send a PR to CM11, so that we can get it to work there.

nemphys avatar Mar 26 '14 14:03 nemphys

Indeed patching InputManagerService seems like the way to go.

On Wednesday, March 26, 2014 at 10:51 AM, Dimitris Kazakos wrote:

Hi, I have been doing my own research in the SGS5 kernel source trying to spot any useful information concerning the cover open/close event and then I stumbled upon this discussion. As correctly mentioned earlier, the driver produces uevents, but the stock android code just ignores them, since the hall sensor is not something default for android phones.
Since all the kernel->userspace event translation/forwarding is done through the InputManagerService, there is no clean way to consume the events. It seems our only option is to patch InputManagerService so that it produces the correct intents and at least send a PR to CM11, so that we can get it to work there.

— Reply to this email directly or view it on GitHub (https://github.com/durka/HallMonitor/issues/12#issuecomment-38692671).

durka avatar Mar 26 '14 17:03 durka

Please check http://review.cyanogenmod.org/#/c/68621/

kumajaya avatar Jul 19 '14 15:07 kumajaya

I have the 3g version whit cmyanogenmod 11 and I can't use the touch functions on the window from the cover. Please someone help me

panchito153 avatar Aug 08 '14 22:08 panchito153

connect your device to pc and run following commands in adb:

echo module_on_master > /sys/class/sec/tsp/cmd && cat /sys/class/sec/tsp/cmd_result echo clear_cover_mode,3 > /sys/class/sec/tsp/cmd && cat /sys/class/sec/tsp/cmd_result

test touch events with closed cover.

if it works then you have to patch line 205 of Functions.java.

habeIchVergessen avatar Aug 09 '14 11:08 habeIchVergessen

@kumajaya I am working on a refactor of HallMonitor to be able use integrated system action and/or HallMonitor services.

manusfreedom avatar Aug 21 '14 08:08 manusfreedom

tanks for your help habeIchVergessen but i dont really know about this stuff so i dont know too well how to do that.

panchito153 avatar Aug 23 '14 01:08 panchito153

next nightly should include flip cover changes

habeIchVergessen avatar Aug 26 '14 10:08 habeIchVergessen

My version already support it, but not committed now. I will try for this week-end.

manusfreedom avatar Aug 27 '14 07:08 manusfreedom

CM-Team made the required changes in android_framework_base. they added an intent ACTION_LID_STATE_CHANGED ("android.intent.action.LID_STATE_CHANGED") which signals cover open/close events. ~~still not working yet (20140826-Nightly).~~

habeIchVergessen avatar Aug 27 '14 12:08 habeIchVergessen

Please try my 2.0.0 beta https://github.com/manusfreedom/HallMonitor/commit/fc74f935d3bd8107d7e3c320e67bf19778ffe6a6 I have not tested on last CM 11 (need to update my phone).

manusfreedom avatar Sep 03 '14 23:09 manusfreedom

Hi @manusfreedom , downloaded your 2.0 beta version, I'm unable to install it successfully. Tried on a clean install, also tried manually copying the apk to /system/app, however, it sill FC's

diegolopezlr avatar Sep 04 '14 00:09 diegolopezlr

only flash via recovery works. screen doesn't turn on since CM-Team has added "partial smart cover support" (nightly 2014-08-27). you have to use WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON.

habeIchVergessen avatar Sep 04 '14 08:09 habeIchVergessen

Install theough recovery use system app feature, so normally no need of WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON because we wake up all the system like the power button. I think they don't send the LID_OPEN event. So, for now continue to use real hall service.

manusfreedom avatar Sep 04 '14 09:09 manusfreedom

tried to install both apk's, but always failed.

LID-OPEN event works properly (see framework test). cm's changeset explicitly enables turn screen on while cover is closed, when the current window use FLAG_TURN_SCREEN_ON. otherwise they don't turn on the screen.

habeIchVergessen avatar Sep 04 '14 09:09 habeIchVergessen

I am on 20140903-Nightly and their LID system does not always work (and only for close).

manusfreedom avatar Sep 04 '14 11:09 manusfreedom

i'm using 2014-08-07-Nigthtly and it works properly. did you tested my "framework test"? maybe an cross talk with your native code. the apk (installed from zip) only shows up, when cover was opened and screen off when closed. i have to reboot to get access to ui back.

habeIchVergessen avatar Sep 04 '14 12:09 habeIchVergessen

@habeIchVergessen i have to reboot to get access to ui back (or kill process)=> It’s a bug to keep a single instance, try last version commited.

manusfreedom avatar Sep 04 '14 12:09 manusfreedom

as mentioned before: installation failed! and yes kill would be an option but requires access to ui!

HallMonitor/cm_certs/zip/common/HallMonitor.apk sha256: 0a38cd1e262f1875d0d17528a2343df5a8f6aa0723b5c3146d8f560dce6e0535 source

habeIchVergessen avatar Sep 04 '14 13:09 habeIchVergessen

I think it's a misunderstood, I speak about Hallmonitor ui (configuration activity) or OS ui (launcher after HallMonitor)? Because the problem with the Cyanogen, they have their own smart cover screen and Hallmonitor seem conflict with it (and it is normal, Cyanogen must provide a settings to disable their). I have no conflict using Hallmonitor and his RealHall service on 20140903-Nightly. Without RealHall service, it does not work at all. And yes you can't use https://github.com/manusfreedom/HallMonitor/tree/master/download/CM_SystemApp without put it in /system/app (and must be copied to 2 times (overwrite each time) with root access or installed through recovery). I compiled a version without system signature and both system parameters in AndroidManifest: https://github.com/manusfreedom/HallMonitor/tree/master/download/debug

manusfreedom avatar Sep 04 '14 15:09 manusfreedom