Touch Debugging the stop responding to touch problem

[jape]

I decided to see if I could infer anything about the nature of the periodic problem my device has where it stops responding to touch, but still responds to home keypresses, so I wrote a script which would wait for a "long press" on the home key and then dump the results of evtest to a log.

It looks like the fault lies at the device driver layer, or the hardware itself, since evtest doesn't echo any touch events after the problem occurs. This suggests to me that this means that the problem is not in the reader app.

There's nothing interesting i see in dmesg, so unless someone has any other debugging ideas I'm stuck.

The script is below, in case it is useful to someone :

[root@kobo init.d]# cat watch-button.sh
#!/bin/sh

HOME_BUTTON=0066
BUTTON_PRESS=0001
BUTTON_RELEASE=0000

while [ true ]
do
    # read 16 bytes off the "keyboard" (one event)
    result=`od -x -N 16 /dev/input/event0`
    event=`echo $result | awk '{print $7}'`
    button=`echo $result | awk '{print $8}'`

    if [ $event == $HOME_BUTTON ]
    then
        if [ $button == $BUTTON_PRESS ]
        then
             button_down_time=`date +%s`
             echo "Home button pressed at $button_down_time"
        else
            if [ $button == $BUTTON_RELEASE ]
            then
               now=`date +%s`
               echo "Home button released $now"
               delta=`expr $now - $button_down_time`
               echo "delta is $delta"
               if [ $delta -gt 2 ]
               then
                    echo "Long press detected" > /etc/init.d/one.log
                    dmesg > /etc/init.d/two.dmesg
                    evtest /dev/input/event1 >> /etc/init.d/one.log
               fi
            fi
        fi
    fi

done

[Rom1]

I was wondering if using uinput would not help you trigger your problem.
You could inject a sequence of touch events and check if it freezes. If it does, it would be a good result in favor of your hardware.

If you get uinput working properly, I would be interested. I have not yet found a simple way from the shell.
Romain

[taming]

I doubt it is the hardware--only because this is a recent problem with this build. Now, it could be a problem with how the latest iteration of the firmware/software interacts with the hardware.

[John F]

Originally Posted by jape

...

It looks like the fault lies at the device driver layer, or the hardware itself, since evtest doesn't echo any touch events after the problem occurs. This suggests to me that this means that the problem is not in the reader app.

...

I thought there were reports that touch still responded, but only on the "tear drops"?

[Techbar]

Originally Posted by John F

I thought there were reports that touch still responded, but only on the "tear drops"?

When mine freezes there are no "tear drops" so I think there are at least two types of freezing. In my case nothing is highlighted, no part of the screen is touch sensitive but the Home and Power keys still work. Turning the power off and then on allows recovery from the freeze.

[Redsgj]

Originally Posted by jape

It looks like the fault lies at the device driver layer, or the hardware itself

I would have to agree with this. My first Touch would stop responding to touch just about every time I used it (although I was only using it occasionally at the time). I had just bought it a few weeks earlier so I decided to exchange it.

The new one which I have had for a month or more and have used pretty much twice a day has not done it once yet!