An experimental CM7 Kernel

[Guest t0mm13b]

This is only for gen 1 devices, this will need to be recompiled for gen 2 devices

I think this is dead as the last update was on the 21st march which was around the same time when the hardware compatibility wasn't the greatest on cm7, now that hardware is perfect someone may as well submit any changes that this kernel has made back up to cyanogenmod

Oh no it is not dead.... just haven't figured out how to switch modes... and yes it does need to be recompiled to cater gen2. :unsure:

[Guest nagper]

Does the kernel support any USB->VGA converter?

Thanks

NagPer

[Guest hackerse7en]

so, any news ??? nothing??

please give me any signal of live

if you havent just figured out how to switch off it means its working??

:)

[Guest DB_Runner]

my usb host mode cable just arrieved me. :)

i hope the project ist still alive !

[Guest oldxfile]

Just made it work on latest ZTE-U V880 (china unicom version of blade). I modified kernel source for the GEN2 address changes. Thanks a lot for your information!

The only issue left is the power problem. Without ext. power supply, no USB device would work. Is there any way to let the phone supply the power? At least for those low power consuming devices.

Edited July 12, 2011 by oldxfile

[Guest t0mm13b]

Just made it work on latest ZTE-U V880 (china unicom version of blade). I modified kernel source for the GEN2 address changes. Thanks a lot for your information!

The only issue left is the power problem. Without ext. power supply, no USB device would work. Is there any way to let the phone supply the power? At least for those low power consuming devices.

You definitely do need an external source, I'd rather that, than the phone supply the power which could suck up battery juice like hell :)

[Guest h4z7d]

Where can I download this? I think the links are broken.

[Guest targetbsp]

Where can I download this? I think the links are broken.

Look at the dates of this stuff. :D I think it'd go pear-shaped if you attempted to put kernels intended for a March build of Cm7 into a current CM7. And a lot of the stuff that was experimental here is in Cm7 now I think? The radio is.

Edited August 3, 2011 by targetbsp

[Guest h4z7d]

I cant find anything that says that USB host mode is in the latest revision of Cm7

[Guest t0mm13b]

I cant find anything that says that USB host mode is in the latest revision of Cm7

USB Host mode is an additional functionality that has a set of patches that needs to be merged in to the kernel source, and needed to be rebuilt.

As for getting it to work - have tried it, either the USB OTG adaptor which I picked up from dealextreme is a dud or the kernel does not recognize the signal when said USB device gets plugged in.

To be honest, the patches are somewhat iffy, as there's no real confirmed set of patches, although it was on the Nexus S handset, am not so sure if it will work.

[Guest h4z7d]

It seems to work ok for gschaden. Would you mind putting up a link to the files, or I can provide an FTP server to put them on. I would really like to have a go at getting this working!

[Guest johnsmithx]

USB Host mode is an additional functionality that has a set of patches that needs to be merged in to the kernel source, and needed to be rebuilt.

As for getting it to work - have tried it, either the USB OTG adaptor which I picked up from dealextreme is a dud or the kernel does not recognize the signal when said USB device gets plugged in.

To be honest, the patches are somewhat iffy, as there's no real confirmed set of patches, although it was on the Nexus S handset, am not so sure if it will work.

It will work, actually it does work already. You don't need any patch to make OTG work, just to properly configure the kernel.

As for the cable, you don't need to buy anything special, you can just take any existing cable of yours (with correct plugs, of course) and in the micro USB end (Blade side) you just connect 4th and 5th pin. That's all what this monumental "OTG adaptor" business is about - to interconnect 2 pins. Why don't you look up all about it on the Internet? It's as easy as writing "otg cable" in the google and selecting the very first link :-)

What you do need to figure out is the power supply, though. Blade won't power an attached device and you don't really want it either. You can use either a hub with its own power supply as suggested by Sven (who I would like to very thank for proving OTG on Blade 3/4 year ago) or you can simply take this cable you just made and connect the power directly to it (pin 1 and pin 4, again - google it).

When we started playing with this, we took the second choice (connecting power source directly to the OTG cable) and what we got stuck with for a minute was whether to actually power or not to power not only the device but also the Blade. You see, you must power the external device you want to connect to Blade, but you may or may not power the Blade too (you probably want it). It turned out that it depends on the power source, whether it's actually strong enough to power 2 devices. Which makes quite a sense because if you use for example some cheap wall->USB power convertor what hardly can power up a single device, you can't expect it to power 2 devices at once. So if it won't work for you at first just don't forget to check what power source you are actually using and if it's not strong enough then either replace it or you can simply disconnect it from a pin 1 on blade side.

Does the idea of having OTG on Blade sound more realistic and optimistic now?

Edited August 3, 2011 by johnsmithx

[Guest t0mm13b]

It will work, actually it does work already. You don't need any patch to make OTG work, just to properly configure the kernel.

Can you then show for the benefit of others (myself included) what is the correct configuration for this to work? :) (I have not worked with .32.9 in a good while now - so would not know now! ;))

As for the cable, you don't need to buy anything special, you can just take any existing cable of yours (with correct plugs, of course) and in the micro USB end (Blade side) you just connect 4th and 5th pin. That's all what this monumental "OTG adaptor" business is about - to interconnect 2 pins. Why don't you look up all about it on the Internet? It's as easy as writing "otg cable" in the google and selecting the very first link :-)

To be honest - I have googled and done my research on it and from others on the thread and elsewhere - it was suggested a dealextreme's USB OTG adaptor, which IMHO did not work or that the set of Sven Killig's patches did not work with the kernel - which was what I was setting out to try achieve... :)

What you do need to figure out is the power supply, though. Blade won't power an attached device and you don't really want it either. You can use either a hub with its own power supply as suggested by Sven (who I would like to very thank for proving OTG on Blade 3/4 year ago) or you can simply take this cable you just made and connect the power directly to it (pin 1 and pin 4, again - google it).

When we started playing with this, we took the second choice (connecting power source directly to the OTG cable) and what we got stuck with for a minute was whether to actually power or not to power not only the device but also the Blade. You see, you must power the external device you want to connect to Blade, but you may or may not power the Blade too (you probably want it). It turned out that it depends on the power source, whether it's actually strong enough to power 2 devices. Which makes quite a sense because if you use for example some cheap wall->USB power convertor what hardly can power up a single device, you can't expect it to power 2 devices at once. So if it won't work for you at first just don't forget to check what power source you are actually using and if it's not strong enough then either replace it or you can simply disconnect it from a pin 1 on blade side.

That last paragraph is very informative and the best explanation EVER :)

So please feel free to share the kernel configuration and the latest kernel image for others to try out :)

Cheers for the post! B)

Edited August 3, 2011 by t0mm13b

[Guest johnsmithx]

I am glad it was helpful a bit :rolleyes:

I will check the config file and separate from it the relevant parts which need to be enabled for OTG. I have quite many other changes in my kernel (it´s almost 1 MB bigger) so the full config might just confuse you. I will also make "git diff" to make sure there are no changes in the source code related to OTG, but I am already 99,9% sure I didn't have to change a single line in the code for this to work (which even more makes me wonder why they didn't enable it, as well as other useful features, in the "original" CM kernel, but that's probably for a different discussion).

If you want, I can also throw in a config part for USB HID things (like USB and bluetooth keyboard and mouse and such things.. all working :-) ).

I should also mention that I am using the 2.6.32-zte branch, not the newer one which is currently distributed in CM nightlies, simply because porting all those changes to basically the same version of the kernel, just because it has a newer date, and probably only for a few months before we get some better source code, didn't seem to me as the best way to spend the time. Rather I just backported a few useful things from the newer kernel back to mine.

As for the kernel binary, any other time it wouldn't be a problem except just now it's in very "dissected" state because I am currently working on making the new accelerometers (LIS33DE, ADI345/346) work in CM7. We in the Czech Republic got several weeks ago a batch of a few thousands Blades (sold out almost immediately) with ADXL345 (and maybe even some with LIS33DE, not sure about that) and people started popping up on our android forum asking why doesn't CM rotate on their phones (actually this problem makes even other sensors stop working) and they are whining at me to do something with it. It's almost done, sensors already work, just there are few side effects - CM tends to kill itself and restart (reminds me a scene from Robocop 2), so the affected ones just moved either back to stock ZTE ROM or to Ginger Stir Fry and try CM only when I ask them to try a new testing build as I don't have a phone with this accelerometer to test it myself. What one wouldn't do for a fun, right? I guess I probably indulge them, they have OTG, HID, working swap and compcache, full r/w NTFS with all ntfsprogs, undervoltaging, busybox with nearly 30 additional commands, soft-buttons and whatnot.

But the source is more important than the binary, the compilation is just a question of 10 minutes.

Just one more thought to the OTG cable and a picture of mine. You can look at the cable as I described it above, i.e. cable between Blade and external device, sideconnected with power source. But maybe easier is to look at the cable between a device and power source, sideconnected with Blade.

Look at the picture (and don't mind the black tape, I know it looks ugly :mellow:). The white long cable is the most usual USB A extension cable. The left white end is the very same connector as the USB port in the computer. To this end you connect the device, using the very same cable you would have used when connecting it to the computer. The other white end connects to the power source - may be a phone charger, powered USB hub, even USB port in PC (just don't forget USB 2.0 gives only 500mA max). And the little black one is to the Blade. In this little connector pins 4 and 5 are interconnected - a little soldering drop does it. It can't be done elsewhere because (big) USB has only 4 pins. Otherwise this black cable is the most cheapest ordinary micro USB cable for $2 off the eBay.

So maybe taking a simple cheap extension cable and attaching a cheap micro USB cable (with other end not important because you will cut it anyway) to it might be easier to understand and to build and you end up with all 3 ends you need.

Edited August 4, 2011 by johnsmithx

[Guest h4z7d]

Thanks for the excellent information!

I will check the config file and separate from it the relevant parts which need to be enabled for OTG.

........

If you want, I can also throw in a config part for USB HID things (like USB and bluetooth keyboard and mouse and such things.. all working :-) ).

That would be brilliant thank you!

So just to summarize:

• USB OTG functionality is available in Cm7 (All revisions?), but one would need to configure the kernel to enable it.
• To configure the kernel, you need to run a configuration file (that will be supplied by johnsmithx)
• Drivers for the peripherals will need to be loaded to drivers/usb/storage. Can I just get them from Svens site?
• USB connection with power to both handset and peripherals with pins 4 & 5 bridged.
• To connect a device, you would need to attach the cables, peripherals and power, then reboot the handset?
• Running dmesg will indicate if the usb devices are detected

I've got one of these:

http://www.amazon.co.uk/Cable-Tex-USB-Micro-Adaptor-male/dp/B005A2RVYQ

And a powered USB hub that charges the phone when it's connected to the USB OTG cable.

Please let me know if I've miss-interpreted any of this.

[Guest t0mm13b]

I am glad it was helpful a bit :rolleyes:

I will check the config file and separate from it the relevant parts which need to be enabled for OTG. I have quite many other changes in my kernel (it´s almost 1 MB bigger) so the full config might just confuse you. I will also make "git diff" to make sure there are no changes in the source code related to OTG, but I am already 99,9% sure I didn't have to change a single line in the code for this to work (which even more makes me wonder why they didn't enable it, as well as other useful features, in the "original" CM kernel, but that's probably for a different discussion).

If you want, I can also throw in a config part for USB HID things (like USB and bluetooth keyboard and mouse and such things.. all working :-) ).

I should also mention that I am using the 2.6.32-zte branch, not the newer one which is currently distributed in CM nightlies, simply because porting all those changes to basically the same version of the kernel, just because it has a newer date, and probably only for a few months before we get some better source code, didn't seem to me as the best way to spend the time. Rather I just backported a few useful things from the newer kernel back to mine.

As for the kernel binary, any other time it wouldn't be a problem except just now it's in very "dissected" state because I am currently working on making the new accelerometers (LIS33DE, ADI345/346) work in CM7. We in the Czech Republic got several weeks ago a batch of a few thousands Blades (sold out almost immediately) with ADXL345 (and maybe even some with LIS33DE, not sure about that) and people started popping up on our android forum asking why doesn't CM rotate on their phones (actually this problem makes even other sensors stop working) and they are whining at me to do something with it. It's almost done, sensors already work, just there are few side effects - CM tends to kill itself and restart (reminds me a scene from Robocop 2), so the affected ones just moved either back to stock ZTE ROM or to Ginger Stir Fry and try CM only when I ask them to try a new testing build as I don't have a phone with this accelerometer to test it myself. What one wouldn't do for a fun, right? I guess I probably indulge them, they have OTG, HID, working swap and compcache, full r/w NTFS with all ntfsprogs, undervoltaging, busybox with nearly 30 additional commands, soft-buttons and whatnot.

But the source is more important than the binary, the compilation is just a question of 10 minutes.

Just one more thought to the OTG cable and a picture of mine. You can look at the cable as I described it above, i.e. cable between Blade and external device, sideconnected with power source. But maybe easier is to look at the cable between a device and power source, sideconnected with Blade.

Look at the picture (and don't mind the black tape, I know it looks ugly :mellow:). The white long cable is the most usual USB A extension cable. The left white end is the very same connector as the USB port in the computer. To this end you connect the device, using the very same cable you would have used when connecting it to the computer. The other white end connects to the power source - may be a phone charger, powered USB hub, even USB port in PC (just don't forget USB 2.0 gives only 500mA max). And the little black one is to the Blade. In this little connector pins 4 and 5 are interconnected - a little soldering drop does it. It can't be done elsewhere because (big) USB has only 4 pins. Otherwise this black cable is the most cheapest ordinary micro USB cable for $2 off the eBay.

So maybe taking a simple cheap extension cable and attaching a cheap micro USB cable (with other end not important because you will cut it anyway) to it might be easier to understand and to build and you end up with all 3 ends you need.

Please do throw in the config for the extras and I will recompile the kernel :)

Okie, so let me get this right (have no clue about electronics and soldering), when you say pins 4 and 5, where are they interconnected? on the plug ends or what...

Maybe it would be a good idea to show a step-by-step on how to create that cable? :)

Cheers B)

Edited August 4, 2011 by t0mm13b

[Guest h4z7d]

Okie, so let me get this right (have no clue about electronics and soldering), when you say pins 4 and 5, where are they interconnected? on the plug ends or what...

Maybe it would be a good idea to show a step-by-step on how to create that cable? :)

Cheers B)

You need to make sure Pins 4 & 5 are connected, this should help you identify them:

Mini-USB Type-A Pinout & Cable Color Code

Attached file - Excuse my terrible paint skills.

you join:

All the reds together

All the blacks together

The greens from the mini usb to the usb socket

The whites from the mini usb to the usb socket

If there is a 5th cable on the Mini USB plug, join it with the black cables. If not, get a test meter and double check that pins 5 and 4 are interconnected on the mini usb plug.

Mini-USB Type-B Pinout & Cable C

All USB cables use the same colour conventions (more info here http://www.accesscom...ference/usb.htm). So you could take a standard usb extension cable like this one

Chop it up and join/solder the color cables as follows:

Attached image USB Host

Dont hesitate to ask me for more info on hardware/electronics (its part of my job).

Edited August 4, 2011 by h4z7d

[Guest johnsmithx]

So just to summarize:

• USB OTG functionality is available in Cm7 (All revisions?), but one would need to configure the kernel to enable it.

• To configure the kernel, you need to run a configuration file (that will be supplied by johnsmithx)

Just to remind once more again that I am using the kernel which was in CM all the time until Jul 9th when Tom replaced it with the kernel from the new ZTE source codes. I can't say these config settings will work in this kernel as well (don't see any reason why not, though, but you need to test it).

• Drivers for the peripherals will need to be loaded to drivers/usb/storage. Can I just get them from Svens site?

I would understand your surprised question "why it wasn't enabled already in the first place?", especially when it doesn't conflict with anything and there is plenty of space on the boot partition to let freely kernel grow a bit. Ask the Führer (a.k.a. Tom) :angry: (just kidding)

USB connection with power to both handset and peripherals with pins 4 & 5 bridged.

Power to Blade only if the power source is capable of powering 2 devices.

Maybe the most universal solution made a one clever guy (user pavbures) from our forum - he simply made a switch and built it directly onto the USB connector which either allows or disallows pin 1 (+5 V) from the power source to the Blade (white cable). Hope he will not mind if I post his pictures:

Pin 4 and 5 must be bridged so that way the Blade (its USB controller) will know that as soon as "something" is connected to it, the Blade should turn itself into USB host mode. From looking at the t0mm13b's logs on previous page here I would say his cable is correct and the Blade does indeed switch itself into USB host mode, just it doesn't detect the connected device, most probably because it was not powered. So maybe you don't even need any config customization, maybe you already got it right just you didn't sort out the power.

If it ends like this:

<6>[04-08 04:07:54.315278] [4: events/0]hub 1-0:1.0: USB hub found

<6>[04-08 04:07:54.315278] [4: events/0]hub 1-0:1.0: 1 port detected

it's wrong.

It should end like this (I've got there lot of verbose messages while we were testing it):

<7>[07-09 23:02:38.155148] [14: khubd]usb 1-1: udev 2, busnum 1, minor = 1

<6>[07-09 23:02:38.155148] [14: khubd]usb 1-1: New USB device found, idVendor=041e, idProduct=2020

<6>[07-09 23:02:38.155148] [14: khubd]usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5

<6>[07-09 23:02:38.155148] [14: khubd]usb 1-1: Product: ZEN X-Fi2

<6>[07-09 23:02:38.155148] [14: khubd]usb 1-1: Manufacturer: Creative Technology Ltd

<6>[07-09 23:02:38.155148] [14: khubd]usb 1-1: SerialNumber: 000000010000059A0002DA83CACD859A

<7>[07-09 23:02:38.155148] [14: khubd]usb 1-1: uevent

<7>[07-09 23:02:38.165153] [14: khubd]usb 1-1: usb_probe_device

<6>[07-09 23:02:38.165153] [14: khubd]usb 1-1: configuration #1 chosen from 2 choices

<7>[07-09 23:02:38.175161] [14: khubd]usb 1-1: adding 1-1:1.0 (config #1, interface 0)

<7>[07-09 23:02:38.175161] [14: khubd]usb 1-1:1.0: uevent

<7>[07-09 23:02:38.175161] [14: khubd]ub 1-1:1.0: usb_probe_interface

<7>[07-09 23:02:38.175161] [14: khubd]ub 1-1:1.0: usb_probe_interface - got id

<7>[07-09 23:02:38.175161] [14: khubd]usb-storage 1-1:1.0: usb_probe_interface

<7>[07-09 23:02:38.175161] [14: khubd]usb-storage 1-1:1.0: usb_probe_interface - got id

<7>[07-09 23:02:38.175161] [14: khubd]usb-storage: USB Mass Storage device detected

<7>[07-09 23:02:38.185158] [14: khubd]usb-storage: -- associate_dev

<7>[07-09 23:02:38.185158] [14: khubd]usb-storage: Vendor: 0x041e, Product: 0x2020, Revision: 0x0001

<7>[07-09 23:02:38.185158] [14: khubd]usb-storage: Interface Subclass: 0x06, Protocol: 0x503

<7>[07-09 23:02:38.185158] [14: khubd]usb-storage: Transport: Bulk

<7>[07-09 23:02:38.185158] [14: khubd]usb-storage: Protocol: Transparent SCSI

<6>[07-09 23:02:38.195159] [14: khubd]scsi0 : SCSI emulation for USB Mass Storage devices

<5>[07-09 23:02:43.255158] [1115: scsi_scan_0]sd 0:0:0:0: Attached scsi generic sg0 type 0

<5>[07-09 23:02:43.315169] [1115: scsi_scan_0]sd 0:0:0:1: Attached scsi generic sg1 type 0

<7>[07-09 23:02:43.365148] [1116: async/0]sd 0:0:0:0: [sda] 7722496 2048-byte logical blocks: (15.8 GB/14.7 GiB)

<5>[07-09 23:02:43.395154] [1116: async/0]sd 0:0:0:0: [sda] Write Protect is off

<7>[07-09 23:02:43.395154] [1116: async/0]sd 0:0:0:0: [sda] Mode Sense: 3e 00 00 00

<7>[07-09 23:02:43.395154] [1116: async/0]sd 0:0:0:0: [sda] Assuming drive cache: write through

<5>[07-09 23:02:43.405148] [1117: async/1]sd 0:0:0:1: [sdb] 62333952 512-byte logical blocks: (31.9 GB/29.7 GiB)

<5>[07-09 23:02:43.435149] [1117: async/1]sd 0:0:0:1: [sdb] Write Protect is off

<7>[07-09 23:02:43.435149] [1117: async/1]sd 0:0:0:1: [sdb] Mode Sense: 3e 00 00 00

<3>[07-09 23:02:43.435149] [1117: async/1]sd 0:0:0:1: [sdb] Assuming drive cache: write through

<6>[07-09 23:02:43.535143] [1116: async/0] sda:

<4>[07-09 23:02:43.555151] [1116: async/0] sda1

<6>[07-09 23:02:43.565154] [1117: async/1] sdb:

<4>[07-09 23:02:43.615149] [1117: async/1] sdb1

<5>[07-09 23:02:43.665146] [1116: async/0]sd 0:0:0:0: [sda] Attached SCSI removable disk

<5>[07-09 23:02:43.685141] [1117: async/1]sd 0:0:0:1: [sdb] Attached SCSI removable disk

Again even more simple - you can connect the external device anytime and the Blade switches itself willingly to the USB host mode and as soon as you disconnect the cable the Blade switches itself back to the USB widget (USB slave) mode.

Only thing you actually need to do is to mount the new device (like /dev/sda1 etc.), i.e. to attach it to a directory (like /mnt/mp3player or something) so you can access it. Maybe someone could make a script or an application to check available devices and allow their mount/unmount (or maybe there is already an application for that on the market?). It quite easy to make it, but for me that's too user-ish, I am more into low level programming.

Right, if there is no application which would do this automatically and just display a notification. Thinking about it it would be reasonable to build it directly into CM.

I've got one of these:

http://www.amazon.co...e/dp/B005A2RVYQ

And a powered USB hub that charges the phone when it's connected to the USB OTG cable.

Definitely should work.

Here are details of micro USB plug on my cable. On the first picture you see pins 1 - 3, no change there, on the second you see pins 4 and 5 bridged with this ugly soldering drop (with ugly tail) :rolleyes: As you can see this plug can be easily opened without brute force.

I would say the best place to connect pin 4 and 5 is right there in the plug, because unless on the other side of the cable is micro USB or mini USB, the cable will probably have only 4 wires (because only micro and mini USB have 5 pins) so you wouldn't be able to connect 4 & 5 on the other end.

There are also "intelligent" cables which can somewhat switch (connect 4&5) itself automatically.

The thing is - if you hardwire 4&5, it will unconditionally command Blade to switch itself into the USB host, no matter what is connected on the other side, so such a cable will logically not work as a "normal" USB cable anymore (had you wanted to connect it to the PC as a USB gadget for example).

[*]Running dmesg will indicate if the usb devices are detected

[*]To connect a device, you would need to attach the cables, peripherals and power, then reboot the handset?

Edited August 4, 2011 by johnsmithx

[Guest johnsmithx]

Excellent h4z7d's pictures.

And if the source won't be sufficient, you just interrupt the red line somewhere between the micro USB connector and the reddish "crossroad".

All USB cables use the same colour conventions (more info here http://www.accesscom...ference/usb.htm).

Oh, I am sorry to say that, but unfortunately in the reality that's not always the case. Just related to this OTG I've done an autopsy on about 4 cables and all of them had different colors. You know, those Chinese..

So in such a case you either need to use a multimeter or you will be left with no other choice than to open the plug on the other side as well to see which wire connects to what pin.

Or simply get the similar adaptor as referred on Amazon + powered USB hub.

Edited August 4, 2011 by johnsmithx

[Guest wbaw]

so, we just need it compiling into the cm7 kernel, automount for usb storage, a cheap cable & a (battery) powered usb hub?

[Guest johnsmithx]

so, we just need it compiling into the cm7 kernel, automount for usb storage, a cheap cable & a (battery) powered usb hub?

Yup.

Just in case of battery powered hub the battery must be able to power both devices.

//EDIT: deleted incorrect assumption to prevent confusion.

Edited August 5, 2011 by johnsmithx

[Guest h4z7d]

That is all excellent news, thanks johnsmithx! Your posts have been amazingly helpful! I look forward to testing it.

[Guest johnsmithx]

So here are 2 files - a diff against the latest defconfig of 2.6.32-zte branch, and a full config file.

I tried to keep there only relevant features, but still you will surely find there a lot of not necessary things. It's hard for me to just switch everything off as I am used back from kernel 2.0 days (mid 90') to build rather monolithic kernel with everything what would look even remotely useful and doesn't affect reliability or performance turned on.

I hope soon there will be many happy people OTGing around B)

[Guest FelixL]

@t0mm13b: will this be included in CM7 as soon as you tested it? I will get my local stuff up-to-date and test it as soon as I'm home, but this can take the hole day :/

@johnsmithx: thanks a lot for all the information! I thought the Blade needs to be powered to turn on the USB-port, as I remember it's like this on the Nexus One. Great that this is not a must.

[Guest Tom G]

As for the kernel binary, any other time it wouldn't be a problem except just now it's in very "dissected" state because I am currently working on making the new accelerometers (LIS33DE, ADI345/346) work in CM7. We in the Czech Republic got several weeks ago a batch of a few thousands Blades (sold out almost immediately) with ADXL345 (and maybe even some with LIS33DE, not sure about that) and people started popping up on our android forum asking why doesn't CM rotate on their phones (actually this problem makes even other sensors stop working) and they are whining at me to do something with it. It's almost done, sensors already work, just there are few side effects - CM tends to kill itself and restart (reminds me a scene from Robocop 2), so the affected ones just moved either back to stock ZTE ROM or to Ginger Stir Fry and try CM only when I ask them to try a new testing build as I don't have a phone with this accelerometer to test it myself. What one wouldn't do for a fun, right? I guess I probably indulge them, they have OTG, HID, working swap and compcache, full r/w NTFS with all ntfsprogs, undervoltaging, busybox with nearly 30 additional commands, soft-buttons and whatnot.

A bit off topic, but it is strange that the new accelerometer works in Ginger Stir Fry considering that kernel does not appear to have support for the newer sensors (I can't see anything in the kernel config for it). I have yet to see any log output from any devices experiencing the sensor problems, so if any of the users experiencing the problem would like me or Jacob to look at the issue someone should create an issue on the CM issue tracker and provide logs. We can't help without any information. The v880 that I got recently which is a fairly new build (has the newer LCD) does not have any sensor issues.