Root Using Logcat to Debug Screen

[AndyDroidBot]

bads3ctor is the only user to have successfully gathered a Logcat dump to give definitive information regarding the "long-press and drag and drop" bug in this phone. Looking further into the issue and doing a little more reading, I don't think we've utilized Logcat to it's full potential and I also don't think the issue has anything to do with a broken digitizer or bad drivers (I suspect it's the way some firmware is compiled with the rom or kernel, ie: inputdispatcher.cpp)

Using the "Log" class in ADB can be scary to new users, but is a life line for devs to debug and fix errors, it essentially is Android's built-in bug-finder.
To learn a little more about what some of the Logcat "flags/switches" do you can read here:
Running Logcat (Advanced way)
and here
Flags

A developer at XDA, named Michael Perez, made an app to easily gather Logcat information (with many flags, and also supports kernel logging) specifically tailored to those of us who are not devs or power users.

This application is called "LogThis" and can be found at the Play Store here:
LogThis

In the attatched youtube video, it gives a description of how to run and how to create an output, according to Michael Perez, once the app is running it collects data for around ~10 minutes, just long enough to minimize the app, go to the homescreen and try to drag an icon around until the error manifests itself again, and then go back to the app to collect the log.

 

[BLuFeNiX]

What application tag should I enter?
Do you need All logs, Debug, Information, Warnings, or Errors only?
What about Android runtime errors?

I know I'd probably be safe if I just enabled everything, but that can make finding the problem harder. If we want users to post logs, we need simple step-by-step instructions of what to do.

 

[AndyDroidBot]

As per request here is a simple-to-follow written guide.
This will function as a "How-to" for generating logs for easy viewing.
This application does not require the phone to have root privileges. Logs can be generated without making any modifications to your phone (or tablet).

Please note: The youtube video made by the developer who wrote the app I attatched in the first post has this same information in somewhat greater detail and visuals, if you are having a hard time generating logs after reading these instructions then please watch the video (it is around 8 minutes long).

Step 1)
Download "Log This" by Mgamerz Productions, from Google Play (Android Market).
Here is a link to make sure you have the correct application.
Google Play Store Link: Log This

Step 2)
The First screen you see will ask you how you want share the finished log, in the interest of time select "Post Logs to Pastebin." If you were to select "Send Logs via Email" you don't get to choose how long the phone collects data before it generates a log.


Step 3)
The next thing you must do is enter a "log tag" which is essentially a feature of Logcat to help create a more well defined log by filtering out information that will not be useful to your bug search[/I][/B]

This is a short excerpt from Google's Developer website explaining how they do it:
Every Android log message has a tag and a priority associated with it.

The tag of a log message is a short string indicating the system component from which the message originates (for example, "View" for the view system).
The priority is one of the following character values, ordered from lowest to highest priority:
V

 

[smith058]

Wow what details.... you're now disignated detail wrighter for our forum... lol gj

 

[bads3ctor]

I have a theory as to what is causing the touchscreen fault but I have yet to find a way to verify it. It could be i/o latency causing the touchscreen driver to drop input data. If anyone knows a way to test i/o latency in Android...I'm all ears.

Edit: I have requested some changes to Bob's OC kernel to test my theory:
http://androidforums.com/transform-...locking-kernel-sph-m930bst-2.html#post4224180

I'd hate to do all this work just to find out I am wrong about this.

 

[AndyDroidBot]

If anyone knows a way to test i/o latency in Android...I'm all ears.

I didn't even think of this so I did a quick google search, only to find that an app had been written for Audio latency (unrelated)...

After I read the top comment I got to thinking.
If you believe the processor may be getting choked up, it may be the scheduler!

XDA has the GREATEST written post ever on how to modify a kernel.
[REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs - xda-developers

Post #4 deals with IO schedulers

 

[Loota]

no-frills cpu control allows you to change I/O scheduler between noop and cfq... I have been using cfq and still have issues with it. I will try noop and report back.

EDIT: just tested with noop enabled and there is no change but I am questioning if the app can change the scheduler without an option being enabled in kernel?

As for the original post in this thread I have it installed and have tried to get a logcat using this method but have not been able to populate it, I will try after watching the video now and see what I can do... worst comes to worst and I will just run an actual logcat with ddms and see if I can't contribute.

 

[Loota]

What application tag should I enter?

As near as I can tell we want InputReader and InputDispatcher. Can someone confirm this? I found this by viewing my log in alogcat and as near as I can tell this is what handles the touchscreen.

here is my pastebin of those two tags. Transform Ultra InputReader/InputDispatcher - Pastebin.com

Note** the v, d, i, w, e, f and s tags do not work and as near as I can tell that describes the a different type of tags found in a logcat and not what this app specifically looks for (which I think is a filter to only show you logs of whatever app or process you specify)

Edit: I definitely think InputReader and InputDispatch are what is needed but I wonder if we need more then just those two? If someone confirms this or can post what we actually need I will use screencast to make a video and take screenshots to make this process even easier to do for endusers for this purpose...

 

[Loota]

Screw it I can always change the video... I just like making and posting things... So here it is a video tailored to the purposes of this thread... As I mentioned please let me know if we need anything else to be logged and I will change it.

Making a logcat using InputReader and InputDispatcher with logit. - YouTube

 

[AndyDroidBot]

Loota is correct, the tags in my original post are filters for doing it the manual way. Sorry for any confusion.. but now that also means I am unsure of what this app uses to filter results.

I have located a website that hosts the repo for the original Android 2.3.4 R1 source (all in Java I believe)
http://grepcode.com/snapshot/repository.grepcode.com/java/ext/com.google.android/android/2.3.4_r1/

It makes it easier to download this way so you don't have to sync with google and wait a bunch to do the download. Once you have the source I have a question for anyone who can analyze it better.

I've downloaded it and opened the java containers with 7Zip on my windows PC, I do not yet have a linux dual boot environment set up, but I really don't know what files I am looking for as it is not very self-explanatory. There is an entire file dedicated to sensors, drivers, and touch utilities, and I'm thinking they can be copied over and recompiled to the source from samsung's open source website.

back to the original point of this thread, which is logcat, it's very interesting that you also returned the same name of a problem area as Bad's original logcat post.
check this out

Failure starts here:

20:07:15.176 Info InputReader 167 dispatchTouch::touch event's action is 1
20:07:15.176 Info InputDispatcher 167 Delivering touch to current input target: action: 1, channel '4079a630 com.android.development/com.android.development.PointerLocation (server)'
20:07:15.176 Info Pointer 1174 Pointer 1: (177.0, 351.0) Pressure=0.149 Size=0.0 TouchMajor=0.0 TouchMinor=0.0 ToolMajor=0.0 ToolMinor=0.0 Orientation=0.0deg
20:07:15.176 Info Pointer 1174 Pointer 1: UP
20:07:15.212 Info InputReader 167 dispatchTouch::touch event's action is 0
20:07:15.212 Info InputDispatcher 167 Delivering touch to current input target: action: 0, channel '4079a630 com.android.development/com.android.development.PointerLocation (server)'
20:07:15.212 Info Pointer 1174 Pointer 1: DOWN
20:07:15.212 Info Pointer 1174 Pointer 1: (181.0, 308.0) Pressure=0.118 Size=0.0 TouchMajor=0.0 TouchMinor=0.0 ToolMajor=0.0 ToolMinor=0.0 Orientation=0.0deg
20:07:15.255 Info InputReader 167 dispatchTouch::touch event's action is 1
20:07:15.255 Info InputDispatcher 167 Delivering touch to current input target: action: 1, channel '4079a630 com.android.development/com.android.development.PointerLocation (server)'
20:07:15.255 Info Pointer 1174 Pointer 1: (181.0, 308.0) Pressure=0.118 Size=0.0 TouchMajor=0.0 TouchMinor=0.0 ToolMajor=0.0 ToolMinor=0.0 Orientation=0.0deg

one thing I read about Logcat is it's output is Java errors (makes sense seeing as how the Dalvik player is a java compatibility layer)
I searched and searched but couldn't find any information regarding "error 167" which is in parenthesis here. but what IS interesting about some of the online logcats I've found is that they all have different error codes for the given problem areas. The ones based on "InputReader"

XDA Thread

these folks at XDA with another samsung phone (galaxy ace) have a log posted about half way down the page and it's error code 173, but still has to do with InputReader

here is the C++ file that goes in the kernel in full, is it possible to compare this to the one are already have to see if some punctuation or something simple is missing?
libs/ui/InputDispatcher.cpp - frameworks-base in rowboat - Gitorious

 

[AndyDroidBot]

EDIT: Here's something else I found on that website,
These are all the .cpp files for handling inputs and touch events

Library files for kernel

Input.cpp
InputDispatcher.cpp
InputManager.cpp
InputReader.cpp
InputTransport.cpp

 

[Loota]

While it's good to know the other files that may be involved rowboat seems to be an ics android port to ti calculators not sure if that applies.. I'm trying to find a version of InputReader version specifically for our phone... Looking in source but I'm not seeing anything...

https://github.com/android/platform_frameworks_base/blob/master/services/input/InputReader.cpp

What do you think of this? Look at lines 163 and 159 which are the two numbers being thrown up by bads and my logs respectively...

 

[bads3ctor]

I have been trying to get cm7 or cm9 booted on the TU to verify if the problem is actually with frameworks inputreader or with the kernel. If I get cm7 booted and we still have the TS bug then the problem would most likely be with the kernel driver or with some other app or driver intermittently taking the I/O bandwidth from the TS driver.

 

[ChoznJuan]

Thank you guys for the instructions. I think these are my logs....hope this helps.
http://pastebin.com/CiNKDW8H