Kobo Libra Colour Support

[xtin]

Got a Kobo Libra Colour delivered early. Is this not supported yet? It doesn't seem to be detected by Calibre. Previously had a Kindle Paperwhite and it worked fine.
I can connect by using the "Connect/share" button, however, I can't send .kepub fies that way, and the formatting looks off on the device.
PS: I followed the steps in the sticky post, it was the only device connected, mac os detects it. Wanted to check if it was something on my end or simply not supported yet since it's ahead of launch.

[PeterT]

I think if you install the current preview version of Calibre it should work.

I'd like to know as I supplied kovid with the USB IDs so they could be added but I'm concerned IIN that there might be a few more changes needed for full support.

Sent from my Pixel 7a using Tapatalk

[theducks]

Connect Share??

Aren't you using a USB cable? Kobo Utilities (plugin) has a tick box in the configuration to Support Newer firmware. <have you tried that.

(FWIW I only have plain old Libra2 and Aura2)

[xtin]

Originally Posted by PeterT

I think if you install the current preview version of Calibre it should work.

thanks so much. everything worked perfectly after installing the preview version (7.8.100)

[jackie_w]

Originally Posted by PeterT

I'd like to know as I supplied kovid with the USB IDs so they could be added but I'm concerned IIN that there might be a few more changes needed for full support.

I may be able to help if you need another opinion on what changes are needed for the KOBOTOUCH driver. Feel free to PM me if you want. Caveat: if there are changes required because of a database schema update I may not be the best bet.

[PeterT]

Originally Posted by xtin

thanks so much. everything worked perfectly after installing the preview version (7.8.100)

Could you send me a calibre debug log with the device attached.

Sent from my Pixel 7a using Tapatalk

[PeterT]

Originally Posted by jackie_w

I may be able to help if you need another opinion on what changes are needed for the KOBOTOUCH driver. Feel free to PM me if you want. Caveat: if there are changes required because of a database schema update I may not be the best bet.

I was told that the only required db change was for the db_version value.

Sent from my Pixel 7a using Tapatalk

[PeterT]

Originally Posted by jackie_w

I may be able to help if you need another opinion on what changes are needed for the KOBOTOUCH driver. Feel free to PM me if you want. Caveat: if there are changes required because of a database schema update I may not be the best bet.

One concern I have is that the three new devices all have the same USB device ID; 0x4237. Kovid has added a single entity LIBRA_COLOR_PRODUCT_ID. Now David has a series of helper functions; isTouch / isGlo etc that are used by set_device_name to assign the correct value to device_name. There is no default device_name in this function.

They are also used by cover_file_endings to assign the supported cover types to _cover_file_endings. Luckily there is a default value here

One place that I know does use the device_name value is the Kobo Utilities plugin.

So as far as I can see we either need to use a generic device_name of (say) Kobo Colour Family or hope that by some magic it is possible to distinguish the devices.

Thoughts?

[PeterT]

Originally Posted by PeterT

One concern I have is that the three new devices all have the same USB device ID; 0x4237. Kovid has added a single entity LIBRA_COLOR_PRODUCT_ID. Now David has a series of helper functions; isTouch / isGlo etc that are used by set_device_name to assign the correct value to device_name. There is no default device_name in this function.

They are also used by cover_file_endings to assign the supported cover types to _cover_file_endings. Luckily there is a default value here

One place that I know does use the device_name value is the Kobo Utilities plugin.

So as far as I can see we either need to use a generic device_name of (say) Kobo Colour Family or hope that by some magic it is possible to distinguish the devices.

Thoughts?

I've created a fork and a new branch with changes to reflect all this.

1465c1465
<     LIBRA_COLOR_PRODUCT_ID = [0x4237]
---
>     COLOUR_FAMILY_PRODUCT_ID = [0x4237]
1473c1473
<                           LIBRA_COLOR_PRODUCT_ID
---
>                           COLOUR_FAMILY_PRODUCT_ID
3602a3603,3605
>     def isColourFamily(self):
>         return self.detected_device_idProduct in self.COLOUR_FAMILY_PRODUCT_ID
> 
3693a3697,3700
>         elif self.isColourFamily():
>             device_name = 'Kobo Colour Family'
>         else:
>             device_name = 'Unnamed Kobo Device'

Thoughts?

[kovidgoyal]

Didnt you say one of the devices is a Clara BW, aka not a color device? Also device_name has a default value, it is "Kobo eReader" comes from the first line of set_device_name()

[PeterT]

There also appear to be values defined for min_device_fwversion but luckily those don't appear to be used so not sure there is a need to add this in.

And of course I forgot about supported_dbversion that will probably need to be increade from 174 to 175.

[PeterT]

Originally Posted by kovidgoyal

Didnt you say one of the devices is a Clara BW, aka not a color device? Also device_name has a default value, it is "Kobo eReader" comes from the first line of set_device_name()

OOPS! I missed thar default being set; and wasn't sure what self.gui_name was

And yes; Kobo in their wisdom is using the same ID for all three of the new devices; two Colour (Clara Colour and Libra Colour) and one BW (Clara BW).

[kovidgoyal]

I have changed the device name to "Kobo 2024" to better reflect these models.

[jackie_w]

Originally Posted by PeterT

One concern I have is that the three new devices all have the same USB device ID; 0x4237. Kovid has added a single entity LIBRA_COLOR_PRODUCT_ID. Now David has a series of helper functions; isTouch / isGlo etc that are used by set_device_name to assign the correct value to device_name. There is no default device_name in this function.

They are also used by cover_file_endings to assign the supported cover types to _cover_file_endings. Luckily there is a default value here

One place that I know does use the device_name value is the Kobo Utilities plugin.

So as far as I can see we either need to use a generic device_name of (say) Kobo Colour Family or hope that by some magic it is possible to distinguish the devices.

Thoughts?

Based on the existing KOBOTOUCH driver and the Kobo Utilities plugin, it's clear that David thought it valuable to know exactly which Kobo device was connected.

Early adopters of the 2 colour devices are probably going to care more than most about the appearance of the cover thumbnails, particularly fullsize screensavers, that calibre transfers. So it's important to try and get the _cover_file_endings stuff correct which means being able to distinguish between the fullscreen size of the Libra Colour (1264x1680) and the 2 Claras (1072x1448). IIRC @NiLuJe thought that it was far preferable, for visual quality, to let the calibre driver do as much of the image manipulation work as possible rather than leaving it to the Kobo device itself. It's why he contributed the extra KOBOTOUCH covers code (letterboxing and B&W dithered images/PNG optimisation).

I find it surprising that Kobo don't distinguish between the three 2024 models with a unique PRODUCT_ID for each. It's never happened before, has it? Anyway, we need to try to find our own method, if possible. Is there any possibility that the BCD value (whatever that is) will be different?

Failing that, my first idea was a method I used many years ago for distinguishing between Sony models. The Libra Colour comes with 32Gb storage and the 2 Claras only 16Gb. Perhaps we could use self.gui.device_manager.connected_device.total_spa ce() to decide whether the connected 'Kobo 2024' device is a Libra or a Clara? Just knowing that much would let us send the correct fullsize screensavers.

Another possibility is to examine the contents of .kobo/version file. Can we use the first few chars of the SerialNo to determine the model? There's already functions in Kobo Utils to read and parse .kobo/version, namely action.py device_version_info() and device_serial_no()

Other than that, an automated way to distinguish between ClaraBW/ClaraColour isn't immediately obvious but I don't *think* there's any current Kobo/calibre option which needs to know. Obviously users will want to send colour thumbnails (of all sizes) to a colour device but that decision is already under user control in KOBOTOUCH options.

Maybe once someone who knows what to look for has one of these colour models in their hands we'll see that some extra file or directory is present on colour models and we can use that? If all else fails and there's a compelling need there's always the fallback option of a user manually adding a zero-length, no-file-extension specially named file to the root dir of the Kobo (e.g. is_a_kobo2024_clarabw).

[PeterT]

I've let the Kobo dev team know of the "challenges" that their non unique USB IDs have caused and requested that for future models they use different IDs.

I can't help but wonder if they couldnt fix this in a susequent f/w release, seeing that the USB id is supplied by the udev rule executed on connection. I can't for the klife of me figure out where the environment variable PRODUCT_ID is set!