Determine device firmware version

[mishagale]

TL;DR: Does anyone know how to programmatically obtain the currently installed firmware version on a Kobo?

I've been working on a program which will automatically download books from a calibre content server onto the Kobo. Currently, my method for forcing the device to add the downloaded books to its library is to fake a USB plug in event, fake a tap on the "Connect" button, and then fake a USB unplug. This works fine on my device, but the problem is that I need the screen co-ordinates of the connect button.

The location of the button is fairly predictable, but the UI has changed once or twice, so it might be in different places on different firmwares, and of course it will depend on the screen resolution, which I think varies with the actual model.

So my questions are basically

1. Is there actually a better method of forcing a the device to re-index the content on the SD card?
2. Is there a way to determine the device's firmware version?
3. Is there a way to determine what model the device is? (WiFi, Glo, Mini, etc..)
4. Does anyone know which firmwares changed the layout of the USB connection dialog?

[jackie_w]

Originally Posted by mishagale

[*]Is there a way to determine the device's firmware version?

I'm afraid I can't help with most of your questions, but the current firmware version seems to be part of the one-line text file, .kobo/version, on each device.

[frostschutz]

You could just ask the user to do it manually once (and record and remember and replay that touch event). Basically just read the touchscreen input event between faking the USB connect and unplug (assuming the user will tap connect when nothing happens) and write it back to it next time.

[mishagale]

Originally Posted by jackie_w

I'm afraid I can't help with most of your questions, but the current firmware version seems to be part of the one-line text file, .kobo/version, on each device.

Thanks! I knew I'd seen a file like that somewhere, but I couldn't find it, probably because I was looking on / instead of on the SD card.

Looks like the comma-separated fields break down into serial number (which starts with the model number), kernel version, firmware version, kernel version again, kernel version yet again, and then something I'm not certain, maybe a different representation of the firmware version? No idea why the kernel version is repeated three times, but looks like there's enough info there to identify model and firmware version.

Originally Posted by frostschutz

You could just ask the user to do it manually once (and record and remember and replay that touch event). Basically just read the touchscreen input event between faking the USB connect and unplug (assuming the user will tap connect when nothing happens) and write it back to it next time.

That's a method I will fall back on, but I'd like to be as user-friendly as possible, and not require any user input at all.

[frostschutz]

Originally Posted by mishagale

That's a method I will fall back on, but I'd like to be as user-friendly as possible, and not require any user input at all.

It would be a one-time action... seems pretty userfriendly to me. Better than blindly guessing and getting it wrong in any case. The button positions may also be different depending on the language setting.

[davidfor]

Originally Posted by mishagale

Thanks! I knew I'd seen a file like that somewhere, but I couldn't find it, probably because I was looking on / instead of on the SD card.

Looks like the comma-separated fields break down into serial number (which starts with the model number), kernel version, firmware version, kernel version again, kernel version yet again, and then something I'm not certain, maybe a different representation of the firmware version? No idea why the kernel version is repeated three times, but looks like there's enough info there to identify model and firmware version.

The last value in the file is the model identifier. That is safer than using the serial number. From memory, for the older Touch's, the serial number doesn't start with the model number. There has been a list of these identifiers posted in the past, but it won't include the latest models.

[mishagale]

Originally Posted by frostschutz

It would be a one-time action... seems pretty userfriendly to me. Better than blindly guessing and getting it wrong in any case. The button positions may also be different depending on the language setting.

You may be interested to know that I eventually decided to do it your way and record the user's manual tap. I still regard it as an interim solution though, and eventually I would like to have a way to do this without any user interaction at all (though of course what I'd *really* like is a way to trigger a library update that doesn't involve faking USB connections and screen taps.)

[Ken Maltby]

Maybe you could check out Tshering's scripting for that feature of his Kobo Start Menu (KSM)? (I mean the simulation of USB connect and disconnect, to have Kobo processing initiated.)

Luck;
Ken

[mishagale]

Originally Posted by Ken Maltby

Maybe you could check out Tshering's scripting for that feature of his Kobo Start Menu (KSM)? (I mean the simulation of USB connect and disconnect, to have Kobo processing initiated.)

Luck;
Ken

That is essentially the method I use (except implemented in C rather than shell-scripting) - however, tshering's method still requires the user to tap the "Connect" button, as far as I can make out. I don't actually run KSM, so maybe there is a feature I am unaware of that doesn't require user interaction?

[Ken Maltby]

Originally Posted by mishagale

That is essentially the method I use (except implemented in C rather than shell-scripting) - however, tshering's method still requires the user to tap the "Connect" button, as far as I can make out. I don't actually run KSM, so maybe there is a feature I am unaware of that doesn't require user interaction?

It is implemented using a fmon .png, I don't remember it requiring any user interaction, besides selecting the .png. The .png is listed in the library, after a proper install of KSM.

It won't hurt anything to install KSM7, the stock software is unaffected.

Luck;
Ken

[frostschutz]

Originally Posted by mishagale

You may be interested to know that I eventually decided to do it your way and record the user's manual tap.

Great. I don't think there is a better solution, for now. Unless you know how to patch / ld_preload nickel to convince it to do it another way. Even updating the database directly [if you knew how], it doesn't work, as nickel ignores it until reboot or, until usb connect as it were. Since nickel believes to be the exclusive user of the database, it does not revalidate caches etc.