I have not experimented with ICS based ROMs much, but I have been reading through the various threads from time to time. The 3.0.x kernel seems to be coming along at a good pace and it looks like ICS will become the new norm sooner than later. Thanks and congratulations to Hashcode and the other contributors to that project.
I was trying out some ICS builds today and found that adb would not recognize gedeROM, so I started to do some digging. Using Windows Device Manager, I saw that it returned a device interface name and hardware IDs different than the stock and CM7 based builds. Here's what the stock and CM7 builds show in Device Manager...
Stock / CM7 / TWRP / CWMR
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01
The line in bold is obviously the name of the build. The next line is the "Class Name -> Interface" shown in the Device Manager list when Windows does not know what drivers to load. The last two are the Hardware IDs in the Properties list.
To my knowledge, these are the only hardware IDs that Kindle Fire users have had to deal with in the past and they are the key to getting the proper drivers to load up in Windows. Now, here's the same information for the ICS builds I've tried out...
Hashcode
Other devices -> Amazon
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006
Reloaded
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006
Energy / gedeROM / AOKP / MIUI
Other devices -> GT-P1000
USB\VID_1949&PID_0001&REV_0216&MI_01
USB\VID_1949&PID_0001&MI_01
Hashcode's build and Reloaded have omitted the "&MI_01" from the list of hardware IDs. With that value missing, it prompts Windows to load up "Android ADB Interface" instead of "Android Composite ADB Interface" that we've come to know. I'm not sure if that's a big problem because adb still seems to work with the change.
On the other hand, Energy, gedeROM, AOKP and MIUI hardware IDs have a different PID value. This poses a bigger problem because it will force users of these builds to reinstall Windows drivers if they want to use adb with them. That means KFU's driver installer has to be fixed, which I'm guessing won't be a huge problem, but all the other KF how-to's out there will have to be amended to include these hardware IDs in their instructions... and that's impossible. It just makes me shudder when I think about how many people are going to post on the forum asking why adb won't work after changing to a different ROM.
Device driver issues are a big problem for novice users and it would be great if we could avoid any potential pitfalls. In a perfect world, I'd love to see all these Interface names go back to "Kindle" and the Hardware IDs standardized back to what we had all along with CM7. I'm not sure if there's a good reason why these names and IDs have to be different now, so please school me on the reasons why if they are a necessary change. If there's a reason why these can't go back to the values we've been using, I implore the devs to at least come up with a standard that they can live with for all ICS based ROMs. It would make for a saner, happier Kindle Fire world. Thanks.
I was trying out some ICS builds today and found that adb would not recognize gedeROM, so I started to do some digging. Using Windows Device Manager, I saw that it returned a device interface name and hardware IDs different than the stock and CM7 based builds. Here's what the stock and CM7 builds show in Device Manager...
Stock / CM7 / TWRP / CWMR
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216&MI_01
USB\VID_1949&PID_0006&MI_01
The line in bold is obviously the name of the build. The next line is the "Class Name -> Interface" shown in the Device Manager list when Windows does not know what drivers to load. The last two are the Hardware IDs in the Properties list.
To my knowledge, these are the only hardware IDs that Kindle Fire users have had to deal with in the past and they are the key to getting the proper drivers to load up in Windows. Now, here's the same information for the ICS builds I've tried out...
Hashcode
Other devices -> Amazon
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006
Reloaded
Other devices -> Kindle
USB\VID_1949&PID_0006&REV_0216
USB\VID_1949&PID_0006
Energy / gedeROM / AOKP / MIUI
Other devices -> GT-P1000
USB\VID_1949&PID_0001&REV_0216&MI_01
USB\VID_1949&PID_0001&MI_01
Hashcode's build and Reloaded have omitted the "&MI_01" from the list of hardware IDs. With that value missing, it prompts Windows to load up "Android ADB Interface" instead of "Android Composite ADB Interface" that we've come to know. I'm not sure if that's a big problem because adb still seems to work with the change.
On the other hand, Energy, gedeROM, AOKP and MIUI hardware IDs have a different PID value. This poses a bigger problem because it will force users of these builds to reinstall Windows drivers if they want to use adb with them. That means KFU's driver installer has to be fixed, which I'm guessing won't be a huge problem, but all the other KF how-to's out there will have to be amended to include these hardware IDs in their instructions... and that's impossible. It just makes me shudder when I think about how many people are going to post on the forum asking why adb won't work after changing to a different ROM.
Device driver issues are a big problem for novice users and it would be great if we could avoid any potential pitfalls. In a perfect world, I'd love to see all these Interface names go back to "Kindle" and the Hardware IDs standardized back to what we had all along with CM7. I'm not sure if there's a good reason why these names and IDs have to be different now, so please school me on the reasons why if they are a necessary change. If there's a reason why these can't go back to the values we've been using, I implore the devs to at least come up with a standard that they can live with for all ICS based ROMs. It would make for a saner, happier Kindle Fire world. Thanks.
Last edited: