00:25.34 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
00:45.29 | *** join/#htc-linux peacedog (n=peacedog@pool-71-254-86-41.lyncva.east.verizon.net) |
00:46.06 | *** part/#htc-linux peacedog_ (n=peacedog@pool-71-254-86-41.lyncva.east.verizon.net) |
00:55.43 | *** join/#htc-linux l33tlinuxh4x0r (n=user@adsl-144-166-112.rmo.bellsouth.net) |
02:07.42 | *** join/#htc-linux wooj (n=wooj@unaffiliated/wooj) |
02:12.28 | wooj | Anyone know if there's any progress on getting calling to work on the HTC Diamond in Linux/Android? |
02:27.59 | *** join/#htc-linux infidel206 (n=infidel2@unaffiliated/jenkempusher/x-35920) |
02:29.01 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
03:08.42 | *** join/#htc-linux mrmoku|away (n=mrmoku@ppp-93-104-48-129.dynamic.mnet-online.de) |
03:20.23 | *** join/#htc-linux surge (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
03:21.27 | tmzt | wooj: still working on it |
03:21.52 | tmzt | we have the rpc codes I think in the wiki |
03:22.12 | AstainHellbring | hiya |
03:22.26 | tmzt | hello |
03:23.02 | AstainHellbring | hows it going? |
03:23.54 | tmzt | ok |
03:24.33 | tmzt | maybe we can trace rpc on g1 with the kernel define |
03:28.54 | wooj | tmzt, okay, cool. Thanks for the update :) |
03:40.53 | wooj | hmm when I boot android, I can't type on the onscreen keyboard, or rather, I can, but I have to click the bottom of the screen where the onscreen keyboard isnt ;) |
03:45.41 | *** part/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
03:53.21 | tmzt | it's not calibrated |
04:04.52 | *** join/#htc-linux j0b0 (n=jobo@67.99.198.4) |
04:11.11 | wooj | tmzt, how can I fix that? |
04:14.20 | *** join/#htc-linux furtardo (n=mks@nat/yahoo/x-55d0fe11b9c726fc) |
04:14.25 | tmzt | uh, which device is it? |
04:14.52 | wooj | htc touch diamond |
04:15.10 | wooj | I just the calibration thing for the stylus in windows mobile, but somehow I doubt that makes a difference |
04:17.04 | tmzt | no |
04:17.09 | tmzt | which diam |
04:17.40 | wooj | ummm |
04:17.46 | wooj | I dont understand |
04:23.29 | wooj | CDMA Htc Touch Diamond, |
04:24.48 | j0b0 | wooj, underneath the battery, it should say DIAM500 or DIAM800 (or some other number) |
04:24.58 | wooj | Oh let me check |
04:25.55 | wooj | tmzt, j0b0, it says DIAM500 |
04:26.09 | j0b0 | ok, that's 'which diamond' |
04:27.13 | wooj | Okay cool |
04:28.32 | j0b0 | ( i just dropped in 10 lines ago so i dont know what youre trying to fix ) |
04:30.52 | tmzt | use the raph800 msmts line |
04:30.58 | wooj | j0b0, well, when i boot android, my onscreen keyboard shows at the top of the screen, but I have to hit the bottom of the screen |
04:31.00 | wooj | hmm kk |
04:32.47 | j0b0 | yes. 'etx' reports here (http://forum.xda-developers.com/showpost.php?p=3914773) that raph800 ts calibration works for -500 |
04:35.38 | wooj | Sorry if I'm noobish, I just got this thing today, specifically cause it can run linux ;) |
04:36.51 | tmzt | cool |
04:36.55 | tmzt | Sprint? |
04:37.06 | wooj | No, I'm in Canada. MTS, which is basically Bell. |
04:38.25 | tmzt | oh |
04:39.30 | wooj | aha I have android... but the colours are all wonky |
04:39.31 | wooj | lol |
04:39.50 | tmzt | you have an old kernel |
04:40.27 | wooj | hmm am i going to have to manually build one? |
04:41.03 | tmzt | that would be best |
04:41.18 | tmzt | don't know if updated ones are available |
04:41.21 | wooj | Guess I'll go google where to get the toolchain |
04:41.27 | tmzt | with diam500 support |
04:41.39 | j0b0 | the color fix is not yet in ltg git |
04:41.39 | tmzt | codesourcery.com works well |
04:41.44 | tmzt | oh |
04:41.58 | j0b0 | try the kernel linked to from that same post 'here is yet another kernel'... |
04:42.01 | tmzt | is it just adding another mach to maejrep's code? |
04:42.25 | tmzt | the raphaelcdma part |
04:42.47 | j0b0 | tmzt, no. it uses different mdp dma flags based on epson vs. toshiba, in stead of gsm vs. cdma |
04:42.58 | wooj | So I just replace my current zimage with this? |
04:43.08 | j0b0 | because the 500 has the mmc id from 100 but the panel from 800 |
04:43.51 | j0b0 | this is how i did it: http://tibook.jb.b4m.com/j0b0/diffs-commits/commit-98c868f-mdp-666-565-jobo-090529.txt but im not sure whether its the proper way. it works tho... |
04:44.21 | j0b0 | wooj yes. replace/rename that kernel, that should do it |
04:44.33 | wooj | Ok |
04:45.23 | wooj | booting now |
04:45.40 | wooj | ooh the android is green |
04:48.02 | *** join/#htc-linux droid001 (n=mc@p4FDCD1C7.dip.t-dialin.net) |
04:49.42 | j0b0 | if there is nothing 'just plain wrong' about that patch we can add it to git, but i can't really judge that. tmzt, care to review it? |
04:49.55 | wooj | well I just booted that kernel |
04:50.04 | wooj | graphics are fine, but the touchscreen is still off |
04:50.14 | wooj | if it touch the top of the screen, the bottom is pressed |
04:50.20 | wooj | and vice versa. |
04:50.41 | j0b0 | wooj did you add the ts calibration from 800 to the cmdline in your default.txt? |
04:50.49 | wooj | Oh, forgot. One minute. |
04:51.43 | wooj | mtype is 1805 |
04:52.48 | wooj | j0b0, is that what it ought to be? it seems to be from this post. |
04:53.18 | j0b0 | yes. should be tha same as diam100 |
04:53.30 | wooj | "I'm using 1805 as the mtype and the touch screen calibration values from a RAPH800 and its pretty close. |
04:53.30 | wooj | " - I'm not sure where to find these calibration values. |
04:53.50 | j0b0 | wooj -> http://wiki.xda-developers.com/index.php?pagename=RaphaelLinux |
04:53.51 | wooj | Is that this line? - msmts_calib=0x7a.0x5e.0x35a.0x37f msmvkeyb_toggle=hide" |
04:54.16 | wooj | ok... |
04:54.17 | wooj | msmts_calib=0x81.0x393.0x358.0x7D |
04:54.20 | wooj | ill change it |
05:02.27 | wooj | ahh perfect! |
05:05.29 | wooj | well apps work |
05:05.44 | wooj | cant find cell service though ;) |
05:06.02 | wooj | But I am impressed :D |
05:06.10 | tmzt | you should |
05:06.25 | tmzt | does that work on cdma yet, except vogue? |
05:06.49 | tmzt | you have to enable SMD7500 which might reboot the diam |
05:06.57 | wooj | How do I do that? |
05:07.03 | tmzt | it would be good to know if it does though |
05:07.14 | wooj | I went into wireless and searched for networks, but no dice |
05:07.15 | tmzt | you do have to compile the kernel for that |
05:07.29 | j0b0 | i thought cell service works for all devices |
05:07.32 | wooj | ahh, I'll get the stuff to do that tomorrow. |
05:07.49 | wooj | j0b0, it said it couldnt find anything. |
05:07.57 | tmzt | j0b0: no, maybe raph800 |
05:08.03 | wooj | my phone is CDMA, not GSM, if that matters |
05:09.12 | wooj | according to the page here, my mtype ought to be 2040, would that matter? (http://wiki.xda-developers.com/index.php?pagename=RaphaelLinux) |
05:10.18 | j0b0 | wooj, you can try it, but i think that will give you no access to mmc, so you couldnt mount any image files to boot into |
05:10.33 | tmzt | I think you where using the raph800 one |
05:10.51 | tmzt | oh |
05:10.52 | wooj | tmzt, I was using DIAM100 mtype |
05:10.59 | tmzt | is that an issue still |
05:11.05 | wooj | j0b0, oh, well that wouldnt be any help. lol :) |
05:11.08 | tmzt | suprised that worked at all |
05:11.38 | tmzt | and color is right now with diam100 mtype? |
05:11.45 | wooj | correct |
05:11.51 | tmzt | odd |
05:11.53 | j0b0 | with that patch i just posted, yes |
05:11.57 | wooj | and with the proper calibration settings, that is all good too. |
05:12.05 | wooj | im trying mtype 2040 to see what happens |
05:12.06 | tmzt | I though diam100 was 18bit |
05:12.39 | j0b0 | the 565 vs. 666 does not depend on mtype then |
05:12.58 | wooj | yeah 2040 doesnt boot |
05:12.59 | tmzt | it must |
05:13.10 | tmzt | how far does it get? |
05:13.21 | wooj | to trying to load android |
05:13.27 | wooj | then it cant find anything in /system |
05:13.38 | tmzt | j0b0: the DST settings are based on mtype |
05:13.48 | tmzt | ok, j0b0 is right |
05:13.58 | tmzt | we need to fix that |
05:14.09 | wooj | So, i'll have to recompile to get my cellular radio to work eh? |
05:14.11 | tmzt | it should be a one-line change |
05:14.15 | j0b0 | the mmc thing depends on mtype, but 555/565 not when you apply this http://tibook.jb.b4m.com/j0b0/diffs-commits/commit-98c868f-mdp-666-565-jobo-090529.txt |
05:14.16 | tmzt | yeah |
05:14.21 | wooj | kk |
05:14.40 | tmzt | j): that was for testing, right? |
05:14.58 | tmzt | got to get use to hw keyboard again |
05:15.06 | wooj | I have gcc and all set up on my debian install here, so I'll see what I need to cross-compile in the am... dont want to embark on a large project at midnight :) |
05:15.29 | ltxda | Everyone go to http://www.facebook.com/username and get it setup before your name gets taken :) |
05:15.29 | ltxda | You are welcome! |
05:16.27 | wooj | o_O |
05:17.05 | wooj | On a completely unrelated subject, what is the best app for playing movies under window mobile? :P |
05:17.11 | wooj | wmp doesn't 'do' xvid. |
05:18.27 | j0b0 | wooj i dont know |
05:20.07 | j0b0 | tmzt, so both cell and sd depend on mtype, but 500 needs one from 100 and the other from 800 |
05:20.19 | j0b0 | could we detect it based on soemthng else |
05:20.27 | j0b0 | to prevent mtype explosion |
05:20.44 | tmzt | we shouldn't be detecting sd slot at all |
05:21.08 | tmzt | we have mtype per device there is really no choice |
05:21.33 | tmzt | I have already registered raph500 but haven't patched anything for it yet |
05:21.41 | j0b0 | then machine_is_something_cdma is really the wrong name |
05:22.00 | j0b0 | as 800 is also cdma |
05:22.04 | tmzt | well, the gsms were given the codename |
05:22.14 | tmzt | diam800? |
05:22.21 | tmzt | or you mean raph |
05:22.26 | j0b0 | both? |
05:22.35 | tmzt | yeah |
05:23.00 | j0b0 | machine_last_name_is_800() ;D |
05:23.44 | tmzt | no |
05:24.03 | tmzt | diam500 and raph800 are msm7501A |
05:24.16 | wooj | my Diam500 has no SD slot. |
05:24.25 | tmzt | raph500 and I think diam800 are msm7500A |
05:24.25 | wooj | only the 4gb internal storage |
05:24.32 | tmzt | which is sd |
05:24.36 | wooj | Oh ok |
05:26.25 | j0b0 | board-htcraphael-mmc.c:448 uses pdata based on whether the machine is cdma. that would fail for 500 |
05:27.36 | j0b0 | so if 500 uses its own mtype, _is_cdma() should return true, as it is cdma, but the sd is as in gsm |
05:28.36 | wooj | if I can provide any info, let me know |
05:28.59 | tmzt | it's not -is-cdma |
05:29.12 | tmzt | it-s machine-is-htcraphael-cdma |
05:30.02 | j0b0 | yes. and diamond_cdma, but the 500 is cdma but should use the pdata for sd that works for diam100 and raph100 |
05:30.16 | tmzt | no |
05:30.29 | tmzt | diam is on 3 I bevieve |
05:30.54 | tmzt | I think we should enable all the sdcc slots anyway, but the current code works |
05:31.14 | tmzt | actually cdma and gsm have the same sdcc setup I think |
05:31.19 | tmzt | diam |
05:31.54 | j0b0 | according to the code, raph/diam gsm are both on 2 and raph/diam cdma are both on 3 |
05:33.28 | j0b0 | or am i looking in the wrong place? (board-htcraphael-mmc.c:448) |
05:34.06 | j0b0 | and diam500 works with 1805 |
05:37.09 | tmzt | oh |
05:37.26 | tmzt | sorry, maejrep did that I don't really remeber |
05:40.18 | j0b0 | so 500 should take the 'gsm path' for sd, but cdma for cell, and on current git also cdma for panel, |
05:41.34 | tmzt | yeah |
05:41.42 | tmzt | I think that's right |
05:41.44 | j0b0 | but it seems odd (name wise) to check for radio type to do sd or panel stuff. |
05:42.17 | tmzt | we saw it as the model subtype |
05:42.42 | tmzt | like I said, the gsms ones were already registered |
05:42.52 | tmzt | before work on cdma began |
05:43.09 | j0b0 | for sd it would look nicer to have machine_sd_slot_number(), and for panel machine_pixel_format() or something |
05:43.48 | j0b0 | or use something that does not depend on mtype at all. im not sure whether that possible for sd, but it apparently is for panel |
05:45.43 | tmzt | well, we could pass those from bootloader if we want |
05:46.08 | tmzt | we might have enough information to detect the tft panel now anyway |
05:46.36 | tmzt | the modification to add diam500 is extremely minor |
05:47.13 | tmzt | we will probably clean this stuff up for 2.6.29 anyway |
05:47.37 | j0b0 | also for battery (4-byte vs. 2-byte smem data layout) differs for different models, but im sure we could detect it by just looking at it |
05:48.39 | j0b0 | that too would be odd to depend on cdma vs. gsm |
05:51.19 | j0b0 | are we moving to .29 yet? |
05:51.52 | tmzt | I'm going to ask cr2 about that |
05:52.59 | tmzt | but I would I would like to clean up the code first |
05:53.25 | *** join/#htc-linux goxboxlive (n=goxboxli@237.80-202-137.nextgentel.com) |
05:54.57 | tmzt | rather than taking over the current code |
05:55.32 | tmzt | but then I would also like are rpc/rpcrouter implementation to work |
05:55.43 | tmzt | so we might just move anyway |
06:01.16 | j0b0 | is it generally a good thing to not depend on mtype is a driver can probe the device and find out which path to take? |
06:01.26 | j0b0 | or does that complicate things for future devices |
06:05.59 | tmzt | if that's possible, yes |
06:06.11 | tmzt | we already have interest in tp2 |
06:07.32 | tmzt | that's what pdata is for, so that the device specific information is not in the driver |
06:07.55 | tmzt | but htcraph-mmc is not a driver, it's a board file for five different models |
06:08.08 | tmzt | part of a board file actually |
06:08.40 | tmzt | I'm hoping we can have a single htc file or set of files and less code in the boards |
06:09.19 | tmzt | for these devices it would make sense to have a type of board file just form amss specifics |
06:09.41 | tmzt | so we would have: |
06:09.53 | tmzt | mach-msm (includes qsd also) |
06:10.25 | tmzt | board-htcraphael raph500/800/100/110/300 diam500/800/100 |
06:10.43 | tmzt | board-htctopaz etc. |
06:10.57 | tmzt | htc-hw-mmc if needed |
06:11.10 | tmzt | amss5200 etc. |
06:11.42 | tmzt | one thing is we pretty much have to follow what google/android does |
06:12.12 | j0b0 | but we have more/different devices |
06:12.45 | tmzt | yes, but we really can't maintain a parallel infrastructure/codebase |
06:13.08 | tmzt | we do now but it's mostly additions not wholesale changes |
06:13.44 | tmzt | I had hoped that sapp would lead to more generalization but there's a lot of duplication instead |
06:23.15 | wooj | finally, a working media player for xvid |
06:23.21 | wooj | *cheer* |
06:25.56 | tmzt | what? |
06:26.37 | wooj | TCPMP (The Core Pocket Media Player) |
06:30.11 | tmzt | yeah |
06:30.47 | wooj | im just waiting for android to get to a functional level, and ill happily use only it. |
06:49.37 | *** join/#htc-linux punkass (i=punkass@unaffiliated/punkass) |
06:49.40 | *** join/#htc-linux lucxxx (n=root@89-115-128-35.cl.ipv4ilink.net) |
07:08.03 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
07:08.35 | *** join/#htc-linux lucxxx (n=root@89-115-128-35.cl.ipv4ilink.net) |
07:15.07 | *** join/#htc-linux Shinto (n=John@f049153229.adsl.alicedsl.de) |
07:23.58 | *** join/#htc-linux the_sys0p (n=the_sys0@cpe-67-49-192-228.bak.res.rr.com) |
07:24.17 | *** join/#htc-linux dream_kill (n=nospam@87.194.186.187) |
07:41.11 | *** join/#htc-linux omegaCD (n=omegaCyb@219-84-5-134-adsl-tpe.STATIC.so-net.net.tw) |
07:47.27 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
08:27.56 | *** join/#htc-linux tsdogs (n=tsdogs@tsdogs.metalit.net) |
08:38.15 | *** join/#htc-linux dream_kill (n=nospam@87-194-186-187.bethere.co.uk) |
08:39.18 | *** join/#htc-linux dream_kill (n=nospam@89.131.127.37) |
08:44.28 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
08:50.26 | *** join/#htc-linux onen|openBmap (n=onen@mry91-1-89-87-198-158.dsl.club-internet.fr) |
08:52.25 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
08:56.27 | *** join/#htc-linux nebi (n=nebi@217.142.147.19) |
09:21.26 | *** join/#htc-linux punk-ass (i=punkass@unaffiliated/punkass) |
09:29.31 | *** join/#htc-linux IamSOG (n=IamSOG@218.19.124.241) |
09:43.10 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
10:04.40 | *** join/#htc-linux MethoS (n=clemens@host-091-097-243-193.ewe-ip-backbone.de) |
10:05.37 | *** join/#htc-linux sroecker (n=sroecker@BAHa48a.bah.pppool.de) |
10:07.13 | Squarc | hey everyone |
10:07.40 | tcccp | hey you |
10:33.15 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
10:38.49 | *** join/#htc-linux dream_kill (n=nospam@89.131.127.37) |
10:49.24 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
10:58.53 | *** join/#htc-linux mblancom (n=mblancom@103.Red-88-17-196.dynamicIP.rima-tde.net) |
10:58.59 | mblancom | hi |
11:01.04 | mblancom | I don't know if your are following the linux kernel mailing list but recently people form google are talking about integrate their .28 branch in mainline and to me it seems they want to support as many devices as possible. It could be a good idea to try to integrate your diffs with the google repository |
11:02.31 | lama | link |
11:03.31 | mblancom | oh, I mean .29 google branch |
11:04.06 | wooj | Gah my battery went from 3 bars to 1 overnight? wtf. |
11:04.47 | Marajin_ | wooj: it happens |
11:05.13 | wooj | Marajin_, the only thing I can think of is that I had windows live messenger running overnight. :S |
11:09.52 | mblancom | the thread started here: http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01522.html and a lot of discussion follows mainly related with the arm arch an their closed mailing list but i think with good attitude to incorporate contributions outside google and to merge in mainline as fast as possible |
11:21.43 | tmzt | mblancom: yeah. great |
11:24.13 | tmzt | Wy: you here? |
11:27.27 | wooj | rawr |
11:34.54 | Squarc | tmzt: any news on the audio ddrivers? |
11:48.20 | *** join/#htc-linux fnord (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
12:22.27 | *** join/#htc-linux sxe (n=sxe@ip-62-143-98-186.unitymediagroup.de) |
12:27.57 | tmzt | http://bobcopeland.com/android_wifi.html |
12:28.06 | tmzt | new driver for mac80211 |
12:29.44 | Squarc | :) |
12:46.27 | wooj | tmzt, slacker, you havent magically singlehandedly got everything working yet? its been about 8 hours! |
13:06.51 | par | tmzt: which chip(s) does that cover? |
13:12.26 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
13:13.31 | *** join/#htc-linux htc-linux (i=5745de6c@gateway/web/ajax/mibbit.com/x-e250278eeb7c670c) |
13:24.09 | par | guess its just for the dream |
13:42.04 | *** join/#htc-linux captnoord (i=5147a47b@gateway/web/ajax/mibbit.com/x-66df6c2ac1784cbc) |
13:44.34 | *** join/#htc-linux MLM (n=mlvdmeid@meide.xs4all.nl) |
13:50.02 | *** join/#htc-linux fnord (n=fnord@24-151-90-116.static.nwtn.ct.charter.com) |
13:57.37 | captnoord | hmmm |
13:57.46 | captnoord | latest raphael build is doing wierd |
13:57.55 | captnoord | anyone know why? |
13:59.34 | tmzt | what do you mean? |
13:59.39 | tmzt | which raph? |
13:59.47 | captnoord | raph 300 |
14:00.07 | captnoord | which is a 100 |
14:00.08 | captnoord | :P |
14:00.22 | tmzt | is that the same as raph100? |
14:00.36 | captnoord | yup |
14:00.43 | captnoord | hmmm |
14:00.43 | captnoord | lol |
14:00.45 | captnoord | waiting long |
14:00.52 | captnoord | I think the framebuffer is broken |
14:00.54 | captnoord | in some way |
14:01.05 | captnoord | as I have the double rumble |
14:01.07 | captnoord | just now |
14:01.22 | captnoord | hmmmm |
14:01.31 | tmzt | how many times did you try? |
14:01.37 | captnoord | second time |
14:01.37 | tmzt | did mmc timeout? |
14:01.53 | tmzt | what build? |
14:02.02 | captnoord | personal-> last rev |
14:02.16 | tmzt | from where? |
14:02.43 | captnoord | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.27 |
14:02.45 | captnoord | that one |
14:03.42 | captnoord | last line of the console is: [ 0.010000] console handover: boot [htc_fb-1]->real [tty0] |
14:03.43 | tmzt | built from git? |
14:03.46 | captnoord | yup |
14:04.06 | captnoord | maybe I have some stuff in the command line I shouldn't have |
14:06.01 | captnoord | set cmdline "root=/dev/ram0 init=/init console=tty0 mem=82M msmsdcc_id=2 imgdevname=/dev/mmcblk0p1 imgdevnum=1 imgdir=/tmp msmts_calib=0x6D.0x5D.0x340.0x375 msmvkeyb_toggle=hide" |
14:08.18 | captnoord | i'm sure |
14:08.23 | captnoord | i'm doing something wrong again |
14:09.46 | captnoord | i'll rebuild |
14:09.51 | captnoord | maybe I did something wrong |
14:15.09 | tmzt | how many times has it failed? |
14:15.27 | captnoord | 2 |
14:15.30 | captnoord | now rebuilding |
14:15.37 | AstainHellbring | morning |
14:15.43 | captnoord | morning |
14:19.56 | captnoord | 3e |
14:22.33 | captnoord | but there isn't something wrong about my command line |
14:22.34 | captnoord | ? |
14:22.43 | captnoord | my last build worked perfect |
14:22.46 | captnoord | so I dono |
14:22.46 | captnoord | :S |
14:24.58 | captnoord | i'll go back in rev's |
14:25.02 | captnoord | maybe its just me |
14:26.22 | NetRipper | captnoord, set mem= to 76M |
14:26.32 | captnoord | dank je |
14:26.56 | NetRipper | and you don't need console= |
14:27.02 | NetRipper | nor msmssdcc_id |
14:27.27 | NetRipper | unless someone re-added it to the kernel |
14:27.28 | captnoord | k |
14:27.49 | NetRipper | and use MTYPE 1910 |
14:28.00 | captnoord | I am |
14:28.01 | captnoord | :D |
14:28.02 | captnoord | thanks |
14:39.08 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
14:40.06 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
14:56.43 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
14:58.23 | *** join/#htc-linux hollo (n=hollo@3e6b7b2c.rev.stofanet.dk) |
15:05.11 | *** join/#htc-linux zycho (n=zycho@dslb-088-070-049-150.pools.arcor-ip.net) |
15:27.39 | *** join/#htc-linux hollo (n=hollo@3e6b7b2c.rev.stofanet.dk) |
16:14.33 | captnoord | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5e47c478b0b69bc9bc3ba544e4b1ca3268f98fef |
16:14.34 | captnoord | lol |
16:23.38 | *** join/#htc-linux surgex0 (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
16:32.27 | *** join/#htc-linux surge (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
17:06.42 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
18:00.46 | *** join/#htc-linux dcordes-kais (n=dcordes-@ip-77-24-73-1.web.vodafone.de) |
18:01.46 | dcordes-kais | lol no more zImage?!? |
18:06.49 | *** join/#htc-linux einand (n=einand@remote2.student.chalmers.se) [NETSPLIT VICTIM] |
18:06.49 | *** join/#htc-linux elysion_ (i=kiiski3@mustatilhi.cs.tut.fi) [NETSPLIT VICTIM] |
18:12.27 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-253-78.web.vodafone.de) |
18:55.45 | *** join/#htc-linux domi007 (i=domi007@pool-0610.adsl.interware.hu) |
18:56.05 | domi007 | hi everybody |
19:04.44 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
19:06.35 | domi007 | is here anybody? :D |
19:22.07 | *** join/#htc-linux tsdogs_ (n=tsdogs@net203-187-146.mclink.it) |
19:25.20 | dcordes-kais | cr2 hello |
19:28.17 | domi007 | hi |
19:32.32 | dcordes-kais | hello domi007 |
19:33.12 | domi007 | actually i came here to ask something about openembedded and the htc universal, but i see |
19:33.18 | domi007 | that there is almost no activity |
19:33.28 | domi007 | so i will have to try later :D |
19:39.14 | dcordes-kais | just ask |
19:40.58 | cr2 | dcordes-kais: hi |
19:42.24 | cr2 | dcordes-kais: i've read the complete kernel-ML thread. if Pavel can't compile the g1 kernel, it says something about the code. |
19:48.29 | domi007 | actually i read that with openembedded |
19:48.43 | domi007 | it is possible to compile a very new kernel |
19:48.48 | domi007 | (version 2.6.26) |
19:48.58 | domi007 | but i tried |
19:49.07 | domi007 | and i only got 2.6.21-hh20 |
19:49.36 | domi007 | so i read something fake? or what? |
19:49.43 | cr2 | domi007: not yet. 2.6.26 is too old anyway. |
19:50.08 | domi007 | actaully for me it would be enough |
19:50.16 | domi007 | because i want to have android running on it |
19:51.18 | cr2 | it does not work. |
19:51.29 | cr2 | expect 2.6.31 soon |
19:52.16 | domi007 | soon? it would be GREAT! |
19:53.09 | domi007 | and will it be available through openembedded? or how? |
20:19.35 | cr2 | domi007: nothing magic about oe. the kernel will be in the linuxtogo.org got |
20:26.14 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-253-78.web.vodafone.de) |
20:26.28 | cr2 | dcordes-kais: ping |
20:40.13 | cr2 | [ 266.246997] adsp: opening module AUDPREPROCTASK |
20:40.14 | cr2 | [ 266.247180] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
20:40.16 | cr2 | [ 266.247241] [RPC] READ on ept d4a4a860 |
20:40.17 | cr2 | [ 266.249133] [RR] - ver=1 type=1 src=0:00000001 crx=0 siz=28 dst=1:d4a4a860 |
20:40.19 | cr2 | [ 266.249896] [RPC] READ on ept d4a4a860 (24 bytes) |
20:40.20 | cr2 | [ 266.249957] adsp error: RPC call was not successful (3) |
20:40.22 | cr2 | [ 266.249987] adsp: REGISTER_APP failed |
20:41.34 | dcordes-kais | cr2 you have raphael dsp working? |
20:42.16 | cr2 | does not look like that |
20:42.21 | cr2 | ^^^ |
20:42.52 | cr2 | i guess some patches to adsp_5200.c are needed |
20:44.41 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B037781.dip.t-dialin.net) |
20:44.41 | cr2 | <PROTECTED> |
20:44.43 | cr2 | <PROTECTED> |
20:47.20 | cr2 | <PROTECTED> |
20:47.30 | cr2 | [ 704.923358] audio: failed to get audplay0 dsp module |
20:47.32 | cr2 | [ 704.924426] audmgr_rpc_thread() start |
20:47.34 | cr2 | [ 704.925128] [RPC] READ on ept d4a4a6e0 |
20:47.51 | cr2 | i think dzo shifted them by one |
20:48.11 | cr2 | <PROTECTED> |
20:48.12 | cr2 | <PROTECTED> |
20:48.14 | cr2 | <PROTECTED> |
20:50.46 | cr2 | dcordes-kais: i've also found the deadly DEX 0x14, but its call sequence is a bit strange |
20:53.16 | cr2 | [ 986.191302] [<c0052498>] (msleep+0x0/0x2c) from [<c002def4>] (clk_set_rate+0x180/0x244) |
20:53.18 | cr2 | [ 986.191333] [<c002dd74>] (clk_set_rate+0x0/0x244) from [<c015c4dc>] (msm_hs_set_termios+0x298/0x444) |
20:53.19 | cr2 | [ 986.191394] [<c015c244>] (msm_hs_set_termios+0x0/0x444) from [<c01578d4>] (uart_change_speed+0x88/0x8c) |
20:53.21 | cr2 | [ 986.191485] [<c015784c>] (uart_change_speed+0x0/0x8c) from [<c015a7dc>] (uart_open+0x420/0x4d8) |
20:53.22 | cr2 | [ 986.191516] r4:d4bc4400 |
20:53.24 | cr2 | [ 986.191546] [<c015a3bc>] (uart_open+0x0/0x4d8) from [<c0144d8c>] (tty_open+0x198/0x30c) |
21:11.16 | domi007 | cr2: thanks, i will get it as soon as it is available ;-) |
21:12.24 | cr2 | dcordes-kais: what do you think about wl12xx driver ? |
21:13.06 | domi007 | wow, linuxtogo has a new design? or i missed somthing? :D Now it is beautiful and seems to be usable :D |
21:13.53 | domi007 | btw do you know anything about the acx driver? on the Universal it is still very buggy :( |
21:14.24 | cr2 | we can try wl12xx there too |
21:15.18 | domi007 | cr2: you mean on the uni? |
21:15.22 | cr2 | yes |
21:17.10 | domi007 | but the uni's wlan chip is not a wl12xx chipset...or the wl12xx driver is universal for all ti chips? |
21:19.35 | cr2 | they are very similar i guess |
21:20.35 | domi007 | it would be great to have a better driver for the uni |
21:20.58 | domi007 | now it freezes in every 5-10 minutes... |
21:23.43 | domi007 | actually can i try the wl12xx driver on the 2.6.21-hh20 kernel too? |
21:23.52 | domi007 | is there any package or kernel module? |
21:24.00 | cr2 | no |
21:25.35 | domi007 | okay, then i have to wait the new kernel |
21:34.47 | domi007 | does anyone work on Android porting for htc-pxa dvices? |
21:34.55 | domi007 | or i am the only one? |
21:35.44 | cr2 | it's not an android channel |
21:35.58 | cr2 | +#define DMOV_USB_CHAN 11 |
21:36.01 | cr2 | hmm. |
21:36.25 | domi007 | ok |
21:36.30 | cr2 | [ 69.240618] msm_dmov_enqueue_cmd(11), error datamover stalled, status 0 |
21:36.58 | cr2 | +void msm_dmov_enqueue_cmd(unsigned id, struct msm_dmov_cmd *cmd); |
21:37.43 | cr2 | PRINT_ERROR("msm_dmov_enqueue_cmd(%d), error datamover stalled, status %x\n", id, status); |
21:38.36 | cr2 | +int msm_dmov_exec_cmd(unsigned id, unsigned int cmdptr) |
21:40.50 | cr2 | <PROTECTED> |
21:48.00 | *** join/#htc-linux nebi (n=nebi@217.142.147.19) |
21:51.20 | cr2 | 112 #define DMOV_HSUART2_RX_CHAN 11 |
21:51.29 | cr2 | 101 #define DMOV_USB_CHAN 11 |
21:52.02 | cr2 | why not |
21:52.14 | domi007 | cr2: are you currently working on the wl12xx driver, aren't you? |
21:52.21 | cr2 | no |
21:53.13 | domi007 | then what are you posting here actually? :) |
21:54.19 | *** join/#htc-linux MLM (n=mlvdmeid@meide.xs4all.nl) |
21:57.09 | cr2 | <PROTECTED> |
22:01.28 | cr2 | 179 D("%s: %u, freq=%lu\n", __func__, id, |
22:01.30 | cr2 | 180 msm_clock_freq_parameters[n].freq ); |
22:01.42 | cr2 | <PROTECTED> |
22:02.02 | cr2 | ok, seems to be a bug introduced by maejrep. |
22:02.21 | cr2 | the kernel code does not like a sleep() here. |
22:03.16 | cr2 | ~ping maejrep |
22:05.07 | cr2 | maejrep: are you still doing some hacking these days ? |
22:19.15 | cr2 | dcordes-kais: still here ? |
22:30.31 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
22:33.46 | cr2 | 0x64=100, 0xa=10 |
22:34.47 | cr2 | 1.92MHz ?? |
22:36.06 | cr2 | 7372800/19200=384 |
22:36.55 | cr2 | arcane google humbers ;) |
22:39.22 | cr2 | rebooting |
22:43.12 | cr2 | okey, now there is another bug |
22:43.17 | cr2 | [ 114.916217] [<c022bca0>] (schedule+0x0/0x43c) from [<c015ce60>] (msm_hs_shutdown+0xf4/0x15c) |
22:43.18 | cr2 | [ 114.916278] [<c015cd6c>] (msm_hs_shutdown+0x0/0x15c) from [<c0158518>] (uart_shutdown+0xe8/0x110) |
22:45.19 | cr2 | root@htcraphael:~# echo $((0x1000)) |
22:45.21 | cr2 | 4096 |
22:46.59 | cr2 | huh ? |
22:47.01 | cr2 | dd: can't open '/dev/mem': No such file or directory |
22:49.02 | tmzt | it's not enabled |
22:50.31 | cr2 | fcking g1 |
22:51.09 | cr2 | tmzt: adsp error: RPC call was not successful (3) |
22:51.42 | cr2 | tmzt: it's pita to check anything without an alsa interface. or /dev/dsp |
22:51.46 | tmzt | I looked at the patches to enable sdio on wl12xx, they just generalize memory access, adding a mem/pcmcia interface should be simple |
22:51.57 | cr2 | ok |
22:52.24 | cr2 | [ 272.343615] adsp: opening module AUDPREPROCTASK |
22:52.26 | cr2 | [ 272.343737] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
22:52.27 | tmzt | the question is probably going to be firmware |
22:52.27 | cr2 | [ 272.343798] [RPC] READ on ept d4a335c0 |
22:52.29 | cr2 | [ 272.345690] [RR] - ver=1 type=1 src=0:00000001 crx=0 siz=28 dst=1:d4a335c0 |
22:52.30 | cr2 | [ 272.346453] [RPC] READ on ept d4a335c0 (24 bytes) |
22:52.32 | cr2 | [ 272.346484] adsp error: RPC call was not successful (3) |
22:52.33 | cr2 | [ 272.346514] adsp: REGISTER_APP failed |
22:52.35 | cr2 | why ? |
22:52.48 | cr2 | we have 2. g1 and wince |
22:53.20 | cr2 | [ 291.998248] adsp: opening module AUDPLAY0TASK |
22:53.21 | cr2 | [ 291.998461] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
22:53.35 | cr2 | AUDPREPROCTASK and AUDPLAY0TASK are 2 and 4 ? |
22:53.48 | tmzt | it's different for different interfaces I think, maybe I'm thinking of libertas |
22:53.51 | cr2 | enabled /dev/mem now |
22:54.46 | tmzt | do we know if ce amss uses the same address for rpcrouter? |
22:55.02 | tmzt | fffffffe should be somewhere in the smem dump |
22:55.11 | cr2 | yes, it is there |
22:55.15 | cr2 | <PROTECTED> |
22:55.17 | cr2 | <PROTECTED> |
22:55.18 | cr2 | <PROTECTED> |
22:55.20 | cr2 | <PROTECTED> |
22:55.22 | cr2 | <PROTECTED> |
22:55.41 | cr2 | hmm |
22:55.43 | tmzt | also, I think we have to call register client on audmgr first |
22:55.50 | cr2 | QDSP_MODULE_AUDPLAY0TASK, is 2 |
22:56.37 | cr2 | then we need a C app, that will send appropriate ioctls |
22:56.52 | tmzt | so we need a program to dump the sequence of rpc calls from memory? |
22:57.02 | cr2 | somebody with g1 may have added printk's to the ioctl part |
22:57.26 | tmzt | won't strace work for that? |
22:57.29 | cr2 | but since it's such a problem to enable /dev/mem, then i give up any hope ;) |
22:57.42 | tmzt | lav.t was looking at playsnd.c |
22:57.44 | cr2 | strace what ? |
22:57.50 | cr2 | all this java crap ? |
22:57.59 | tmzt | it's not java |
22:58.10 | tmzt | audioflinger |
22:58.23 | tmzt | but yeah, it's not standalone |
22:58.25 | cr2 | hehe. wtf is that ? |
22:58.31 | tmzt | the playsnd is though |
22:58.45 | tmzt | it's used to play startup sound |
22:58.57 | cr2 | ive read about alsa for g1 at lkml |
22:59.00 | tmzt | until they switched to playmp3 |
22:59.06 | tmzt | cool |
22:59.18 | cr2 | maybe it will happen |
22:59.20 | tmzt | somebody has patches? |
22:59.29 | cr2 | not yet |
23:00.14 | cr2 | [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
23:00.22 | cr2 | what is 0:00000001 ? |
23:00.50 | cr2 | ADSPRTOSATOM 0x3000000a adsp_* |
23:00.52 | cr2 | 1,4 adsp_rtos_app_to_modem (1,1,2,4) |
23:01.16 | cr2 | yes, the SND and AUDMGR rpcs were not sent before. |
23:02.12 | cr2 | and i'd like to know why dzo commented this one out |
23:02.15 | cr2 | <PROTECTED> |
23:03.33 | tmzt | system/extras/sound/playwav.c |
23:04.10 | cr2 | link ? |
23:04.14 | cr2 | <PROTECTED> |
23:04.16 | cr2 | <PROTECTED> |
23:04.17 | cr2 | <PROTECTED> |
23:04.19 | cr2 | <PROTECTED> |
23:04.38 | cr2 | 1,1,2,4 |
23:04.42 | tmzt | I'm in repo but it's on git as well |
23:04.56 | cr2 | 4 is not QDSP_MODULE_AUDPPTASK anymore ... |
23:05.30 | tmzt | open /dev/msm-pcm-out |
23:05.45 | tmzt | AUDIO-GET-CONFIG |
23:05.59 | tmzt | channels = 2 |
23:06.06 | tmzt | sample-rate = |
23:06.20 | tmzt | AUDIO-SET-CONFIG |
23:06.50 | tmzt | it gets buf sz from config |
23:07.00 | tmzt | prefiles it |
23:07.06 | cr2 | #define RPC_ADSP_RTOS_APP_TO_MODEM_PROC 2 |
23:07.07 | cr2 | #define RPC_ADSP_RTOS_MODEM_TO_APP_PROC 2 |
23:07.12 | tmzt | then AUDIO-START |
23:08.26 | cr2 | are these ioctls in pcm ? |
23:08.30 | cr2 | <PROTECTED> |
23:08.31 | cr2 | <PROTECTED> |
23:08.33 | cr2 | <PROTECTED> |
23:08.34 | cr2 | <PROTECTED> |
23:08.43 | cr2 | #define RPC_ADSP_RTOS_APP_TO_MODEM_PROC 2 ! |
23:08.55 | cr2 | looks like a bug here. |
23:09.05 | cr2 | at least it does not match our data. |
23:09.24 | cr2 | changed it to 1 |
23:10.59 | cr2 | i'll remove the // of dzo |
23:11.14 | cr2 | dzo: are you here ? |
23:12.31 | tmzt | http://www.netmite.com/android/mydroid/system/extras/sound/playwav.c |
23:14.15 | cr2 | ok |
23:16.01 | cr2 | <PROTECTED> |
23:16.23 | cr2 | tmzt: can you compile this program ? |
23:16.33 | cr2 | i think it should be included with initrd |
23:16.42 | tmzt | let me try, need to reboot |
23:21.53 | cr2 | open("/dev/ttyHS1", O_RDWR|O_NOCTTY |
23:21.56 | cr2 | blocks |
23:22.19 | cr2 | yeah, the bug here. |
23:22.22 | cr2 | [ 109.620684] [<c022bad8>] (schedule+0x0/0x43c) from [<c015cc9c>] (msm_hs_shutdown+0xf4/0x15c) |
23:22.52 | cr2 | wow |
23:23.31 | cr2 | tmzt: looks like the DSP record is working |
23:23.58 | cr2 | [ 193.792193] adsp: opening module AUDPREPROCTASK |
23:24.00 | cr2 | [ 193.792315] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
23:24.01 | cr2 | [ 193.792376] [RPC] READ on ept d4a331a0 |
23:24.03 | cr2 | [ 193.794268] [RR] - ver=1 type=1 src=0:00000001 crx=0 siz=28 dst=1:d4a331a0 |
23:24.04 | cr2 | [ 193.795031] [RPC] READ on ept d4a331a0 (24 bytes) |
23:24.06 | cr2 | [ 193.795092] adsp: module AUDPREPROCTASK has been registered |
23:24.08 | cr2 | [ 193.795123] adsp: opening module AUDRECTASK |
23:24.09 | cr2 | [ 193.795184] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
23:24.11 | cr2 | [ 193.795245] [RPC] READ on ept d4a33200 |
23:24.12 | cr2 | [ 193.797656] [RR] - ver=1 type=1 src=0:00000001 crx=0 siz=28 dst=1:d4a33200 |
23:24.14 | cr2 | [ 193.798358] [RPC] READ on ept d4a33200 (24 bytes) |
23:24.15 | cr2 | [ 193.798419] adsp: module AUDRECTASK has been registered |
23:24.17 | cr2 | [ 193.799456] audmgr_rpc_thread() start |
23:24.19 | cr2 | [ 193.800219] [RPC] READ on ept d4a337a0 |
23:24.21 | cr2 | [ 195.708911] adsp: closing module AUDRECTASK |
23:24.23 | cr2 | [ 195.709979] [RR] x REMOVE_CLIENT id=1:d4a33200 |
23:24.25 | cr2 | [ 195.710772] adsp: closing module AUDPREPROCTASK |
23:24.27 | cr2 | [ 195.711596] [RR] x REMOVE_CLIENT id=1:d4a331a0 |
23:24.29 | cr2 | [ 195.712237] adsp: disable interrupt |
23:24.32 | cr2 | i did od -x /dev/msm_pcm_in |
23:24.47 | cr2 | don't see the hexdump on the screen though. |
23:25.17 | cr2 | at least i got the adsp RPC right |
23:26.53 | cr2 | this one does not barf anymore: |
23:26.56 | cr2 | cat /linuxrc > /dev/msm_mp3 |
23:27.15 | cr2 | and produces sensible output in dmesg |
23:27.32 | cr2 | [ 407.487963] adsp: opening module AUDPLAY0TASK |
23:27.33 | cr2 | [ 407.488085] [RPC] CALL to 3000000a:0 @ 0:00000001 (56 bytes) |
23:27.35 | cr2 | [ 407.488146] [RPC] READ on ept d4a336e0 |
23:27.37 | cr2 | [ 407.490466] [RR] - ver=1 type=1 src=0:00000001 crx=0 siz=28 dst=1:d4a336e0 |
23:27.38 | cr2 | [ 407.491259] [RPC] READ on ept d4a336e0 (24 bytes) |
23:27.40 | cr2 | [ 407.491320] adsp: module AUDPLAY0TASK has been registered |
23:27.41 | cr2 | [ 407.492419] audmgr_rpc_thread() start |
23:27.43 | cr2 | [ 407.493060] [RPC] READ on ept d4a33800 |
23:27.44 | cr2 | [ 411.089953] audio_disable() |
23:27.46 | cr2 | [ 411.090899] adsp: closing module AUDPLAY0TASK |
23:27.47 | cr2 | [ 411.091571] [RR] x REMOVE_CLIENT id=1:d4a336e0 |
23:27.49 | cr2 | [ 411.092211] adsp: disable interrupt |
23:28.52 | cr2 | tmzt: what is the purpose of /dev/msm_pcm_ctl ? |
23:30.21 | tmzt | don't know |
23:30.37 | tmzt | playwav caused a bug in audmgr-enable |
23:30.50 | tmzt | but it got through prefill and start |
23:31.49 | tmzt | playwav also has -record |
23:32.09 | tmzt | it's not enough to read or write the device |
23:32.25 | *** join/#htc-linux onen|openBmap (n=onen@mry91-1-89-87-198-158.dsl.club-internet.fr) |
23:32.38 | tmzt | oh, ctl is used for set-device |
23:32.47 | tmzt | and some other ioctls |
23:32.56 | tmzt | but never got those to work either |
23:33.18 | cr2 | ? |
23:33.32 | cr2 | you need to patch the adsp code first |
23:33.44 | tmzt | patch how? |
23:34.35 | cr2 | i need to create a patch |
23:34.58 | cr2 | just came to my mind, tat the bt powr is disabled ;) |
23:35.48 | cr2 | diff --git a/arch/arm/mach-msm/qdsp5/adsp.h b/arch/arm/mach-msm/qdsp5/adsp.h |
23:35.58 | cr2 | -#define RPC_ADSP_RTOS_APP_TO_MODEM_PROC 2 |
23:36.00 | cr2 | +#define RPC_ADSP_RTOS_APP_TO_MODEM_PROC 1 |
23:36.33 | cr2 | then you also need the HELLO patch |
23:37.14 | cr2 | btw, who calls snd_set_device and snd_set_volume ? |
23:37.42 | cr2 | then there is a bug in |
23:37.45 | cr2 | +++ b/arch/arm/mach-msm/clock-wince.c |
23:37.55 | cr2 | - msleep(5); |
23:37.57 | cr2 | +// msleep(5); |
23:38.31 | cr2 | at least the hsuart code makes an oops here |
23:39.51 | tmzt | I think only audioflinger |
23:40.06 | tmzt | playwav didn't even setup the correct device |
23:40.56 | cr2 | ok, somebody should call audmgr and snd rpcs |
23:41.09 | cr2 | dzo put them into vogue-hw.c |
23:42.13 | cr2 | weird. the latest gXX .29 code has |
23:42.17 | cr2 | 127 #define RPC_ADSP_RTOS_APP_TO_MODEM_PROC 2 |
23:42.19 | cr2 | 128 #define RPC_ADSP_RTOS_MODEM_TO_APP_PROC 2 |
23:42.28 | cr2 | strange. |
23:42.52 | cr2 | but ok. |
23:48.04 | cr2 | why do i get such a huge delay of fb handover ? |
23:48.35 | tmzt | looks like nothing calls it??? |
23:51.22 | cr2 | hehe. enabled bt power, and got hardlock on hciattach ;) |
23:51.35 | cr2 | still some progress :) |
23:52.47 | cr2 | tmzt: check how kaiser calls SND rpc |
23:55.13 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
23:55.38 | tmzt | nice |
23:56.13 | tmzt | we don't have any code in android to enable routing, just the qemu and pc version |
23:56.24 | tmzt | it's in libhardware |
23:56.49 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-253-78.web.vodafone.de) |