Develop Bugs

Temperature hacks on the Tab (battery, and the other sensor)

First of all, I needed SetCPU to detect the battery temperature on my overclocked Galaxy Tab (to switch profile when overheating), so I modified my home-brewed kernel with this small patch:
http://forum.xda-developers.com/showthread.php?p=11454036#post11454036
This is fine, but on my JMI ROM (even with the correct /system/lib/hw/sensors.default.so library), applications like "SensorTest" were not displaying the temperature from the AK8973B sensor. I found a way to fix this.
Basically, I compiled this open-source driver (or alternatively, this one), which provides a custom sensors.default.so library and akmd service executable. The former is actually not needed, only the latter needs to be run on the Tab (because the standard /dev/akm8973_daemon device node is used, via ioctl to update the /dev/input values for compass, etc.).
First, I stopped the default /system/bin/akmd2 service. I then launched the custom akm daemon, which showed wrongly-calibrated values for the compass and orientation sensors (because I entered random digital and analog gain values), but the correct temperature was displayed (actually higher than the battery one !). I then stopped akmd, and re-launched akmd2...and magic: the temperature is now picked-up correctly !
Note that the gyroscope and accelerometer sensors are *not* affected these AKM modifications (they are effectively different hardware, with different drivers). The ambient light and proximity sensors are also different hardware (the latter isn't enabled on the Tab, by the way...I suspect we need to compile/install a driver for it).
I will do more testing with akmd and akmd2, and I will probably modify my init.rc to launch the service accordingly (in my custom initramfs).
I hope this helps.
Cheers, Dan
--- EDIT ---
Mhmmm, here's an interesting update:
There is no need to compile the open-source AKM daemon ! Instead, you just need to kill the /system/bin/akmd2 process, and restart it.
Well, actually it's not that simple: it only really works when the temperature sensor is polled (for example, when the SensorTest or Elixir app is displaying current values). Oh, and the temperature sensor only spits-out results when the compass sensor is also polled at the same time ! (Elixir is useful to test this, because sensors can be selectively activated)
I tried to reverse-engineer the values coming out of /dev/input/event4 (which corresponds to the compass sensor, as shown by the getevent command). I used shell commands similar to that (note the automatic conversion from hexadecimal to decimal values):
Code:
getevent | grep "/dev/input/event4:" | sed 's/ffffff//g' | awk '{print $2 " " $3 " " ("0x"$4)+0 ">" $4}'
Unfortunately my time ran out before I could make sense out the stream of values.
By the way, here is the script I used to stop+restart the AKM daemon in init.d/ :
Code:
get_akmd_pid()
{
ps -w | grep akmd2 | grep -v grep | awk '{print $1}'
}
pid=`get_akmd_pid`
echo "Killing /system/bin/akmd2 (PID: ${pid}) ..."
kill -9 $pid
pid=`get_akmd_pid`
echo "Checking that /system/bin/akmd2 process has been terminated: now PID = [${pid}] (should be empty)"
echo "Restarting /system/bin/akmd2..."
/system/bin/akmd2 &
pid=`get_akmd_pid`
echo "Checking that /system/bin/akmd2 process has been restarted: now PID = [${pid}] (should NOT be empty)"

What temperature do you consider too hot on your tab? I currently have my set to underclock from 1.4 ghz to 800 mhz whenever it reaches 90 degrees Fahrenheit (I am a worry-wart), but it reaches that a lot, so I was wondering what you have the maximum temperature set to before you bring the clock speed down.
Thanks

caveman999 said:
What temperature do you consider too hot on your tab?
Click to expand...
Click to collapse
I'm not sure yet. The battery temperature is lower than the one indicated by the AK8973 sensor. As it stands, SetCPU switches profiles based on the battery temperature, so personally I use conservative values (at the moment, 35 degrees Celcius).
By the way, the original post has been updated to reflect new findings.
Cheers, Daniel

my temp sensor is stuck at 30 c after flashing a kernel how do i get it to work. what you posted did not work. im actually stuck in a boot loop

nev310 said:
my temp sensor is stuck at 30 c after flashing a kernel how do i get it to work. what you posted did not work. im actually stuck in a boot loop
Click to expand...
Click to collapse
Same here, stuck on 30 degrees C. Any fix would be appreciated.

Any updates on this

activity manager cpu 100%

Hi
i have a weird thing , dont know if its rom related but defenetly noticed it after rooting my device and installing cosutm roms. well i only used ARHD since 2.0.09 and i love it.
but , what happens is that suddenly and out of nothing (after like hours/days and the rom running smooth and ultra fast) , system cpu usage jumps to 100% and never bugs off only through a restart, and this seems to happen with all the different versions of ARHD i had, even though i install most of them with full wipes. but this i don't understand and it annoyes me cos it uses this cpu amount and drains battery and it happens suddenly and randomly , dunno what triggers it, and no matter how i tried to track it to see the error but couldn't find a thing.
i just hope u can help me by taking a look at this log i saved from android systeminfo app registering some errors (3 min log and it drained 14% battery ) , it shows something about "activity manager", im not a developer and i know nothing about those codes, but would be awesome if someone helps me out with any tip please.
thank you.

I am not a DEV but i don't think your log file includes any clue of what is causing your problem. Do you have sense account on? or any types of account that let you track your phone?

Activate usb debugging
Seems to be the bug with the .init process.
Sent from my Desire HD using Tapatalk

thank you for the replies , i already have usb debugging on. dunno what is causing this, its totally random and its driving me nuts.

can you see a process that uses 100% cpu in android system info? If yes, try to kill it and look at your cpu usage.
CPUNotify is a great tool. It shows cpu usage in the notification bar
Sent from my Desire HD using Tapatalk

the process showing 100% cpu usage (not always but randomly, no idea what triggers it ) is system , and u can't force close or end that task

Hmm strange... i can't even find a process called activity manager on my phone...
Well i don't know but maybe it's related to the DroidDream malware. Some apps in the market were infected with this virus. And i've read that the virus gains root access and can download other apps in the background.
Here's a link: http://forum.xda-developers.com/showthread.php?t=977154
I really don't know if it's related to this but it just came to my mind
Sent from my Desire HD using Tapatalk

thx for the help mate , but i dont think its related to droidream cos ive been having this issue since a while (long time before droidream was up )
im still monitoring to find out what is causing this issue.

i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
Activate usb debugging
Seems to be the bug with the .init process.
Click to expand...
Click to collapse
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.

wow , cheers mate for the help , sounds a bit complicated for me but at least we know what it is now and how to get over it.
but how come mike1986 doesnt know about this bug and its fix ? he could incorporate this into his next build so it saves us that command run every 15 mins. or it cant be incorporated ?
someone should tell him to be honest
but cheers for explanation mate, thank you

Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.

walda said:
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
Click to expand...
Click to collapse
i have no idea about that , if he does then im sure he will fix it

As I read in mikes 3.0 thread, he is informed. Fine...
sent from my DHD via Tapatalk

further to this.
in ProcessStats.java (im not sure if this is a kernel file or if it sits just outside the kernel).
mBuffer looks to me to be the main problem.
1. in apaches rom, which is overclocked he defines 23 CPU speeds..ProcessStats.java only allows 20
Code:
private long[] getCpuSpeedTimes(long[] out) {
long[] tempTimes = out;
long[] tempSpeeds = mCpuSpeeds;
final int MAX_SPEEDS = 20;
if (out == null) {
tempTimes = new long[MAX_SPEEDS]; // Hopefully no more than that
tempSpeeds = new long[MAX_SPEEDS];
this is a minor issue..as this overflow is trapped in the loop anyway:
Code:
if (speed == MAX_SPEEDS) break; // No more
however, the definition of mBuffer is too small:
Code:
private byte[] mBuffer = new byte[256];
my file at the moment is 300 bytes. the readFile reads only once instead of looping until end of file:
Code:
int len = is.read(mBuffer);
is.close();
so only the first 256 bytes are ever read.
My assumption is that IF the files first 256 bytes ends up cutting off the last read line (and that line lies in the first MAX_SPEEDS lines of the file) before the speed time element..this causes a NoSuchElementException to throw..as the last line will be like
921600 255
960000 750
998400 8042
10368
ie the line
1036800 3089
was cut off too soon and this code
Code:
long val = Long.parseLong(token);
tempSpeeds[speed] = val;
token = st.nextToken(); <-- here
val = Long.parseLong(token);.
in getCpuSpeedTimes() fails as it cant see the timing?
would then fail on the second nextToken().
the big question is who owns that code in our custom ROM? is it the same as the original android code so we are at the mercy of Google to fix it or is this something Mike / Apache will be able to patch up ..assuming i'm making sense
the only workaround is as i said before: to chmod this file to 700 and ensure it stays there (avoid using setcpu as it changes the permissions).
You can probably also reduce this by limiting the CPU frequency range your phone uses (ie keep the filesize smaller)..if you have profiles that span 200mhz to 1.2ghz then you will probably hit this sooner
i did a test.
1. rebooted my phone..ensured time_in_state had permissions -r--r--r--
2. manipulated CPU frequency using cpu tuner to make all frequencies have at least 5 bytes per line.
once the first 20 lines were > 256 bytes and the 256nd byte sat between <cpu speed> and <time spent at that speed> i get the loop.
eg just before the issue arose i saw:
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 9937
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
i had my cpu pinned to 960 mhz.
the 256 at this point lies here:
Code:
1075200 1560
1113600 1
ie line 20 is cut off after 1..this is still "valid" in terms of the data in mBuffer..but once 960 rolled into five digits
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 10288
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
the 256 byte now meant the last line shifts to:
Code:
1036800 6864
1075200
the 2nd word is now totally missing!
as soon as this happened..my logcat started issuing
Code:
Unexpected exception collecting process stats
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:272)
at com.android.server.ProcessStats.getCpuSpeedTimes(ProcessStats.java:596)
at com.android.server.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:568)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1657)
at com.android.server.am.ActivityManagerService$4.run(ActivityManagerService.java:1583)
errors.
something later on then causes this behavior to go into a full tight loop (as once the issue starts..it just issues this every few seconds..so most uses wont notice it).

didnt mike fixed it with his latest release (ARHD 3.1) ?

Goodm7sn said:
didnt mike fixed it with his latest release (ARHD 3.1) ?
Click to expand...
Click to collapse
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).

DazzaL said:
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
Click to expand...
Click to collapse
Thanks mate, your solution is really effective on my DHD with revolution 3.0.
I am going to reflash with revolution 3.1, hopefully 3.1 will cure the cpu 100% usage

im on android revolution HD and i can confirm this , 100% system cpu of death is still here, didnt get fixed , had to change setcpu frequency and it stopped
meh phone cant last 12 hrs without a restart, frustrating.

DazzaL said:
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
Click to expand...
Click to collapse
if setcpu changed the range once the gui is opened , what do u recommend us to use for overclocking ? something safer
thx for helping

I read that it happens with CPU tuner and even without anything also!
The only solution I see is to fix the frequency file.
sent from my DHD via Tapatalk

Adjusting the "Touch Slop" in CM9 (from 8 to 16)

I responded in the larger CM9 thread but it will probably be buried in a day or so. And I think this will help devs who are working on CM9 builds at the moment.
------------------------------------------------------------------
jdommer said:
The correct settings for the our touch screen appear to be:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
# Size
# Based on empirical measurements, we estimate the size of the contact
# using size = sqrt(area) * 28 + 0.
touch.size.calibration = default
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
# Pressure
# Driver reports signal strength as pressure.
#
# A normal index finger touch typically registers about 80 signal strength
# units although we don't expect these values to be accurate.
touch.pressure.calibration = none
touch.pressure.scale = 1.0
# Orientation
touch.orientation.calibration = default
Unfortunately, that doesn't do anything for the tap/drag problem. The KF can't distinguish pressure or size of touch.
Looks like Android decides any touch where x1-x2 or y1-y2 > 8 as a drag. I can't find any place that that value is configurable after scouring the internets all morning, but if it could simply be turned up to maybe 12 that would probably alleviate 90% of our taps as drags problems.
Anyone have any idea, is there a config file or is that compiled in and has to be changed at source? I feel competent enough to dink with config files, but can't compile crap.
Click to expand...
Click to collapse
I build from the KFire-Android git as a testing model and i've been experimenting with a setting of "16" for touch slop, and in my opinion it's working much better.. could probably be 12, but who knows. I'm having a much easier time selecting things like Beautiful Widgets 1x1 Toggles, where before it was a trial of patience and about 10 touches.
This is a setting in the overlay config.xml file. I went ahead and committed it this morning to the KFire-Android org at Github:
https://github.com/KFire-Android/device-amazon-otter/commit/56b3d52fe6c645a18e60ab765e5b9831cb6a0663

Is the code that uses the clickSlop in android hackable for KFire?
I found on my device that most of the noise on taps was occurring in the last few samples (like the touchscreen firmware is averaging in some bad samples on finger release) and that by dropping the last few touch events I got much better touch response in my app. I'm not sure where to put such a state machine in the framework, though, or how to have it only for KFire...
(My state machine would buffer 3 samples ahead for the first 20 samples, and then drop the last 3 samples on finger up and patch N-3 to be a finger up instead of a move -- after 20 samples it just passed everything through with no buffering to avoid adding latency to drags).

Hardware/driver info gathering for ICS/JB

In response to the ICS leak, I have abandoned this thread in favor of a different approach. I'm leaving it here purely for archival purposes.
I have something stewing. I'll make a thread when I'm ready.
Compiling a list of the drivers required and making sure we've got them all checked off; that's the first step to making an ICS port happen, right? I'm giving it the old gentleman try.
All input is nice; I'm a complete noob to kernel-level Android. I'm familiar with troubleshooting drivers on x86 but I don't know the buses and whatnot involved here.
KEY: RED == we don't know enough about the item to find/make an appropriate driver; YELLOW == enough info is available to write a driver but we haven't found/made one yet; GREEN == A driver that SHOULD work for ICS/JB is already available.
So, all the drivers we need:
Video. Tegra 2 Ventana. Driver Available.
Audio. Wolfson WM8994. Driver Available.
Power/volume buttons. Dedicated interrupts. Even if a driver is not available, it should be trivial to do, unless I'm naive of some major ARM architecture quirk.
Flash/microSD access. CWM can do this, so we know how to do it, but is there a 3.0 driver available or are we gonna need a kernel hacker?
Cell radio. Appears to be a Samsung custom proprietary something or other, because they wrote their own damn driver for it. I'm gonna be digging through the Samsung source release for the kernel bits, but we have a big ugly problem in the form of two closed source binary blobs in the pipeline from Android to hardware named libsec-ril.so and libsecril-client.so. We need to either a) get the official blobs to somehow work correctly in the ICS/JB environment (potentially very hard), b) replace these blobs entirely (even harder), c) wait for official straight-from-Samsung ICS/JB versions (yeah, when's that happening again?) or d) substitutde official blobs from another phone (which is likely to not work at all).
USB device mode. Fairchild FSA9480. Galaxy Nexus has the same chip so I'm going to assume a driver is available.
Physical keyboard. Interrupt 215 is mapped to an "STMPE1801". A quick peek at the datasheet strongly suggests this is our keyboard controller. A datasheet is available, but I have yet to find evidence of a 3.0 driver. It may conform to some standard -- does anyone know more about this chip or ones like it?
Touchscreen. Atmel MXT224. An official driver is available on GitHub.
Cameras. Not yet identified. A simply stupid amount of V4L drivers are included in the GB kernel config.gz. Hunting down which ones are actually used may take some time. "CONFIG_TEGRA_CAMERA" looks promising though.
Battery/Charger controller. /proc/interrupts shows a MAX8907C while dmesg shows a MAX8922. Both chips have appeared in devices that have officially gone ICS, so we should be good.
Wi-Fi and Bluetooth. Broadcom BCM4330, a working driver is in the 3.0 kernel tree.
GPS. The GB driver calls itself "gps_sirf" in logcat. Perhaps part of the SiRFstar family? Don't have anything more specific yet.
Accelerometer. The MPU3050 gyroscope has a second I2C port for the express purpose of attaching an accelerometer to it. That port may be empty, or there may be an accelerometer there, and that accelerometer probably wouldn't need its own driver, but no guarantees; there's no easy way to tell until we've actually booted a kernel and seen what the MPU3050 driver gives us.
Proximity and ambient light sensors. Capella CM3663. 3.0 driver is available.
Compass/Orientation Sensor. Asahi Kasei AK8975. 3.0 driver is in the tree.
Gyroscope. InvenSense MPU3050. A 2.6 driver is available; not sure about 3.0.
MHL/HDMI. Yeah, you know what? I'll tackle that when I have everything else more-or-less working.
Saving this and this for me to take a closer look at later.
Wikipedia claims we have a gyroscope a magnetometer HDMI... really? Can anyone confirm this? And what the heck is MHL? There *is* an interrupt mapped for it...
/proc/ioports revealed that we have a Broadcom BCM4330, which is a Wi-Fi plus Bluetooth plus goddamned FM RADIO all-in-one. It apparently can transmit in FM too. If that's actually hooked up to a usable antenna... holy ****.
Here's the raw /proc/interrupts, in case more enlightened eyes grace my presence:
Code:
CPU0 CPU1
36: 150598 0 PPI tegra-avp
46: 4943342 0 PPI mmc2
51: 305330 0 PPI mmc1
52: 11794 0 PPI tegra-otg, fsl-tegra-udc
53: 335496 0 PPI ehci_hcd:usb1
61: 0 0 PPI rpc-arbsema
63: 11198199 0 PPI mmc0
70: 7880675 0 PPI tegra-i2c
73: 9025413 0 PPI timer0
74: 3059444 0 PPI timer_lp2wake
77: 0 0 PPI spdif_out
85: 6188775 0 PPI tegra-i2c
86: 70301 0 PPI stat_mon_int
99: 0 0 PPI host_status
105: 598486 0 PPI tegradc.0
106: 0 0 PPI tegradc.1
116: 1104236 0 PPI tegra-i2c
118: 16978 0 PPI max8907c
124: 80 0 PPI tegra-i2c
136: 7 0 PPI dma_channel_0
137: 0 0 PPI dma_channel_1
138: 0 0 PPI dma_channel_2
139: 615533 0 PPI dma_channel_3
140: 385356 0 PPI dma_channel_4
141: 347 0 PPI dma_channel_5
142: 1283 0 PPI dma_channel_6
143: 0 0 PPI dma_channel_7
144: 0 0 PPI dma_channel_8
145: 0 0 PPI dma_channel_9
146: 0 0 PPI dma_channel_10
147: 0 0 PPI dma_channel_11
152: 0 0 PPI tegra_cpuidle_both_idle
153: 0 0 PPI tegra_cpuidle_tear_down_cpu1
169: 441390 0 syncpt disp0_a
173: 6 0 syncpt vi_isp_1
175: 3 0 syncpt vi_isp_3
178: 577637 0 syncpt 2d_0
180: 695 0 syncpt disp0_b
182: 1890786 0 syncpt 3d
192: 238662 0 GPIO mpuirq
215: 5942 0 GPIO stmpe1801
223: 223163 0 GPIO mxt224_ts
248: 0 0 GPIO mhl_int
261: 0 0 GPIO max17043 fuel alert
276: 454855 15 GPIO akm_int
281: 29 0 GPIO fsa9480 micro USB
305: 136 0 GPIO proximity_int
321: 114 0 GPIO KEY_VOLUMEUP
322: 114 0 GPIO KEY_VOLUMEDOWN
324: 1194 0 GPIO sec_touchkey
338: 0 0 GPIO bt_host_wake_irq_handler
357: 533 0 GPIO KEY_POWER
358: 0 0 GPIO nct1008
362: 1 0 GPIO cp_act
370: 44475 0 GPIO hst_wkp
371: 98 0 GPIO HALL
417: 4 12 max8907c max8907c-vchg_f
418: 4 12 max8907c usb_phy_vbus
438: 3607 5008 max8907c rtc-alarm0
IPI: 7366740 17570126
LOC: 16779564 13867086
Err: 0
NCT1008 is a temperature sensor. Battery temp, I'm guessing.
Here's /proc/ioports. Nothing too interesting.
Code:
00000000-00000000 : sim_det
0000004d-0000004d : bcm4330_nshutdown_gpio
00000073-00000073 : cp_on
00000080-00000080 : hsic_sus
00000083-00000083 : cp_req
00000085-00000085 : hsic_act
0000008c-0000008c : slv_wkp
00000091-00000091 : bcm4330_btwake_gpio
000000a8-000000a8 : hsic_en
000000a9-000000a9 : ap_act
000000aa-000000aa : cp_act
000000b1-000000b1 : bcm4330_nreset_gpio
000000b2-000000b2 : hst_wkp
000000b9-000000b9 : cp_rst

Z-DeviceTest lists the accelermator as "MPL accel" and vendor as Invensource, if that helps.

bobbinthreadbare said:
Z-DeviceTest lists the accelermator as "MPL accel" and vendor as Invensource, if that helps.
Click to expand...
Click to collapse
Taking a closer look, I see that the MPU3050 has an I2C port intended for an accelerometer. Hmmm.... Well, updated in any case.

roothorick said:
And what the heck is MHL? There *is* an interrupt mapped for it...
Click to expand...
Click to collapse
MHL stands for Mobile High Definition Link, it takes Micro USB out to an adapter which has a power cable connected and then outputs through a male-male HDMI cord to your TV mirroring what's on the screen. It's pretty sweet!
http://www.monoprice.com/products/p...=10833&cs_id=1083314&p_id=8675&seq=1&format=2

what about the so called NFC chip, did you see any indication to that in your digging of drivers need?

No NFC so not needed I think

roothorick said:
[*]Physical keyboard. Interrupt 215 is mapped to an "STMPE1801". A quick peek at the datasheet strongly suggests this is our keyboard controller. A datasheet is available, but I have yet to find evidence of a 3.0 driver. It may conform to some standard -- does anyone know more about this chip or ones like it?
Click to expand...
Click to collapse
The keyboard chip is indeed a STMPE1801, controlled by drivers/input/keyboard/stmpe-keypad.c (in Sammy sources for 2.6.36).
There is even a version in the main Linux tree: http://git.kernel.org/?p=linux/kern...=blob;f=drivers/input/keyboard/stmpe-keypad.c
However, the files differ and I did not try using the mainline version on my Glide.

taiber2000 said:
what about the so called NFC chip, did you see any indication to that in your digging of drivers need?
Click to expand...
Click to collapse
Neither Samsung, AT&T, nor Rogers have ever claimed that the Glide has NFC, and I haven't found any hint of otherwise.

Tested with my s3 and no dice. If there happens to be it's definitely not on GB. My battery in my s3 has NFC printed on the back

I927UCLG9 - ICS leak, coming your way soon.
Code:
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=IMM76D
ro.build.display.id=IMM76D
ro.build.version.incremental=UCLG9
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0.4
ro.build.date=Fri Jul 27 23:37:33 KST 2012
ro.build.date.utc=1343399853
ro.build.type=user
ro.build.user=se.infra
ro.build.host=SEP-121
ro.build.tags=release-keys
ro.product.model=SGH-I927
ro.product.brand=samsung
ro.product.name=SGH-I927
ro.product.device=SGH-I927
ro.product.board=SGH-I927
ro.product.cpu.abi=armeabi-v7a
# Samsung Specific Properties
ro.build.PDA=I927UCLG9
ro.build.hidden_ver=I927UCLG9
ro.build.changelist=970642
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=samsung
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=tegra
# ro.build.product is obsolete; use ro.product.device
ro.build.product=SGH-I927
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=SGH-I927-user 4.0.4 IMM76D UCLG9 release-keys
ro.build.fingerprint=samsung/SGH-I927/SGH-I927:4.0.4/IMM76D/UCLG9:user/release-keys
ro.build.characteristics=default
# end build properties
dalvik.vm.heapsize=64m
ro.opengles.version = 131072
wifi.interface=wlan0
rild.libpath=/system/lib/libsec-ril.so
rild.libargs=-d /dev/ttyS0
ro.sf.lcd_density=240
#rild.libpath=/system/lib/libril-icera.so
#rild.libargs=-e wwan0
persist.sys.storage_preload=1
#ril.fastdormancy_to=50
# Icera fild
#modem.fild.rootdir=/data/rfs
#modem.fild.blocksize=65528
#modem.fild.baudrate=3500000
#modem.fild.hif=0
#modem.fild.coredump=enabled
#modem.fild.coredumpdir=/data/rfs/data/debug
#modem.powercontrol=disabled
#modem.power.device=/sys/class/gpio/gpio169/value,0,1
#ro.ril.devicename=/dev/ttyACM1
#
# ADDITIONAL_BUILD_PROPERTIES
#
wifi.interface=wlan0
wifi.supplicant_scan_interval=15
ro.com.google.clientidbase=android-samsung
ro.com.google.clientidbase.ms=android-att-us
ro.com.google.clientidbase.am=android-att-us
ro.com.google.clientidbase.yt=android-samsung
ro.com.google.clientidbase.gmm=android-samsung
ro.error.receiver.default=com.samsung.receiver.error
ro.monkey=0
ro.com.google.gmsversion=4.0_r3
ro.config.ringtone=ATT_Firefly.ogg
ro.config.notification_sound=S_Sherbet_Default_message.ogg
ro.url.legal=http://www.google.com/intl/%s/mobile/android/basic/phone-legal.html
ro.url.legal.android_privacy=http://www.google.com/intl/%s/mobile/android/basic/privacy.html
ro.kernel.qemu=0
ro.secdirenc=true
ro.secsddecryption=true
ro.secfulldirenc=true
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt

If you don't mind me asking, where did you get that info?

Aquethys said:
If you don't mind me asking, where did you get that info?
Click to expand...
Click to collapse
from the oneclick exe sitting on my hdd

You own a glide?
Mines ready for crazy testing. Running aokp job on s3, all I need for happiness. Lol

Aquethys said:
You own a glide?
Mines ready for crazy testing. Running aokp job on s3, all I need for happiness. Lol
Click to expand...
Click to collapse
I don't have a glide, someone asked if there was an ICS leak for the Glide, I asked and it magically appeared on my hdd

For all
http://forum.xda-developers.com/showthread.php?t=1590614
If we can get proprietary files ics will boot. Problem is i think it has to be ics proprietary so we will need leak

Aquethys said:
For all
http://forum.xda-developers.com/showthread.php?t=1590614
If we can get proprietary files ics will boot. Problem is i think it has to be ics proprietary so we will need leak
Click to expand...
Click to collapse
It will be leaked soon.
127.93 MB of 665.39 MB (19%) Speed: 8.46 MB/sec
It's uploading very fast
leak thread:
http://forum.xda-developers.com/showthread.php?p=30182275

Thinks working/not working on the leaked rom:
Video. Working (Tested: YouTube-App)
Audio. Working (Tested: YouTube-App, System Sounds)
Power/volume buttons. Working.
Flash/microSD access. Internal /sdcard seems woking. Currently I have no external sdcard for testing
Cell radio. This means GSM/Edge/3g? GSM & Edge are working (Germany). No 3g connection arround here because of my provider...
USB device mode. I can access /sdcard from windows explorer
Physical keyboard. Keys working, Backlight not
Touchscreen. Working.
Cameras. Both Working, also flashlight
Battery/Charger controller. Phone is currently charging.
Wi-Fi and Bluetooth. Wifi: Yes. BT: No device for testing
GPS. I was out for some minutes but couldn't get a gps-fix (gps status app)
Accelerometer. GPS-Status app changes the value when moving the phone...
Proximity and ambient light sensors. Don't know how to test
Compass/Orientation Sensor. Orientation changes by rotating the phone, GPS Status app shows N/S/W/E Orientation
Gyroscope. Don't know how to test
MHL/HDMI. Not owning a HDMI adapter
Supported Languages are: English, German, Espanol, French, Italiano, (something like chinese)

Roeni said:
Thinks working/not working on the leaked rom:
Video. Working (Tested: YouTube-App)
Audio. Working (Tested: YouTube-App, System Sounds)
Power/volume buttons. Working.
Flash/microSD access. Internal /sdcard seems woking. Currently I have no external sdcard for testing
Cell radio. This means GSM/Edge/3g? GSM & Edge are working (Germany). No 3g connection arround here because of my provider...
USB device mode. I can access /sdcard from windows explorer
Physical keyboard. Keys working, Backlight not
Touchscreen. Working.
Cameras. Both Working, also flashlight
Battery/Charger controller. Phone is currently charging.
Wi-Fi and Bluetooth. Wifi: Yes. BT: No device for testing
GPS. Not tested yet
Accelerometer. Don't know how to test
Proximity and ambient light sensors. Don't know how to test
Compass/Orientation Sensor. Orientation changes by rotating the phone
Gyroscope. Don't know how to test
MHL/HDMI. Not owning a HDMI adapter
Click to expand...
Click to collapse
There is an app called GPS Status, the icon is a orange antenna, you can test accel, gps, light sensor, gyro, compass with it

Roeni said:
Thinks working/not working on the leaked rom:
Video. Working (Tested: YouTube-App)
Audio. Working (Tested: YouTube-App, System Sounds)
Power/volume buttons. Working.
Flash/microSD access. Internal /sdcard seems woking. Currently I have no external sdcard for testing
Cell radio. This means GSM/Edge/3g? GSM & Edge are working (Germany). No 3g connection arround here because of my provider...
USB device mode. I can access /sdcard from windows explorer
Physical keyboard. Keys working, Backlight not
Touchscreen. Working.
Cameras. Both Working, also flashlight
Battery/Charger controller. Phone is currently charging.
Wi-Fi and Bluetooth. Wifi: Yes. BT: No device for testing
GPS. I was out for some minutes but couldn't get a gps-fix (gps status app)
Accelerometer. GPS-Status app changes the value when moving the phone...
Proximity and ambient light sensors. Don't know how to test
Compass/Orientation Sensor. Orientation changes by rotating the phone, GPS Status app shows N/S/W/E Orientation
Gyroscope. Don't know how to test
MHL/HDMI. Not owning a HDMI adapter
Supported Languages are: English, German, Espanol, French, Italiano, (something like chinese)
Click to expand...
Click to collapse
Just Tested With AT&T
Everything That You've tested works for it, I tested External And its fine but It Changes The Way your music was set up by giving every song and artist which is really confusing when its the same artist, 3G/4G Works, and yep except theres trouble with The slide down notifications and sometimes they won't open, other than that its working.

I can confirm as well that backlight does not work on the physical keyboard. All sensors are functioning as expected.
Facial recog. is working as expected. Developer's tools mostly work - enabling screen updates causes a soft restart.
I have experienced no soft restarts otherwise.

Scaling the touchscreen on ZE550ML with ZE551ML screen by building kernel

Due to mistake in product description, I now have a ZE550ML phone with the display from ZE551ML model. The difference is in the resolution (720 vs 1080), the screen works fine, but the touch is scaled from left top corner towards the right bottom, due to scaling factor of 1.5.
I would like to fix that by changing the kernel, since android interpolates reported touch value to a screen resolution it seems that all I need to do is to divide the interpolated values by 1.5. Could someone point out where these interpolation takes place? Or maybe there are other better solutions to this problem? So far I've managed to compile the kernel for android 6 from asus source code 4.21.40.112 version and have been playing with different tweaks in the ftxxxx_ts.c, but I'm not sure that this is the right place to fix it.

In case someone will face this problem, the way you can solve is the following:
1. Obtain stock or cyanogenmod source.
2. Change following lines in the file /kernel/asus/moorefield/drivers/input/touchscreen/ftxxxx_ts.h (cyanogenmod, path is different for stock kernel)
#define TOUCH_MAX_X 720
#define TOUCH_MAX_Y 1280
to
#define TOUCH_MAX_X 1080
#define TOUCH_MAX_Y 1920
3. Compile and flash
Rrom updates may break the touchscreen again.