[knc1]

Originally Posted by geekmaster

I am currently getting the path to the zforce events this way:

T=$(for i in /dev/input/event*;do evtest info $i|grep zforce>/dev/null&&echo $i&&break;done)


If I change it to use your suggestion, it makes the command line longer, but no longer requires calling the built-in evtest program:

T=$(for i in /sys/class/input/event*;do grep zforce $i/device/name>/dev/null&&echo $i&&break;done)

I do not think that loop will do what you expect it to.
Reads like a discovery process to me.

Originally Posted by geekmaster

I then use it like this:

script -c "hexdump $T" /dev/null | while...

The script command forces unbuffered STDOUT so I can sense touches immediately instead of waiting for enough extra touch data to trigger a full buffer. It is annoying to need to press an onscreen keyboard button multiple times to get any action, then have those multiple touches come out in a batch.

The complication is things in a piped while loop run in a separate process, and when my "Exit" button is touched in the inner do loop, an "exit" or "return" command only acts like a break, exiting only to the done. Setting DONE=1 to break the while (while [[ $DONE -ne 1 ]]; do) still waits for more output from hexdump before checking the flag, and you need to touch the screen to create that output. So I ended up doing the "self-terminating script" thing, by parsing "ps a" and killing the first "hexdump $T" process. If you kill the "script -c" your terminal goes bonkers, but it dies cleanly by killing its child process.

Answer:
Do not use a "piped while loop".

Originally Posted by geekmaster

My "solution" may be crude but it will work until I find something better.

In my previous incarnation of my "onscreen keyboard" program, I just grabbed 64 bytes of touch event data (minimum guaranteed size), but that was (infrequently) missing the Y coordinate if a "sync" packet got squeezed in there, resulting in a lost keypress.

Now I do all processing inside the inner subprocess loop, but I wanted to exit without needed two touches, and hence the "ps kill" hack.

Yeah, what you describe is certainly a dirty way to solve the problem you have.
When you find yourself doing something like that, take a break and re-think your solution.

Originally Posted by geekmaster

Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.

You must have seen the names you where interested in, otherwise why did you try to poll them in a script?

Originally Posted by knc1

1) The topic was changing device names.
I only addressed the topic.

2) I never received the copy of your code, nor the link to where you have your work-in-progress posted in a public repository.
So how am I expected to fix your coding errors?

3) I do not set the priorities of how you schedule your own time.
You get to do that yourself, I refuse to be responsible for the result of your own choices.

4)

Originally Posted by geekmaster

WTF? This thread was to provide others a warning that we cannot make assumptions about input device file names like past code did.

And the separately sub-titled, response was a confimation that names in the /dev sub-tree are dynamic and that the names in the /sys sub-tree are fixed.

Originally Posted by geekmaster

I do not have code bugs that I want you to solve, nor do I want you to manage my time (just don't waste it with dead-end suggestions). This thread is about how diags uses different device names than main uses, and the paths you and ixtab suggest that I use do not even exist in diags. I spend a lot of time checking my facts before I post them, and you should too. You need to chill, dude! Go read a book or something...

While I am off reading that book, I think you need to re-read what you posted, as noted above.