Lindent – amazing script for lazy C coder

For you a lazy C coder, sometimes indentation could be a big mess when you only think about code’s performance and not so into a cosmetic and style. Anyway, I was in that time too, I never thought about the importance of style when I wrote a code until I have to review someone’s code. It’s crappy and PITA, it ended up by me writing the whole code from scratch.

Thanks to kernel source script: Lindent now that cosmetic stuff is over, you can just write the code your way, and in the end call this script to make your code better and readable, and the most important is: it conforms Linux CodingStyle ;-).

Here we go, you can get it from Linux source in script directory: linux-source/scripts/Lindent. Or you can make a leftover from the snippet below:

1#!/bin/sh
   2PARAM="-npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1"
   3RES=`indent --version`
   4V1=`echo $RES | cut -d' ' -f3 | cut -d'.' -f1`
   5V2=`echo $RES | cut -d' ' -f3 | cut -d'.' -f2`
   6V3=`echo $RES | cut -d' ' -f3 | cut -d'.' -f3`
   7if [ $V1 -gt 2 ]; then
   8  PARAM="$PARAM -il0"
   9elif [ $V1 -eq 2 ]; then
  10  if [ $V2 -gt 2 ]; then
  11    PARAM="$PARAM -il0";
  12  elif [ $V2 -eq 2 ]; then
  13    if [ $V3 -ge 10 ]; then
  14      PARAM="$PARAM -il0"
  15    fi
  16  fi
  17fi
  18indent $PARAM "$@"
  19

You can use it as follow:

$ /path/to/Lindent source.c

Consider following images:

1. before

2. After

Lindent uses the features of GNU indent. A tool to change the appearance of a C program by inserting or deleting whitespace.

strace log::SurfaceFlinger

After successfully porting the m5-rc14 last week, i just curious why is it not as stable as m3. Then i try to port the m5-rc15. I was interested to this just because of curious whether pppd is running or not. I have tried to make such ppp connection to USB modem with m3, but the problem seems to be trapped inside stubs.c or stub.c. Forget it, it’s just closed now by Google. My assumption is just, probably in the new sdk i will get ppp running and can make some call or at least able to browse the internet using ppp. Failed with rc14 -i just don’t get why i can’t get stable console. It’s just like switched between /system/bin/sh and /bin/sh, which i copied from OSELAS. So i remove the /bin and edit the environment vars.

The problem still remain. I just get this from the strace log. weird :

18:13:13 writev(5, [{"\4", 1}, {"ServiceManager", 15}, {"ServiceManager: unable to find service SurfaceFlinger\n", 55}], 3) = 71
18:13:13 writev(5, [{"\4", 1}, {"runtime", 8}, {"Still waiting for surface flinger...", 37}], 3) = 46
18:13:13 writev(5, [{"\4", 1}, {"ServiceManager", 15}, {"ServiceManager: waiting for service SurfaceFlinger\n", 52}], 3) = 68
18:13:13 clock_gettime(CLOCK_MONOTONIC, {472, 72299030}) = 0
18:13:13 clock_gettime(CLOCK_MONOTONIC, {472, 72533292}) = 0
18:13:13 clock_gettime(CLOCK_MONOTONIC, {472, 72804040}) = 0
18:13:13 futex(0x12574, FUTEX_WAIT, 0, {4, 999000000}) = -1 ETIMEDOUT (Connection timed out)

So, I just got, application error : com.android.googleaps, An error has occured in com.google.android.googleaps. Unable to create service blah blah blah.

I tried to googling and found that this error usually appear when you just use new emulator and not give -wipe-data when run the new emulator. Okay. i just point my assumption that my hardware is just like the emulator and there’s a memory remain to write data from the old SDK. Do i have to format the file system ? So i decide to flash the fresh and brand new file system.

I do the same procedures just like the first m5-rc14 porting, not use the rc15. I expect getting something new, but again it just shows me the same error.

m5-rc14 porting

m5-rc14 porting, steps are quiet the same with m3. I get strace output file and there are lines which weird for me, i did not see anyone has the same problem i guess. Well, investigation will be the later step. These are the lines:

13:05:22 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0           
13:05:22 write(1, "ERROR:  3885 cannot locate \'_ZN7android17cleanIMemoryFilesEv\'...\n", 65) = 65   
13:05:22 write(1, "ERROR: failed to link /system/bin/runtime\n", 42) = 42                            
13:05:22 write(1, "ERROR: CANNOT LINK EXECUTABLE \'/system/bin/runtime\'\n", 52) = 52                
13:05:22 exit_group(-1)                 = ?

the complete strace log :

13:05:22 open("libdbus.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
13:05:22 open("/system/lib/libdbus.so", O_RDONLY|O_LARGEFILE) = 5
13:05:22 lseek(5, -8, SEEK_END)         = 321552
13:05:22 read(5, "\200\256PRE ", 8) = 8
13:05:22 mmap2(0xae800000, 323584, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xae800000
13:05:22 close(5)                       = 0
13:05:22 mprotect(0xae800000, 319488, PROT_READ|PROT_EXEC) = 0
13:05:22 mprotect(0xad300000, 352256, PROT_READ|PROT_EXEC) = 0
13:05:22 open("libsystem_server.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
13:05:22 open("/system/lib/libsystem_server.so", O_RDONLY|O_LARGEFILE) = 5
13:05:22 lseek(5, -8, SEEK_END)         = 6928
13:05:22 read(5, "\240\251PRE ", 8) = 8
13:05:22 mmap2(0xa9a00000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xa9a00000
13:05:22 close(5)                       = 0
13:05:22 open("libsurfaceflinger.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
13:05:22 open("/system/lib/libsurfaceflinger.so", O_RDONLY|O_LARGEFILE) = 5
13:05:22 lseek(5, -8, SEEK_END)         = 147708
13:05:22 read(5, "\320\254PRE ", 8) = 8
13:05:22 mmap2(0xacd00000, 151552, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xacd00000
13:05:22 close(5)                       = 0
13:05:22 mprotect(0xacd00000, 143360, PROT_READ|PROT_EXEC) = 0
13:05:22 open("libaudioflinger.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
13:05:22 open("/system/lib/libaudioflinger.so", O_RDONLY|O_LARGEFILE) = 5
13:05:22 lseek(5, -8, SEEK_END)         = 100324
13:05:22 read(5, "\253PRE ", 8)   = 8
13:05:22 mmap2(0xab000000, 102400, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xab000000
13:05:22 close(5)                       = 0
13:05:22 fstat64(1, {st_mode=S_IFCHR|0660, st_rdev=makedev(5, 1), ...}) = 0
13:05:22 brk(0)                         = 0x14000
13:05:22 brk(0x14000)                   = 0x14000
13:05:22 brk(0x15000)                   = 0x15000
13:05:22 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
13:05:22 write(1, "ERROR:  3885 cannot locate \'_ZN7android17cleanIMemoryFilesEv\'...\n", 65) = 65
13:05:22 write(1, "ERROR: failed to link /system/bin/runtime\n", 42) = 42
13:05:22 write(1, "ERROR: CANNOT LINK EXECUTABLE \'/system/bin/runtime\'\n", 52) = 52
13:05:22 exit_group(-1)

Touchscreen driver, what’s wrong

After digging some more days, i still get nothing related to touchscreen driver with android. What actually wrong ? Touchscreen driver which is mxc_ts.c reads input and parsing it into subsystem. When i try ts_test and ts_calibrate, it seems works properly, it reads correct input and TSLIB passes the input subsystem, then i can see moving cursor on LCD as well. There is no flickering also when xterm running. But, flickering appears very hard when android runs, and also, touchscreen does not work.

So, android seems to be wrong to read input subsystem or has different way to read it. Well, is this gonna be framebuffer related ? technically, i just did not review it. I get response from mail list, said :

This depends.

If you have Android output on the display, e.g. you get Android home screen etc., and just can’t use ts input, it is ts/input related. And *not* “double buffering” related. If “double buffer” doesn’t work, you wouldn’t get anything on the screen.

But if you don’t get anything on the screen (just a blank screen), this is “double buffer” related.

So. i make myself sure, that’s not framebuffer related!!

Well, mxc_ts.c works this way :

* The touchscreen driver is designed as a standard input driver which is a
* wrapper over low level PMIC driver. Most of the hardware configuration and
* touchscreen functionality is implemented in the low level PMIC driver. During
* initialization, this driver creates a kernel thread. This thread then calls
* PMIC driver to obtain touchscreen values continously. These values are then
* passed to the input susbsystem.

which is :

 pmic_adc_get_touch_sample(&ts_sample, !wait);

and let’s take a look into : include/asm/arch/pmic_adc.h

PMIC_STATUS pmic_adc_get_touch_sample(t_touch_screen * ts_value, int wait);

the values returned then passes into subsystem:

input_report_abs(mxc_inputdev, ABS_X, ts_sample.x_position);
input_report_abs(mxc_inputdev, ABS_Y, ts_sample.y_position);
input_report_abs(mxc_inputdev, ABS_PRESSURE,
ts_sample.contact_resistance);
input_sync(mxc_inputdev);
wait = ts_sample.contact_resistance;
msleep(20);

finished! So the problem seems to be in, how does android read those fucking inputs subsystem ? i will do some dirty hack, and will post it soon.