Calibre can't detect Nexus One

[kovidgoyal]

remove the encoding declaration (line that has coding in it) from the top of the py file.

[tonyx3]

Well that was a rookie mistake. My bad.

Ok, so now it's adding it, but it doesn't seem to be subclassing any of the data. It adds it as the base USBMS driver. Here's the output:

tony@tony:~/Desktop$ calibre-customize -a myandroiddriver.zip
Plugin added: USBMS Base Device Interface (1, 0, 0)
tony@tony:~/Desktop$

tony@tony:~$ calibre-customize -l
Type           Name                Version        Disabled       Site Customization

Device InterfaceUSBMS Base Device Interface(1, 0, 0)      False          
	Communicate with an eBook reader.
	Configure Device

It's like it's stopping at the 'import USBMS' line, and not going any further.

The modified driver file is literally just the Android 'driver.py' from the source package, modified with my BCD (0x226 instead of 0x0100). Although I also changed the class from ANDROID to ANDROID2 because I thought maybe it was conflicting there, but it didn't help.

[kovidgoyal]

Small bug in the USBMS base class, will be fixed in the next release.

[tonyx3]

Cool, thanks. I ended up switching to a development environment so I could just tweak the .py directly, and it's working great now.

Also, while looking around at the code I noticed this comment in 'interface.py'

# BCD can be either None to not distinguish between devices based on BCD, or
# it can be a list of the BCD numbers of all devices supported by this driver.
    BCD         = None

So I tried to just set it to 'None' in the android driver, and it didn't work at all. Am I misreading this comment, or is this even possible?


Thanks!

[kovidgoyal]

It's possible in general, but IIRC not for the android driver, which has various special semantics.

Incidentally, I've added your BCD to trunk.

[tonyx3]

Yeah, I noticed the new BCD there when I updated my copy of the source. Thanks.

Too bad about the Android driver, then. My python skills aren't up to tracing it back to see where the issue starts...

[tonyx3]

Ok, so i got it to detect based only on VENDOR_ID and PRODUCT_ID, without BCD, but I had to convert the driver from using the 'dictionary of dictionaries' approach, to using the fields separately, the way the HanlinV3 driver does, for example.

I just left the BCD out completely, so it reverts to the 'None' value, inherited from interface.py.

So I changed from the old version:

VENDOR_ID   = {
            0x0bb4 : { 0x0c02 : [0x100], 0x0c01 : [0x100]},
            0x22b8 : { 0x41d9 : [0x216]},
            0x18d1 : { 0x4e11 : [0x0100], 0x4e12: [0x0100,0x226]},
            0x04e8 : { 0x681d : [0x0222]},
            }

To this method:

VENDOR_ID   = [0x0bb4, 0x22b8, 0x18d1, 0x04e8]
PRODUCT_ID  = [0x0c02, 0x0c01, 0x41d9, 0x4e11, 0x4e12, 0x681d]

I'm not sure it's ideal though, because it doesn't correlate the product id's with their proper vendor id, it just matches each field with one of the options in the comma separated list. It would be better if it could use the old, dictionary approach, but without requiring BCD, but I haven't figured out how to do that yet.(The Hanlin driver, which uses this method, only has one possible vendor id, while the Android one has 4)

I suppose the likelyhood of two of the vendors using the same product id is pretty slim, though, isn't it, considering there's currently only four vendor id's in the list? It's theoretically possible, I suppose, but not likely.

In any case, it does detect my Nexus One, but I don't have any other Android devices to test it on. I guess it would match any of the others in the list, as long as they matched one of the vendor id's and one of the product id's.

What are your thoughts on this method?


Edit: I just noticed that this is very similar to the way the cybook driver is formatted, but the cybook still has the BCD field.

[kovidgoyal]

I implemented the dictionary lookup for the android driver because there are going to be lots and lots of android devices, so indivdual matching is a recipe for disaster. And I still think that matching on BCDs is neccessary. For example, the Nook is an android device but has various special requireements, for cover handling to enable cover flow browsing.

[tonyx3]

Yeah, I can see that with Android having lots of devices, it's not optimal, which is why I kinda hedged around it above. But I guess I'm still not convinced that BCD is necessary for normal Android devices.

The nook is technically an Android device, yes, but it's a dedicated ebook reader, and its OS is pretty heavily modified, so as you mention, it does require special consideration. But the vast majority of Android devices don't. You already handle the nook with a custom driver, and not with the Android driver, so you've noticed that as well.

I just don't see that any device which will be handled by this Android driver is going to need any special considerations that might be dependent on BCD. It's a driver for generic Android devices, none of which are dedicated ebook devices with their own special anything, in relation to reading ebooks.

In other words, if it's a Motorola Droid (determined by vendor and product id), it's not gonna matter what custom Android build someone runs on it, it's still gonna interface along the parameters of this driver. Same goes for all other normal Android devices.

[kovidgoyal]

I'm not convinced, but lets see how things progress in the Android world. There's no need to make a final decision here and now.

[tonyx3]

Indeed. Also, thanks for being so helpful and patient.