Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 1 day, 10 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 2 days, 10 hrs ago - more...
| The Following User Says Thank You to juiceme For This Useful Post: | ||
|
2012-10-30
, 16:50
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#32
|
Now I had time to actually debug your preinit script.
What I did, is I splitted the multiboot() section out from your file, edited the paths a bit and then run that script on single user mode from console to see how it behaves. (this is the best way to debug these things, as then normal Harmattan UI does not get in the way of debugging)
I found out that you do have some issues about it, it looks like there is something that causes the script to output a lot of error messages to console and it (just as you stated in your post) does not react to touches but rather calls the evtap command repeatedly before breaking out of the loop.
Maybe if you could explain why you wrote the script that way, and what kind of behaviour you expect from it I can help you to write a better script.
What I did, is I splitted the multiboot() section out from your file, edited the paths a bit and then run that script on single user mode from console to see how it behaves. (this is the best way to debug these things, as then normal Harmattan UI does not get in the way of debugging)
I found out that you do have some issues about it, it looks like there is something that causes the script to output a lot of error messages to console and it (just as you stated in your post) does not react to touches but rather calls the evtap command repeatedly before breaking out of the loop.
Maybe if you could explain why you wrote the script that way, and what kind of behaviour you expect from it I can help you to write a better script.
| The Following User Says Thank You to juiceme For This Useful Post: | ||
|
|
2012-10-31
, 21:33
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#33
|
Ouch. You've changed some parameters... Well it least now I have my Rescue 9 CD for editing files on a dead phone 
.
So anyway why did you remove -n parameter and strtoul when writting to ml->c? Isn't that supposed to be a character? Is this a bug or was this intentional? I can't get current evtap to output a character nor an area number. Or am I just compiling this wrong (I'm using scratchbox with armel target)?
.So anyway why did you remove -n parameter and strtoul when writting to ml->c? Isn't that supposed to be a character? Is this a bug or was this intentional? I can't get current evtap to output a character nor an area number. Or am I just compiling this wrong (I'm using scratchbox with armel target)?
|
|
2012-11-02
, 07:24
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#34
|
Ah, I am so sorry!
I should have told you to check the format of the map file when you update the evtap to newest version.
My sincierest apologies!
There is a good reason for the change, as the old version worked on the assumption that if you want to output a character (like in the virtual keyboard example that I use to input passphrase) the map file has the character symbol.
However, I changed that to ascii value instead of ascii charcter becuse of handling non-printing characters.
I should have told you to check the format of the map file when you update the evtap to newest version.
My sincierest apologies!
There is a good reason for the change, as the old version worked on the assumption that if you want to output a character (like in the virtual keyboard example that I use to input passphrase) the map file has the character symbol.
However, I changed that to ascii value instead of ascii charcter becuse of handling non-printing characters.
|
|
2012-11-02
, 07:55
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#35
|
You propably are compiling it correctly, else it would not run at all in the target device.
What you need to note, is that because evtap needs to return 2 values at the same time, it is returning the character value as the "printout character" and the numeric value as the "return code".
Hence you need to call it like this in your script:
Now to get the character value in $tap and the numeric value in $ret and you can decide in your code which to use. If a timeout occurs then $ret equals 255 (that's in shell variables, it's -1 in code)
See the example script "sillykbd" in the repository. In that file you can see how two different keyboard layouts are used, changeable with the shift key. The return values are used to differentiate between "character printing keys" and control keys like shifts, backpace, OK, CANCEL etc...
What you need to note, is that because evtap needs to return 2 values at the same time, it is returning the character value as the "printout character" and the numeric value as the "return code".
Hence you need to call it like this in your script:
Code:
tap=$(evtap -t $touchdevice -m $mapfile -d $timeout -c) ret=$?
See the example script "sillykbd" in the repository. In that file you can see how two different keyboard layouts are used, changeable with the shift key. The return values are used to differentiate between "character printing keys" and control keys like shifts, backpace, OK, CANCEL etc...
|
|
2012-11-02
, 17:44
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#36
|
No problem. Since then I brick my phone about once a day :-). BTW Debian with Gnome works quite good with N9 rescue image (it automatically mount rootfs and unmounts everything when you eject either).
Here is a version that on -c returns the character and on -a return ascii number:
http://m.enux.pl/_n9/boot/evtap.c
if you'd like to check md5 is: 14f5417981bb9e327a8d6a261c197284
Anyway I found out that I cannot use your script as I planned. I'm not even sure if it is doable just by reading from this touch device. As seems the touch device does not output anything if you just keep your finger on the screen (long tap). It only starts to output anything once there is some movement and only output a meaningful value for coordinates that change.
I've tested with a simple bash script (works when played e.g. from Putty after being logged in):
So if you hold your phone in portrait view you get the following (with 0:0 in bottom right corner).
It outputs y:x on-touch (meaning once).
It outputs timeout if you will not move your finger.
it outputs y:0 if you move your finger up or down.
it outputs 0:x if you move your finger left or right.
it outputs y:x again if you move on both axis.
In landscape view x and y is exchanged with 0:0 in top left corner. It seems that on pre-init you are stuck in portrait view, but I guess you know that one already.
Here is a version that on -c returns the character and on -a return ascii number:
http://m.enux.pl/_n9/boot/evtap.c
if you'd like to check md5 is: 14f5417981bb9e327a8d6a261c197284
Anyway I found out that I cannot use your script as I planned. I'm not even sure if it is doable just by reading from this touch device. As seems the touch device does not output anything if you just keep your finger on the screen (long tap). It only starts to output anything once there is some movement and only output a meaningful value for coordinates that change.
I've tested with a simple bash script (works when played e.g. from Putty after being logged in):
Code:
while [ true ] do selection=$(/bin/evtap -t /dev/input/"$touch" -m /usr/share/multiboot/touch.map -d "$touchDelay" -xy) echo "xy: $selection" done
It outputs y:x on-touch (meaning once).
It outputs timeout if you will not move your finger.
it outputs y:0 if you move your finger up or down.
it outputs 0:x if you move your finger left or right.
it outputs y:x again if you move on both axis.
In landscape view x and y is exchanged with 0:0 in top left corner. It seems that on pre-init you are stuck in portrait view, but I guess you know that one already.
| The Following User Says Thank You to eccenux For This Useful Post: | ||
|
|
2012-11-02
, 21:48
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#38
|
Yes, you can get touch_on /touch_off effects from the device.
I intentionally filter out such things, like doing "key-debounce" because what I want to do is get single keypresses for virtual keyboard.
Now I am beginning to understand what you want, in your application you want to get different result for long press?
I intentionally filter out such things, like doing "key-debounce" because what I want to do is get single keypresses for virtual keyboard.
Now I am beginning to understand what you want, in your application you want to get different result for long press?
|
|
2012-11-02
, 22:10
|
|
Community Council |
Posts: 4,920 |
Thanked: 12,867 times |
Joined on May 2012
@ Southerrn Finland
|
#39
|
You could experiment with this attached code, to see what kind of codes you are going to get. All the input devices return the same kind of data, "struct input_event", whether it be touchscreen, accelerometer or whatever
The important header file here, "/usr/include/linux/input.h" contains the constants that are returned in type and code fields of the input_event.
---------- edit ----------
OK, so I played with it again just for the fun of it. For example, every time I set finger on the TS I get nine input events something like this;
And every time I lift up finger, I get eight events like this;
The input_event "1, 330, 1" means "EV_KEY, BTN_TOUCH, DOWN", it is the touchdown event.
The input_event "1, 330, 0" means "EV_KEY, BTN_TOUCH, UP", it is the touchup event.
Last edited by juiceme; 2012-11-02 at 22:47. Reason: added more of the same...
The important header file here, "/usr/include/linux/input.h" contains the constants that are returned in type and code fields of the input_event.
Code:
int main(int argc, char *argv[])
{
struct input_event ievent;
int fdev, xaxis, yaxis, flag, ret;
if ((fdev = open("/dev/input/ts", O_RDONLY)) < 0) {
perror("cannot open input device");
return -1;
}
while(1) {
if((ret = read(fdev ,&ievent ,sizeof(ievent))) < sizeof(ievent)) {
printf("\nreceived only %d bytes on read", ret);
return -1;
}
printf("\n%d,\t%d,\t%d", ievent.type, ievent.code, ievent.value);
}
return 0;
}
OK, so I played with it again just for the fun of it. For example, every time I set finger on the TS I get nine input events something like this;
Code:
0, 0, 0 1, 330, 1 3, 0, 657 3, 1, 327 3, 53, 657 3, 54, 327 3, 48, 22 3, 57, 0 0, 2, 0
Code:
0, 0, 0 3, 53, 657 3, 54, 327 3, 48, 38 3, 57, 0 0, 2, 0 0, 0, 0 1, 330, 0
The input_event "1, 330, 0" means "EV_KEY, BTN_TOUCH, UP", it is the touchup event.
Last edited by juiceme; 2012-11-02 at 22:47. Reason: added more of the same...
|
|
2012-11-03
, 12:15
|
|
Posts: 52 |
Thanked: 33 times |
Joined on Oct 2011
@ Poland, Tricity
|
#40
|
So here it is - new ultimate touch utility 
(attached .tar, md5: 69da8c70b1d7da6aaacb849081042a55).
It works perfectly if run when MeeGo is fully loaded. In pre-init the device seems a bit less reliable (it sometimes sends touch end or "forgets" to send touch start), but its workable. It seems it would work best if I would send some feedback while listing on the device, not returning to bash. That is always wait for touch-end.
Note that I tried to keep backward compatibility as much as I can. I dropped polling - it seemed to have waited longer then the actual timeout (probably because it was in a loop, but I don't feel how poll really works). Maybe you can tweak it a bit more.
BTW. Based on the info from the header file you mentioned I've made a debug function (it helped a lot to observe how the touch device works). Maybe you could use it to make some sens of vibration events? I've also seen some info in the mention header file that you first should upload an effect and then play it. Haven't had time to tried that, though.
(attached .tar, md5: 69da8c70b1d7da6aaacb849081042a55).It works perfectly if run when MeeGo is fully loaded. In pre-init the device seems a bit less reliable (it sometimes sends touch end or "forgets" to send touch start), but its workable. It seems it would work best if I would send some feedback while listing on the device, not returning to bash. That is always wait for touch-end.
Note that I tried to keep backward compatibility as much as I can. I dropped polling - it seemed to have waited longer then the actual timeout (probably because it was in a loop, but I don't feel how poll really works). Maybe you can tweak it a bit more.
BTW. Based on the info from the header file you mentioned I've made a debug function (it helped a lot to observe how the touch device works). Maybe you could use it to make some sens of vibration events? I've also seen some info in the mention header file that you first should upload an effect and then play it. Haven't had time to tried that, though.
| The Following User Says Thank You to eccenux For This Useful Post: | ||
At first look I see that you do not have the latest evtap version, I made some changes to it that are not relevant in this case but I recommend using the latest
It might be that there is something wrong with the timeout polling code in evtap, if it behaves in the manner you describe. I see from your preinit script that you use it in one instance having timeout of 1000 ms, so I imagine that it might go so that the code does not continue until the 1s timeout is expired?
However I have tested evtap with different timeouts myself and it should return immediately after a registered screentap even when using long timeouts.