sh_ivtool: a simple UI application for use in scripts - Page 6

rkomar · 12-07-2023, 09:57 AM

It sounds like they left some debugging statement in their keyboard code that writes to standard output. Until they fix that, it looks like some kind of workaround will be required. Thanks for pointing this out and sharing your solution.

neil_swann80 · 03-17-2024, 05:28 AM

Quote:

Originally Posted by rkomar

It sounds like they left some debugging statement in their keyboard code that writes to standard output. Until they fix that, it looks like some kind of workaround will be required. Thanks for pointing this out and sharing your solution.

Do you think there's a way of clearing stdout between calling the keyboard function (which I assume generates the debugging statement) and writing what is captured by it?

rkomar · 03-17-2024, 10:04 AM

You can try closing descriptor '1' after the call to dup(), to see if that stops the pocketbook keyboard code from writing to standard output. You might also try adding "fflush(stdout);" to the beginning of the char_handler() function in case the keyboard code is writing to the stdout file stream. I'm not sure if either will work, but you might get lucky.

neil_swann80 · 03-17-2024, 12:06 PM

Quote:

Originally Posted by rkomar

You can try closing descriptor '1' after the call to dup(), to see if that stops the pocketbook keyboard code from writing to standard output. You might also try adding "fflush(stdout);" to the beginning of the char_handler() function in case the keyboard code is writing to the stdout file stream. I'm not sure if either will work, but you might get lucky.

You legend!

Adding "fflush(stdout);" actually increased the amount of unneeded text, but closing descriptor '1' did it!

rkomar · 03-17-2024, 12:39 PM

Nice! I should probably add that to the official version. The problem is I don't remember exactly why I needed to call dup() in the first place (something to do with the version built to run on the emulator). I suspect it would bust that again, so maybe I can #ifdef it to work with either situation.

rkomar · 03-17-2024, 12:47 PM

By the way, did you (@neil_swann80) create cmake files to build sh_ivtool? If so, I can add them to the official source package if you don't mind donating them. It would make it easier for others to build their own versions.

neil_swann80 · 03-17-2024, 12:56 PM

Now to busy myself removing my clumsy workarounds from the many scripts that use sh_ivtool!

Quote:

Originally Posted by rkomar

By the way, did you (@neil_swann80) create cmake files to build sh_ivtool? If so, I can add them to the official source package if you don't mind donating them. It would make it easier for others to build their own versions.

Yeah, sure. I've attached my modified main.c and CMakeLists.txt file needed to build.
Let me know if you're happy for me to upload the compiled binary in the interim before you update the official.

rkomar · 03-17-2024, 01:27 PM

I like to keep the sources buildable on all of the supported platforms, so I don't want to just delete the functionality that disappeared in newer firmwares. It will take some time to figure out how to do that. In the meantime, you can attach your version in a message. There isn't a lot of traffic here, so it should be visible to anyone who comes in the near future.

neil_swann80 · 03-17-2024, 01:47 PM

My CMakeLists.txt will still work with your original source. I guess it would need to reference an older SDK (and inkview.h) that still contains the functions now missing in the newer firmware.

I've attached my compiled version of sh_ivtool which should work on fw6+ and no longer has the output bug.

neil_swann80 · 04-19-2025, 06:48 AM

@rkomar
Apologies for the sporadic interruptions fella...

Do you know if I can make the background for sh_ivtool transparent?

I can achieve a transparent background for the system dialog by manually setting the active task before calling it, e.g.

Code:

#!/bin/sh
dialog=/ebrmain/cramfs/bin/dialog
$dialog 1 "" "test 1"
iv2sh SetActiveTask `pidof bookshelf.app`
$dialog 1 "" "test 2"
iv2sh SetActiveTask $$
/ebrmain/bin/run_script -clear_screen -bitmap=pocketbook_logo_software
$dialog 1 "" "test 3"
iv2sh SetActiveTask `pidof bookshelf.app`
exit

Currently sh_ivtool always behaves like the dialog for "test 1" and I'd love to get it working as an overlay like in tests 2 & 3.

I may also try and get sh_ivtool to respect dark-mode, I think I just need to add:

Code:

IvSetAppCapability(APP_CAPABILITY_SUPPORT_SCREEN_INVERSION);

rkomar · 04-19-2025, 11:20 AM

There is a set_active_task() function that calls SetActiveTask (via the *sat function pointer). I added it way back because the dialog stopped being displayed for some firmware versions without it. You can try messing with that in your version. There are two arguments to the function: task and subtask, and I have no idea what the second is for. I set "task" to the return value from GetCurrentTask(), but maybe you can set the arguments to something else to achieve what you want.

The behaviour sounds very firmware-dependent, and may change at any time. It doesn't sound like something you can count on over a range of devices and firmware versions.

04-19-2025, 06:48 AM	#85
neil_swann80 0000000000101010 Posts: 5,906 Karma: 12983233 Join Date: Mar 2023 Location: An island off the coast of Ireland Device: PB632 [HD3]	@rkomar Apologies for the sporadic interruptions fella... Do you know if I can make the background for sh_ivtool transparent? I can achieve a transparent background for the system dialog by manually setting the active task before calling it, e.g. Code: #!/bin/sh dialog=/ebrmain/cramfs/bin/dialog $dialog 1 "" "test 1" iv2sh SetActiveTask `pidof bookshelf.app` $dialog 1 "" "test 2" iv2sh SetActiveTask $$ /ebrmain/bin/run_script -clear_screen -bitmap=pocketbook_logo_software $dialog 1 "" "test 3" iv2sh SetActiveTask `pidof bookshelf.app` exit Currently sh_ivtool always behaves like the dialog for "test 1" and I'd love to get it working as an overlay like in tests 2 & 3. I may also try and get sh_ivtool to respect dark-mode, I think I just need to add: Code: IvSetAppCapability(APP_CAPABILITY_SUPPORT_SCREEN_INVERSION);

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Trio of Picture Books - Simple Animals, Simple Shapes, and You're My Baby!	Manley Peterson	Self-Promotions by Authors and Publishers	5	01-06-2012 08:55 PM
Application update: application not installed error	Merischino	Amazon Fire	4	12-01-2011 10:30 PM
erm, simple question , hope for simple answer!	al zymers	Amazon Kindle	5	09-25-2010 01:01 PM
Simple question for a simple mind :)	PKFFW	OpenInkpot	6	08-27-2009 09:00 PM
Television scripts for your handheld	Bob Russell	Lounge	2	01-07-2006 06:22 PM

12-07-2023, 09:57 AM	#76
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	It sounds like they left some debugging statement in their keyboard code that writes to standard output. Until they fix that, it looks like some kind of workaround will be required. Thanks for pointing this out and sharing your solution.

03-17-2024, 10:04 AM	#78
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	You can try closing descriptor '1' after the call to dup(), to see if that stops the pocketbook keyboard code from writing to standard output. You might also try adding "fflush(stdout);" to the beginning of the char_handler() function in case the keyboard code is writing to the stdout file stream. I'm not sure if either will work, but you might get lucky.

03-17-2024, 12:39 PM	#80
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	Nice! I should probably add that to the official version. The problem is I don't remember exactly why I needed to call dup() in the first place (something to do with the version built to run on the emulator). I suspect it would bust that again, so maybe I can #ifdef it to work with either situation.

03-17-2024, 12:47 PM	#81
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	By the way, did you (@neil_swann80) create cmake files to build sh_ivtool? If so, I can add them to the official source package if you don't mind donating them. It would make it easier for others to build their own versions.

03-17-2024, 01:27 PM	#83
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	I like to keep the sources buildable on all of the supported platforms, so I don't want to just delete the functionality that disappeared in newer firmwares. It will take some time to figure out how to do that. In the meantime, you can attach your version in a message. There isn't a lot of traffic here, so it should be visible to anyone who comes in the near future.

04-19-2025, 11:20 AM	#86
rkomar Wizard Posts: 3,067 Karma: 18821071 Join Date: Oct 2010 Location: Sudbury, ON, Canada Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633	There is a set_active_task() function that calls SetActiveTask (via the *sat function pointer). I added it way back because the dialog stopped being displayed for some firmware versions without it. You can try messing with that in your version. There are two arguments to the function: task and subtask, and I have no idea what the second is for. I set "task" to the return value from GetCurrentTask(), but maybe you can set the arguments to something else to achieve what you want. The behaviour sounds very firmware-dependent, and may change at any time. It doesn't sound like something you can count on over a range of devices and firmware versions.

Advert

Advert