Workarounds/known issues 7/22: Updated for FRX07

[manekineko]

Originally Posted by [ACL]

Oo i didnt experince the no where sound yet. You are using pandora as a simple test? i'll have to look at that. I did notice on nand the sound gets routed back to the ear piece so there is some fine tuning to do.

I'm using the Android music player with an mp3 as a simple test.

I just played around with it some more. When it's playing with nowhere sound after a disconnect and replug, the 3.5mm on the extUSB seems definitely involved, because unplugging isn't detected even for pausing the music. However, if you keep unplugging and plugging it will sooner or later detect the plug and start playing sound through the headset again.

The great majority of the time when you have nowhere sound, plugging into the 3.5mm on the extUSB works correctly and sound starts coming out of the headset. I only managed to get the nowhere sound to happen once out of like 10-20 tries just now.

I haven't managed to create any situation that causes sound to get routed to the ear piece.

The lack of sound from the speakerphone without a rest period seems to occur 100% of the time.

[[ACL]]

I may have to wait on the 3.5mm jack. Trying to implement something solid for the rhod will most likely break blacstone and kovsky. Now i will try to get basic audio to work but i'm not sure if i can without making too many changes. Damn those legacy devices.

I'm pretty sure we will need to make changes anyways for TV out, but i'm not so sure who can fix blackstone after i break it. lol..

[arrrghhh]

Originally Posted by [ACL]

I may have to wait on the 3.5mm jack. Trying to implement something solid for the rhod will most likely break blacstone and kovsky. Now i will try to get basic audio to work but i'm not sure if i can without making too many changes. Damn those legacy devices.

I'm pretty sure we will need to make changes anyways for TV out, but i'm not so sure who can fix blackstone after i break it. lol..

Perhaps this is heresy in the making...

But why can't we break out each device? I guess that would leave some devices in the doldrums, but for the sake of progress... I dunno. Just my .02, I don't want progress to be slowed by anything, as I can see my RHOD quickly aging already!

Plus to me that would make for better support, on a per-device basis. Have a tree for each device, an autobuild for each device, and then improvements and testing only go towards that device. A lot less to worry about breaking as well in respect to committing code (I would think).

[manekineko]

Originally Posted by arrrghhh

Perhaps this is heresy in the making...

But why can't we break out each device? I guess that would leave some devices in the doldrums, but for the sake of progress... I dunno. Just my .02, I don't want progress to be slowed by anything, as I can see my RHOD quickly aging already!

Plus to me that would make for better support, on a per-device basis. Have a tree for each device, an autobuild for each device, and then improvements and testing only go towards that device. A lot less to worry about breaking as well in respect to committing code (I would think).

Even if the improvements for the Rhodium came necessarily at the expense of the Blackstone and Kovsky, it seems like a great deal for the project anyway. I bet there's a ton more users that are on the Rhodium rather than those really old legacy devices.

Of course, I may be more than a little biased on the matter as well.

[natemcnutty]

Originally Posted by arrrghhh

Perhaps this is heresy in the making...

But why can't we break out each device? I guess that would leave some devices in the doldrums, but for the sake of progress... I dunno. Just my .02, I don't want progress to be slowed by anything, as I can see my RHOD quickly aging already!

Plus to me that would make for better support, on a per-device basis. Have a tree for each device, an autobuild for each device, and then improvements and testing only go towards that device. A lot less to worry about breaking as well in respect to committing code (I would think).

The big problem is keeping everything consistent and easy to maintain the code. Breaking it into separate configs and autobuilds per device creates an administration nightmare.

I like the direction they are planning with .35 to refactor everything and truly keep device specific code in the baordfiles and try to keep it out of the main files. The closer to AOSP they can keep it, the easier their work becomes since Google's devs suddenly become the code maintainers.

[arrrghhh]

Originally Posted by natemcnutty

The big problem is keeping everything consistent and easy to maintain the code. Breaking it into separate configs and autobuilds per device creates an administration nightmare.

I like the direction they are planning with .35 to refactor everything and truly keep device specific code in the baordfiles and try to keep it out of the main files. The closer to AOSP they can keep it, the easier their work becomes since Google's devs suddenly become the code maintainers.

Makes sense... I also just read some stuff on the .35 refactor as you call it, and it does sound like a much better way of doing things.

Glad we've got guys like Alex pushin to get this stuff updated.

Funny thing is, there are quite a few devs with very old devices, like Alex and stine... so Kov and Raph still stays relevant so long as they still have their old dinosaurs

[[ACL]]

Originally Posted by arrrghhh

Perhaps this is heresy in the making...

But why can't we break out each device? I guess that would leave some devices in the doldrums, but for the sake of progress... I dunno. Just my .02, I don't want progress to be slowed by anything, as I can see my RHOD quickly aging already!

Plus to me that would make for better support, on a per-device basis. Have a tree for each device, an autobuild for each device, and then improvements and testing only go towards that device. A lot less to worry about breaking as well in respect to committing code (I would think).

Ahh man i said the same thing then got a verbal abuse of epic proportions by the fellas. Looks like its a way to keep all devices up to date. If we start quickly moving Rhod then all the others would get left behind. This isnt good since some of the xdandroid guys have raphs. I will continue working on my nand kernel in the meantime.

[Boominsvx]

Well you never recieved verbal abuse from me. I think the HD2 is the #1 device, and the Rhodium is #2 in the irc chat. Up until recently I understood the reason to keep things together and compatable, but with the recent progress being halted until "everyone is tested and safe" has seriously slowed the final product. With the creation of taid's Froyo X build, I've finally switched to android full-time, and I check the logs and threads daily for updates like a junkie. It just feels like we're so close but every corner seems to be a dead end at this point. Either something hasn't been commited, or can't be cause it'll break something else. Now I'm even seeing some of these kov/raph/blac devs going on to different devices. My 3rd tp2 sits in my hands and before i can say a word, I've got by buddy with his epic and his friend with an evo shift shutting me out. At least I can laugh at their bill to regain my footing. The HD2 guys split off right from the get go, and look where they are now. Yes, we share the same hardware on these devices, but the fine tuning stage is going to be hell as things are now. At this point, you'll never recieve any verbal abuse from me. Just my .02. Great job on this ACL, and all involved developers. Don't leave us now.

Regards, A rhodium user.

[natemcnutty]

Originally Posted by [ACL]

Ahh man i said the same thing then got a verbal abuse of epic proportions by the fellas. Looks like its a way to keep all devices up to date. If we start quickly moving Rhod then all the others would get left behind. This isnt good since some of the xdandroid guys have raphs. I will continue working on my nand kernel in the meantime.

I can see where they are coming from on the Haret side, but on the NAND side, I think you are correct that we need separate configs for each device. If all devices had NAND working, that would be awesome to separate them all since you'd have to make tinboot changes anyway.

That's one of the things I love about your NAND tree is that you can make any changes you want as quickly as you like. I love how the NAND tree has been the testing platform that brings a lot of features over to Haret, and it does so with more native code than relying on Haret

[[ACL]]

Originally Posted by natemcnutty

I can see where they are coming from on the Haret side, but on the NAND side, I think you are correct that we need separate configs for each device. If all devices had NAND working, that would be awesome to separate them all since you'd have to make tinboot changes anyway.

That's one of the things I love about your NAND tree is that you can make any changes you want as quickly as you like. I love how the NAND tree has been the testing platform that brings a lot of features over to Haret, and it does so with more native code than relying on Haret

Yea and actually im using that code to bring to .35 so we have nand compatibility out of the box. I might ask bzo to just give me the camera patch to have that on nand .27 without worries. And just finish off getting the partitioning portion to get true nand done for ourselves. the hell with the gsm guys :-p