MobileRead Forums - View Single Post

geekmaster · 04-23-2016, 03:37 PM

I finally got my update*.bin install.sh script to execute another script (/mnt/us/RUNME.sh). The key was that after seeing how all the amazon/lab126 scripts installed on my K1 habitually used full absolute paths on everything (data files, executables, scripts, everything) and wondering why, I stumbled across a comment in a script saying to use full absolute paths because "relative paths are unreliable". Well, aparently so, even when I can see the file in the current working directory with "ls -lash" and it tests TRUE with [ -f file ], but yet I was unable to execute or source it.

I changed my code to use a full absolute path to the RUNME.sh file in my current working directory, and it executed just fine (displaying its news on the eink display). Yay! One more step forward! I suspect that I can source files this way too (but using '. </path/file>' instead of 'source </path/file>').

I now have an Update*.bin that does nothing but execute /mnt/us/RUNME.sh if it exists. This could launch an interactive menu, once I figure out the keyboard codes.

So far, I have not found a proc or other way to interact with the keyboard directly (no /dev/input/event devices and no obvious /proc interfaces). The K1 does have a "waitforkey" command, but it does NOT wait for just any key and return its keycode. Instead you must supply the keycode you want to wait for, and it waits for only that key. Which means you cannot easily use it to discover keycodes in a while loop, where you just echo the returned keycode.

I am considering a way to leverage the only way I know to determine a pressed key, by "bending" this limited "waitforkey" command. I plan to launch a bunch of background "waitforkey" commands, one with each possible keycode, followed by an echo of that (input) keycode into a temp file. I can monitor that temp file in the foreground, displaying whatever was last put into it by one of the background "waitforkey" processes. Then I can press all the keys and discover their keycodes. No, I did not find the keycodes in the GPL source, nor in any of the scripts (except for the "R" key, as used in u-boot).

With the limited knowledge I have discovered, can any of y'all think of a better simpler way to discover K1 keycodes? I am all ears (or all thumbs, as the case may be).

04-23-2016, 03:37 PM	#7
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773668 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	I finally got my update.bin install.sh script to execute another script (/mnt/us/RUNME.sh). The key was that after seeing how all the amazon/lab126 scripts installed on my K1 habitually used full absolute paths on everything (data files, executables, scripts, everything) and wondering why, I stumbled across a comment in a script saying to use full absolute paths because "relative paths are unreliable". Well, aparently so, even when I can see the file in the current working directory with "ls -lash" and it tests TRUE with [ -f file ], but yet I was unable to execute or source it. I changed my code to use a full absolute path to the RUNME.sh file in my current working directory, and it executed just fine (displaying its news on the eink display). Yay! One more step forward! I suspect that I can source files this way too (but using '. </path/file>' instead of 'source </path/file>'). I now have an Update.bin that does nothing but execute /mnt/us/RUNME.sh if it exists. This could launch an interactive menu, once I figure out the keyboard codes. So far, I have not found a proc or other way to interact with the keyboard directly (no /dev/input/event devices and no obvious /proc interfaces). The K1 does have a "waitforkey" command, but it does NOT wait for just any key and return its keycode. Instead you must supply the keycode you want to wait for, and it waits for only that key. Which means you cannot easily use it to discover keycodes in a while loop, where you just echo the returned keycode. I am considering a way to leverage the only way I know to determine a pressed key, by "bending" this limited "waitforkey" command. I plan to launch a bunch of background "waitforkey" commands, one with each possible keycode, followed by an echo of that (input) keycode into a temp file. I can monitor that temp file in the foreground, displaying whatever was last put into it by one of the background "waitforkey" processes. Then I can press all the keys and discover their keycodes. No, I did not find the keycodes in the GPL source, nor in any of the scripts (except for the "R" key, as used in u-boot). With the limited knowledge I have discovered, can any of y'all think of a better simpler way to discover K1 keycodes? I am all ears (or all thumbs, as the case may be). Last edited by geekmaster; 04-23-2016 at 04:21 PM.