| 00:02.02 | *** part/#htc-linux t3g (~t3g@p3E9E253C.dip.t-dialin.net) |
| 00:02.26 | *** join/#htc-linux mag00 (51606fd8@gateway/web/freenode/ip.81.96.111.216) |
| 00:02.30 | *** join/#htc-linux t3g (~t3g@p3E9E253C.dip.t-dialin.net) |
| 00:03.18 | *** part/#htc-linux mag00 (51606fd8@gateway/web/freenode/ip.81.96.111.216) |
| 00:13.06 | *** join/#htc-linux jonpry (~jon@63.245.31.4) |
| 00:20.55 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
| 00:24.04 | *** join/#htc-linux hardwalker (~hardwalke@114-33-201-92.HINET-IP.hinet.net) |
| 00:24.23 | *** join/#htc-linux arrrghhh_ (~arrrghhh@c-71-237-40-111.hsd1.co.comcast.net) |
| 00:29.58 | *** part/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |
| 00:35.49 | *** join/#htc-linux mitsutaka (~mitsutaka@rt.miraclelinux.com) |
| 00:37.55 | *** join/#htc-linux S[h]O[r]T (~ShOrT@216.245.217.114) |
| 00:44.02 | *** join/#htc-linux surge (surge@pool-98-118-157-221.bflony.fios.verizon.net) |
| 00:56.08 | SG | ~seen jesusfreak316 |
| 00:56.24 | apt | jesusfreak316 <~JesusFrea@USF-Wifi-33-152.laptops.usf.edu> was last seen on IRC in channel #htc-linux, 19d 7h 28m 42s ago, saying: 'Forum's back up.'. |
| 00:56.24 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 01:00.02 | *** join/#htc-linux Berger (noreply@c65wn1.wifi.halden.net) |
| 01:02.07 | *** join/#htc-linux siulmagic (~IceChat7@24.54.255.153) |
| 01:10.25 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 01:34.43 | *** join/#htc-linux MN_ (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 01:39.34 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless248.wirelesstcp.net) |
| 01:39.54 | arrrghhh | WisTilt2, yo |
| 01:40.01 | WisTilt2 | hey |
| 01:41.18 | WisTilt2 | found the non wake problem:) kept saying it was related to unblank timing, sure is. ill give you the details after i code the fix |
| 01:45.08 | *** join/#htc-linux parmaste1 (par@dipole.idlepattern.com) |
| 01:49.36 | arrrghhh | WisTilt2, you're awesome <3 |
| 01:51.56 | WisTilt2 | arrrghhh: ill have a test image for you to try in a bit. |
| 01:52.09 | arrrghhh | np, take your time. |
| 01:52.32 | *** join/#htc-linux manekineko (~manekinek@newyork.homeserver.com) |
| 01:53.04 | *** join/#htc-linux massstash (~massstash@68-31-7-29.pools.spcsdns.net) |
| 01:59.55 | *** join/#htc-linux surge (~surge@pool-98-118-157-221.bflony.fios.verizon.net) |
| 02:00.38 | *** join/#htc-linux massstash (~massstash@173-105-227-24.pools.spcsdns.net) |
| 02:05.31 | *** join/#htc-linux surge (~surge@pool-98-118-157-221.bflony.fios.verizon.net) |
| 02:17.06 | *** join/#htc-linux sykosoft (455cd27d@gateway/web/freenode/ip.69.92.210.125) |
| 02:17.16 | sykosoft | Netripper: I'll be happy to help with the irclog |
| 02:17.27 | sykosoft | I'm a systems engineer, mysql dba |
| 02:17.54 | sykosoft | you mentioned before it wasn't indexed properly |
| 02:18.04 | sykosoft | curious what your sql statements and table layout look like |
| 02:18.37 | *** join/#htc-linux rpierce99_ (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 02:20.58 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
| 02:22.55 | stinebd | goodby precious underscore |
| 02:23.19 | arrrghhh | overly-dramatic much? |
| 02:23.41 | *** join/#htc-linux D3tul3 (~Oliver@cpe-174-109-223-235.nc.res.rr.com) |
| 02:24.34 | *** join/#htc-linux |Atom| (~atom@82.194.234.249) |
| 02:25.09 | sykosoft | an underscore is not nearly as good as an overscore |
| 02:25.12 | sykosoft | (sarcasm) |
| 02:33.07 | arrrghhh | WisTilt2, we have NAND :D |
| 02:33.30 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 02:35.16 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
| 02:35.19 | WisTilt2 | so you're going to the dark side huh? thats the way ill probably go with one of my phones after its all done and stable. |
| 02:35.30 | arrrghhh | just one? |
| 02:35.39 | arrrghhh | once it's stable enough, i can't wait to ditch winmo. |
| 02:36.17 | WisTilt2 | i still will keep one with dual boot just in case for awhile. |
| 02:36.23 | jonpry | hmm, so we are still doing this weirdness where microp-ksc just deals with the cap/fn led states? |
| 02:36.50 | arrrghhh | heh |
| 02:37.21 | WisTilt2 | yeah you saw my actual implementation? temporary until userland side can get hooked to do the work the way it should |
| 02:38.21 | stinebd | we should keep it like that :P |
| 02:38.30 | arrrghhh | heh |
| 02:41.56 | jonpry | how is the userland stuff supposed to work? |
| 02:47.46 | *** join/#htc-linux sykosoft_ (455cd27d@gateway/web/freenode/ip.69.92.210.125) |
| 02:55.03 | stinebd | that's why we should keep it like that ;) |
| 02:56.51 | jonpry | stinebd: i feel your pain, but i think others will want it done differently for .35 |
| 03:00.45 | *** join/#htc-linux leobaillard (~leobailla@secteur7.org) |
| 03:01.25 | *** join/#htc-linux tyween (~tyween@pool-71-163-117-57.washdc.fios.verizon.net) |
| 03:04.10 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
| 03:04.13 | *** join/#htc-linux surge (surge@pool-98-118-157-221.bflony.fios.verizon.net) |
| 03:18.48 | *** join/#htc-linux Rumuzunuz144 (~ChatFox@78.181.91.33) |
| 03:24.29 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 03:25.35 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 03:33.26 | *** join/#htc-linux nineX_ (~nunya@75-132-13-29.dhcp.stls.mo.charter.com) |
| 03:39.17 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 03:40.06 | *** join/#htc-linux rpierce99_ (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 03:41.15 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 03:48.57 | *** join/#htc-linux |lippa| (~lippa@ppp118-209-218-222.lns20.mel6.internode.on.net) |
| 03:51.07 | manekineko | is there anyone here that knows anything about the ril we're using? |
| 03:51.12 | manekineko | I'm looking at http://gitorious.org/linux-on-qualcomm-s-msm/android-htc-ril/blobs/diamond/htcgeneric-ril.c |
| 03:51.39 | manekineko | and in requestRegistrationState, the only part that seems to be actually handling CDMA |
| 03:51.47 | manekineko | only executes on RIL_REQUEST_GPRS_REGISTRATION_STATE |
| 03:52.04 | manekineko | which strikes me as very strange, as I would think that would mean the CDMA code is never executing at all |
| 03:52.12 | manekineko | because GPRS is a GSM thing |
| 03:53.32 | manekineko | but then if this were the case, I'm having a hard time seeing how we seem to be able to get some info registration states on CDMA phones |
| 03:53.40 | manekineko | such as 3G/edge status, etc. |
| 03:55.47 | *** join/#htc-linux Curious_ (8bb3cfda@gateway/web/freenode/ip.139.179.207.218) |
| 03:57.32 | jonpry | hrm, is i2c working on .35? |
| 04:03.24 | *** join/#htc-linux arrrghhh (~arrrghhh@c-71-237-40-111.hsd1.co.comcast.net) |
| 04:11.18 | *** join/#htc-linux Samsunguy (~Samsunguy@cpe-76-186-50-40.tx.res.rr.com) |
| 04:22.25 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 04:23.17 | *** join/#htc-linux Rob2223 (~Miranda@p4FFF324D.dip.t-dialin.net) |
| 04:29.49 | *** join/#htc-linux plupke (~chatzilla@ip56589430.direct-adsl.nl) |
| 04:30.09 | *** join/#htc-linux AgentBlair (~AgentBlai@adsl-67-124-200-190.dsl.sndg02.pacbell.net) |
| 04:39.13 | *** join/#htc-linux DuperMan (~Duper@109-186-15-140.bb.netvision.net.il) |
| 04:41.29 | arrrghhh | WisTilt2: yo |
| 04:41.40 | arrrghhh | lots of amazing developments tonight. how you doin? |
| 04:42.23 | WisTilt2 | still squashing this delay problem but looking good |
| 04:42.28 | arrrghhh | cool |
| 04:42.47 | arrrghhh | so... i might need your help. we have a way to get location data from CDMA |
| 04:42.52 | WisTilt2 | what else is going on? sounds like a party somewhere |
| 04:42.58 | arrrghhh | the call works manually, but it needs to be implemented into the RIL |
| 04:43.06 | arrrghhh | so yea |
| 04:43.14 | arrrghhh | nate got nand working tonight |
| 04:43.23 | arrrghhh | and manekineko got cdma loc working basically |
| 04:43.27 | arrrghhh | proved that it works |
| 04:43.31 | manekineko | heh not by a longshot |
| 04:43.42 | manekineko | still gotta figure out the code |
| 04:43.47 | manekineko | but yeah, the command works |
| 04:44.08 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 04:45.11 | WisTilt2 | damn, sounds like everyone is progressing tonight. i can see about the location data. i should have this delay fixed in a bit. |
| 04:45.49 | arrrghhh | schweet |
| 04:45.52 | WisTilt2 | its just a missing command isnt it? |
| 04:45.56 | manekineko | oh yeah, that'd be nice to get someone that actually knows what they're doing looking at it |
| 04:46.02 | manekineko | haha |
| 04:46.12 | arrrghhh | yea, i thought so :P |
| 04:46.17 | manekineko | well, arrrghhh found this command that returns the tower location |
| 04:46.24 | manekineko | just have to figure out where to populate it in the ril |
| 04:46.28 | WisTilt2 | bsinfo? |
| 04:46.29 | arrrghhh | and i never really pursued how to use it |
| 04:46.31 | arrrghhh | yea |
| 04:46.54 | WisTilt2 | its only implemented in ril for gsm so adding cdma shouldnt be all that hard |
| 04:46.58 | *** join/#htc-linux BoominSVX (421f78ad@gateway/web/freenode/ip.66.31.120.173) |
| 04:47.10 | WisTilt2 | cant be any harder than this timing crap im messing with |
| 04:47.20 | arrrghhh | heh |
| 04:47.26 | arrrghhh | especially when we have the proven command |
| 04:47.35 | arrrghhh | that works. just needs some maths applied. |
| 04:47.40 | arrrghhh | divided by 14,400 |
| 04:47.41 | WisTilt2 | that helps know that much for sure |
| 04:47.41 | arrrghhh | odd. |
| 04:48.08 | *** join/#htc-linux DuperMan (~Duper@109-186-15-140.bb.netvision.net.il) |
| 04:48.47 | arrrghhh | i <3 rebooting to android |
| 04:48.53 | manekineko | though to do it right, we probably don't want to turn the minutes and seconds into decimal points |
| 04:49.03 | manekineko | like we were doing just to test things out in #xdandrdoid |
| 04:49.17 | BoominSVX | arrrghhh: have you gotten a full boot with that new nbh? |
| 04:49.29 | arrrghhh | BoominSVX: oh yea. |
| 04:50.16 | BoominSVX | i just lock up at the androidupdate.tgz file. holding vol up does bring me a enu, but it's not navigatable |
| 04:50.25 | arrrghhh | been running it for a few hours now |
| 04:50.33 | arrrghhh | oh |
| 04:50.43 | arrrghhh | touch the bottom right and bottom left to move |
| 04:50.52 | arrrghhh | and bottom center to click enter |
| 04:50.57 | arrrghhh | heh |
| 04:52.36 | BoominSVX | I knew you had an answer. you always do |
| 04:53.13 | arrrghhh | :P |
| 04:53.18 | arrrghhh | L_miller told me |
| 04:53.35 | arrrghhh | er maybe it was nate... |
| 04:53.37 | arrrghhh | crap. |
| 04:54.36 | BoominSVX | yea, if you play with the screen you eventually find the answer :) |
| 04:54.49 | arrrghhh | lol |
| 04:55.07 | arrrghhh | i certainly didn't quite. i tried touching the section of the screen up there lol... |
| 04:56.38 | BoominSVX | Bottom left is up, Bottom right is down right around the center seems to be enter/select |
| 04:56.39 | arrrghhh | had to be instructed |
| 04:56.47 | arrrghhh | indeed |
| 04:56.51 | arrrghhh | :D |
| 05:03.18 | arrrghhh | BoominSVX: how goes it? |
| 05:03.38 | BoominSVX | OMG she's beautiful. A tear has fallen. I love you guys. |
| 05:03.45 | arrrghhh | yes! |
| 05:03.48 | arrrghhh | win. |
| 05:04.00 | arrrghhh | kinda tricky |
| 05:04.01 | arrrghhh | but win. |
| 05:04.04 | arrrghhh | my wifi worked too |
| 05:04.05 | arrrghhh | i was shocked |
| 05:04.06 | BoominSVX | epic win |
| 05:04.11 | arrrghhh | i guess i should post my androidupdate |
| 05:04.25 | arrrghhh | data doesn't work for me... |
| 05:04.34 | arrrghhh | as with everyone else. |
| 05:04.41 | BoominSVX | I think ACL should just commit. |
| 05:04.59 | arrrghhh | i want to try to figure out what's up with data |
| 05:05.01 | BoominSVX | Me either, but its NAND! |
| 05:05.14 | arrrghhh | lol |
| 05:05.19 | arrrghhh | nate is awesome. |
| 05:05.27 | arrrghhh | he just swooped in and hex edited the crap out of it |
| 05:06.12 | BoominSVX | hey, if your on this channel and speak without getting yelled at, your awsome. |
| 05:06.37 | arrrghhh | lol |
| 05:06.41 | BoominSVX | I'm gonna play around, but i'll be here if you need me. |
| 05:06.47 | BoominSVX | thanks buddy |
| 05:07.04 | arrrghhh | np |
| 05:07.07 | arrrghhh | my pleasure |
| 05:09.08 | *** join/#htc-linux MassStash (~MassStash@c-67-175-41-173.hsd1.il.comcast.net) |
| 05:11.04 | arrrghhh | zomg |
| 05:11.13 | arrrghhh | USB mass storage? "just works". amazing. |
| 05:11.29 | manekineko | oh that'll be nice |
| 05:11.47 | manekineko | how about USB tethering? |
| 05:11.50 | arrrghhh | i just clicked it, no fuss. took a little while, but yea... |
| 05:11.57 | arrrghhh | haven't tried that since data doesn't work. |
| 05:12.03 | manekineko | oh right |
| 05:12.05 | arrrghhh | lol |
| 05:14.00 | jonpry | WisTilt2: how is that battery stuff? maybe you can send me the code you have, i want start getting some pigs logging :p |
| 05:14.48 | arrrghhh | heh |
| 05:17.11 | WisTilt2 | jonpry: im running 1min intervals on my other phone as we speak. been running for just over 2hrs. ill email you the output before i quit tonight. |
| 05:17.58 | jonpry | oh cool. i had terrible problems with battlog today |
| 05:18.15 | jonpry | you have my email? |
| 05:19.58 | WisTilt2 | battlog from the current git tree? dont know how accurate the values are with that. yes i have your email |
| 05:20.24 | jonpry | battlog is a windows mobile program |
| 05:20.52 | *** join/#htc-linux Kasjopaja23 (~Tina@p579C116D.dip.t-dialin.net) |
| 05:21.22 | WisTilt2 | oh, so its microsoft. not accurate at all:) |
| 05:21.51 | jonpry | i just wanted it to save voltage and current to file |
| 05:22.11 | WisTilt2 | does it return current in ma? |
| 05:22.16 | jonpry | yeah |
| 05:22.22 | *** join/#htc-linux mortis531 (63a97491@gateway/web/freenode/ip.99.169.116.145) |
| 05:22.24 | *** join/#htc-linux programmer8922 (~Evan@67.219.164.162) |
| 05:22.40 | WisTilt2 | does it have a temp reading also? really have no idea what format these temp values are in im reading |
| 05:22.40 | *** join/#htc-linux AgentBlair (~AgentBlai@adsl-67-124-200-190.dsl.sndg02.pacbell.net) |
| 05:22.49 | jonpry | but it writes file 1/sec but the values change kind of randomly at ~10sec intervals |
| 05:23.08 | jonpry | it has temp reading, but they don't seem to know what it means either |
| 05:23.25 | mortis531 | why when I download the cab file i ger rar and not the cab? |
| 05:23.51 | mortis531 | get* |
| 05:23.56 | arrrghhh | mortis531: the cab is broken, and this isn't a support channel. |
| 05:23.57 | jonpry | all of xda-devs is showing up |
| 05:24.07 | arrrghhh | lol |
| 05:24.15 | mortis531 | crap |
| 05:24.35 | arrrghhh | #xdandroid for support |
| 05:24.53 | *** join/#htc-linux toastcfh_ (~toastcfh@29-37.200-68.tampabay.res.rr.com) |
| 05:25.19 | mortis531 | ok well i have it installed on my sd card an that card is going into my new phone what can i do |
| 05:25.49 | arrrghhh | mortis531: please go to the channel i suggested above... |
| 05:33.53 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 05:36.20 | WisTilt2 | jonpry: whats the easiest way to pull the .35 fb commit to get back to the previous one do you know? |
| 05:36.52 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 05:37.13 | jonpry | hrm |
| 05:37.32 | jonpry | well, you can create a patch |
| 05:37.40 | jonpry | and then checkout an old commit |
| 05:37.45 | jonpry | and try to apply the patch |
| 05:38.58 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 05:38.59 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 05:39.49 | arrrghhh | i thought there was some git revert command |
| 05:39.55 | arrrghhh | to pull specific commits... |
| 05:40.00 | WisTilt2 | either something in .35 fb code is flakey or something in clocks. vsync is whats causing these delay wakeups and unblank gets called even when there are vsync request errors. |
| 05:40.22 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 05:40.29 | WisTilt2 | that sounds easier arrrghhh. |
| 05:40.36 | *** join/#htc-linux goxboxlive (~jrs@mail2.hjellnesconsult.no) |
| 05:40.39 | jonpry | yeah you can go back |
| 05:40.47 | jonpry | but thats just a checkout |
| 05:41.07 | jonpry | and it doesn't help you get new code onto old state |
| 05:41.45 | arrrghhh | i'm no git expert, by any means :P |
| 05:43.49 | WisTilt2 | well im not working on it anymore tonight, frustrated enough already. problem is happening during resume_console, but only now and then with different lengths of delay. |
| 05:44.13 | arrrghhh | WisTilt2: screw it. |
| 05:44.22 | arrrghhh | may become moot when we move to .35 |
| 05:45.11 | WisTilt2 | yeah probably not worth wasting time on. you getting that on nand or is acl using the same panel and fb code as we are? |
| 05:45.23 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 05:45.32 | jonpry | maybe revert does work |
| 05:46.18 | *** join/#htc-linux byrnsey88 (614dea4e@gateway/web/freenode/ip.97.77.234.78) |
| 05:47.24 | arrrghhh | WisTilt2: panel wake seems much worse if anything heh |
| 05:47.25 | *** join/#htc-linux GPFerror (~GPF@ip72-208-193-231.ph.ph.cox.net) |
| 05:48.57 | WisTilt2 | so it has same timing problems. ive just adjusted somewhat with all the tweaks we've been testing this past week. i think its a clock problem |
| 05:49.08 | arrrghhh | hrm |
| 05:50.38 | WisTilt2 | jonpry: you know what would be causing vsync timeout requests that cause msm pan_display to flake? |
| 05:50.53 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 05:51.09 | WisTilt2 | i mean wouldnt that be clock related? |
| 05:51.14 | jonpry | not really, thats when i gave up on .35 |
| 05:51.30 | jonpry | somehow they got it working though, or apparently working |
| 05:51.51 | BoominSVX | WisTilt2: I see a lot of these on NAND when playing with sleep/wake. |
| 05:51.54 | BoominSVX | BatteryStatsImpl( 220): Couldn't get kernel wake lock stats |
| 05:52.07 | BoominSVX | No SOD's, but many failed wakes. |
| 05:52.11 | WisTilt2 | only happens coming out of sleep and only now and then at different intervals |
| 05:52.32 | jonpry | thats about right |
| 05:52.55 | jonpry | back in the day, its like if it would get to the second frame, aka first vsync, it would work |
| 05:52.56 | WisTilt2 | BoominSVX, you think the failed wakes are related to the kernel wake locks? |
| 05:53.19 | WisTilt2 | jonpry: yeah thats exactly what it is doing, waiting for second frame |
| 05:54.05 | BoominSVX | WisTilt2: I'm not sure how much of your work has been implimented into acl's nand kernel. Might have to ask him |
| 05:54.07 | WisTilt2 | i even removed all the panel collapse code, which leaves it powered on and it still happens. |
| 05:54.23 | jonpry | yeah i think its shutting down mdp |
| 05:54.28 | jonpry | that will get you |
| 05:55.22 | *** join/#htc-linux kiozen (~kiozen@rgnb-5d878b3b.pool.mediaWays.net) |
| 05:56.29 | jonpry | maybe you need to spin waiting for vsync irq, then wait some certain time and bring up mdp, lol |
| 05:56.35 | jonpry | i tried everything |
| 06:10.45 | arrrghhh | WisTilt2: so... about this RIL fun |
| 06:12.08 | WisTilt2 | ? you already fix it... |
| 06:12.34 | *** join/#htc-linux GlemSom (~glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk) |
| 06:14.07 | arrrghhh | heh |
| 06:14.13 | arrrghhh | i kinda have an idea how to fix it |
| 06:14.20 | arrrghhh | but how to apply it to the RIL code... |
| 06:14.24 | arrrghhh | that's a different story. |
| 06:15.21 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
| 06:15.40 | *** join/#htc-linux Guest43155 (~Bry8Star@adsl-71-137-233-207.dsl.irvnca.pacbell.net) |
| 06:15.40 | *** join/#htc-linux Guest43155 (~Bry8Star@unaffiliated/bry8star) |
| 06:16.06 | WisTilt2 | fire away. getting it into the ril shouldnt be a problem if you know the logic of what we need to put in there. |
| 06:17.05 | arrrghhh | jonpry said there's an array of 14 variables i believe? |
| 06:17.13 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 06:17.46 | arrrghhh | and i can show you what we did to get the output in the terminal |
| 06:20.42 | arrrghhh | echo -e 'AT+HTC_BSINFO?\r" > /dev/smd0 |
| 06:21.24 | arrrghhh | and it would spit out a line something like this "+HTC_BSINFO: 4384,50,2753,+606881,-1264782,-81,"10/01/22,05:08:07-24,0"" |
| 06:22.14 | arrrghhh | the giant + and - number are divided by 14,400 and those are the lat/long... |
| 06:23.47 | WisTilt2 | so when you do that manually it makes it work until you reboot? |
| 06:24.15 | WisTilt2 | or we need to do the math and stick it somewhere |
| 06:24.44 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 06:24.56 | arrrghhh | well i had to stop the ril |
| 06:24.58 | arrrghhh | and inject that command |
| 06:25.02 | arrrghhh | kinda messed up my radio... |
| 06:25.14 | arrrghhh | but obviously that was just to open the dev channel to the radio |
| 06:27.41 | WisTilt2 | im looking through the ril source to find where something like this is being done for gsm |
| 06:27.55 | *** join/#htc-linux Guest43155 (~Bry8Star@adsl-71-137-233-207.dsl.irvnca.pacbell.net) |
| 06:27.57 | *** join/#htc-linux Guest43155 (~Bry8Star@unaffiliated/bry8star) |
| 06:28.01 | *** part/#htc-linux Guest43155 (~Bry8Star@unaffiliated/bry8star) |
| 06:28.09 | *** join/#htc-linux Guest43155 (~Bry8Star@unaffiliated/bry8star) |
| 06:29.18 | arrrghhh | ok |
| 06:31.15 | arrrghhh | shame jonpry left |
| 06:31.28 | arrrghhh | he seemed to have a good idea on how it should work. |
| 06:31.34 | WisTilt2 | we are using the htc generic ril right |
| 06:31.45 | arrrghhh | uhm |
| 06:31.56 | WisTilt2 | i think thats what stinebd told me |
| 06:31.57 | arrrghhh | i think we're using a ril that was kinda butchered from vogue |
| 06:33.04 | WisTilt2 | rhod 400/500's are world phones? |
| 06:33.17 | arrrghhh | yes |
| 06:33.37 | arrrghhh | they only work as one or the other tho |
| 06:36.05 | WisTilt2 | this ril was mainly made for gsm it looks like. all the gsm AT commands are there |
| 06:36.56 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 06:38.33 | *** join/#htc-linux goxboxlive (~jrs@mail2.hjellnesconsult.no) |
| 06:39.04 | WisTilt2 | lol, if this is the ril we're using then HSDPA cant work. maybe thats why i get way faster data in winmo |
| 06:40.45 | arrrghhh | lol |
| 06:41.43 | *** join/#htc-linux kvaster_ (~kvaster@93.84.112.82) |
| 06:42.38 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 06:45.06 | WisTilt2 | arrrghhh: can you echo this to that dev and see what it replies with? AT+HTC_SRV_STATUS? yes with the ? on the end also |
| 06:56.16 | WisTilt2 | arrrghhh: ping ping |
| 07:01.48 | *** join/#htc-linux Phally (~Phally@dhcp-077-251-163-183.chello.nl) |
| 07:04.19 | manekineko | WisTilt2 |
| 07:04.28 | WisTilt2 | arrrghhh: going to bed. try that AT cmd above and also AT+COPS? and see what you get returned |
| 07:04.31 | manekineko | I ran that, got +HTC_SRV_STATUS: 0,2,"0310000" |
| 07:04.47 | WisTilt2 | ok hang on... |
| 07:05.18 | manekineko | AT+COPS returns just OK |
| 07:06.06 | WisTilt2 | you on at&t? |
| 07:06.17 | manekineko | Sprint |
| 07:06.19 | manekineko | CDMA |
| 07:06.48 | WisTilt2 | dont forget the ? at the end of that cops cmd |
| 07:07.04 | manekineko | oh you're right, I typoed that |
| 07:07.24 | WisTilt2 | ? query's |
| 07:07.33 | manekineko | hmm |
| 07:07.38 | manekineko | +CME_ERROR: 30 |
| 07:07.39 | WisTilt2 | should return more than ok |
| 07:08.40 | *** join/#htc-linux kiozen (~kiozen@p5DDF154E.dip.t-dialin.net) |
| 07:08.46 | WisTilt2 | hmm, 30 i think means no sim but you have a sim right? |
| 07:09.43 | manekineko | well, not installed, since I'm using CDMA |
| 07:09.58 | manekineko | it's required to make CDMA data work reliably to remove the ISM |
| 07:10.00 | manekineko | SIM |
| 07:11.29 | *** join/#htc-linux dekar (~dekar@drms-590ce9dd.pool.mediaWays.net) |
| 07:12.59 | WisTilt2 | manekineko can you see what you get with AT+COPS?+COPS: |
| 07:13.40 | manekineko | like that? it returns ERROR |
| 07:13.59 | manekineko | I entered it as echo -e "AT+COPS?+COPS\r" > /dev/smd0 |
| 07:14.10 | WisTilt2 | : on the end |
| 07:14.54 | manekineko | okay, I entered echo -e "AT+COPS?+COPS:\r" > /dev/smd0 |
| 07:14.58 | manekineko | ERROR |
| 07:15.25 | WisTilt2 | ok try this AT+CGREG? |
| 07:15.34 | WisTilt2 | should give you the gprs info |
| 07:15.47 | manekineko | +CREG: 1,1 |
| 07:15.56 | manekineko | I was actually wondering that from the source |
| 07:16.02 | manekineko | why would CDMA phones have GPRS info? |
| 07:16.33 | *** join/#htc-linux Drakh (Drakh@190.42.35.125) |
| 07:18.27 | WisTilt2 | no telling. well either way, knowing the bsinfo cmd and the math, we can add it to the ril. need to go to bed though. we'll pick up on this tomorrow night. |
| 07:18.53 | manekineko | okay cool, I'll leave this in your capable hands then |
| 07:19.00 | manekineko | actually |
| 07:19.02 | manekineko | the math is unnecessary |
| 07:19.17 | manekineko | the numbers should be passed straight through |
| 07:19.38 | WisTilt2 | where are they passed back to? |
| 07:19.49 | manekineko | I think we can just stick them into response[5] and response[6] |
| 07:19.54 | manekineko | as defined here: http://android.git.kernel.org/?p=platform/hardware/ril.git;a=blob;f=include/telephony/ril.h;h=99fd355db1b41ce84b4a296465cfcdda364fbc65;hb=HEAD#l1012 |
| 07:20.08 | WisTilt2 | ah, that shouldnt be too hard to implement |
| 07:20.16 | manekineko | yeah, the response array should be expanded |
| 07:20.29 | manekineko | as everything from 5-13 is for CDMA |
| 07:20.36 | manekineko | while our array was only intialized to [4] |
| 07:20.52 | WisTilt2 | ok we'll talk more tomorrow night. im out. arrrghhh catch you tomorrow night. |
| 07:26.10 | *** join/#htc-linux |Atom| (~atom@82.194.234.249) |
| 07:33.24 | *** join/#htc-linux dekar_ (~dekar@drms-590ec5d5.pool.mediaWays.net) |
| 07:41.12 | *** join/#htc-linux Rajko (~Rajko@cable-94-189-156-130.dynamic.sbb.rs) |
| 08:01.47 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 08:03.53 | *** join/#htc-linux MattOG (~MattOG@82-68-49-6.dsl.in-addr.zen.co.uk) |
| 08:06.27 | *** join/#htc-linux CazH (~quassel@3007ds2-rd.0.fullrate.dk) |
| 08:27.02 | *** join/#htc-linux venom00ut (~venom00@unaffiliated/venom00) |
| 08:29.13 | *** join/#htc-linux Bry8Star (~Bry8Star@unaffiliated/bry8star) |
| 08:43.56 | *** join/#htc-linux kvaster_ (~kvaster@93.84.112.80) |
| 08:45.43 | *** join/#htc-linux cazh_ (~quassel@3007ds2-rd.0.fullrate.dk) |
| 09:03.38 | *** join/#htc-linux |Atom| (~atom@82.194.234.249) |
| 09:12.11 | *** join/#htc-linux Curious_ (8bb3cfda@gateway/web/freenode/ip.139.179.207.218) |
| 09:23.59 | *** join/#htc-linux gauner1986 (~Miranda@p5B382F4C.dip.t-dialin.net) |
| 09:34.38 | *** join/#htc-linux Bry8Star_ (~Bry8Star@adsl-71-137-233-207.dsl.irvnca.pacbell.net) |
| 09:34.42 | *** part/#htc-linux Bry8Star_ (~Bry8Star@adsl-71-137-233-207.dsl.irvnca.pacbell.net) |
| 09:35.01 | *** join/#htc-linux Guest56650 (~Bry8Star@unaffiliated/bry8star) |
| 09:41.07 | *** join/#htc-linux opdf2 (~asdfsd@c-67-173-70-13.hsd1.il.comcast.net) |
| 09:41.40 | *** join/#htc-linux Bry8Star (~Bry8Star@adsl-71-137-233-207.dsl.irvnca.pacbell.net) |
| 09:41.46 | *** join/#htc-linux Bry8Star (~Bry8Star@unaffiliated/bry8star) |
| 10:05.57 | *** join/#htc-linux |lippa| (~lippa@ppp118-209-218-222.lns20.mel6.internode.on.net) |
| 10:07.48 | *** join/#htc-linux programmer8922 (~Evan@67.219.164.162) |
| 10:26.28 | *** join/#htc-linux MethoS (~clemens@134.102.106.250) |
| 10:33.47 | *** join/#htc-linux imilka (~kvirc@95-28-72-91.broadband.corbina.ru) |
| 10:34.56 | *** join/#htc-linux tyween` (~tyween@pool-71-163-117-57.washdc.fios.verizon.net) |
| 10:36.05 | *** join/#htc-linux kvaster_ (~kvaster@leased-line-93-125-0-84.telecom.by) |
| 10:36.18 | *** join/#htc-linux [acl] (~abel@cpe-69-203-141-229.si.res.rr.com) |
| 10:39.08 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 10:56.40 | *** join/#htc-linux Ondalf (~ondalf@dsl-roibrasgw1-fe8bfb00-146.dhcp.inet.fi) |
| 11:02.21 | *** join/#htc-linux dekar (~dekar@95.143.165.210) |
| 11:08.43 | *** join/#htc-linux avinashhm (~avinash-h@203.101.61.7) |
| 11:22.02 | *** join/#htc-linux |Atom_wk| (~atom@82.194.234.252) |
| 11:32.54 | *** join/#htc-linux _Atom_wk_ (~atom@82.194.234.249) |
| 11:35.58 | *** join/#htc-linux Erikson (~Erik@p54B76E45.dip.t-dialin.net) |
| 11:48.45 | *** join/#htc-linux dekar (~dekar@95.143.165.210) |
| 11:54.38 | *** join/#htc-linux L_miller (~IceChat7@bs.americas.lc.americanstandard.com) |
| 12:02.31 | *** join/#htc-linux D3tul3 (~Oliver@cpe-174-109-223-235.nc.res.rr.com) |
| 12:14.45 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 12:19.10 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/session) |
| 12:19.10 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/ip.86.134.32.198) |
| 12:26.31 | *** join/#htc-linux |Atom_wk| (~atom@82.194.234.252) |
| 12:33.37 | *** join/#htc-linux |Atom_wk| (~atom@82.194.234.249) |
| 12:41.43 | *** join/#htc-linux GNUtoo|laptop (~gnutoo@host68-143-dynamic.54-79-r.retail.telecomitalia.it) |
| 12:45.19 | *** join/#htc-linux fakker (~noobhands@cpc13-hitc6-2-0-cust129.9-2.cable.virginmedia.com) |
| 12:49.55 | *** join/#htc-linux LordDeath (~Lord|Lapt@cable-81-173-166-52.netcologne.de) |
| 12:57.09 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
| 13:04.07 | *** join/#htc-linux XirXes_ (~XirXes@67-2-24-163.slkc.qwest.net) |
| 13:13.04 | *** join/#htc-linux ElFinLazz (~elfinlazz@112.154.189.103) |
| 13:30.22 | *** join/#htc-linux jonpry (~jon@63.245.31.4) |
| 13:39.10 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 13:58.13 | *** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring) |
| 14:01.46 | *** join/#htc-linux L_miller (~IceChat7@bs.americas.lc.americanstandard.com) |
| 14:03.24 | *** join/#htc-linux t3g (~t3g@p3E9E5875.dip.t-dialin.net) |
| 14:14.30 | *** join/#htc-linux t3g (~t3g@p3E9E5875.dip.t-dialin.net) |
| 14:25.21 | *** join/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |
| 14:25.44 | Cotulla | hey |
| 14:32.19 | *** join/#htc-linux asd_ (50b77877@gateway/web/freenode/ip.80.183.120.119) |
| 14:33.51 | gauner1986 | hey cotulla |
| 14:35.23 | Cotulla | flashed first rom to RHO |
| 14:38.22 | Cotulla | via MAGLDR |
| 14:38.33 | Cotulla | but it discharged fully now :( |
| 14:43.50 | fakker | 14:39 |
| 14:43.51 | fakker | i always feel like a peodphile buying huge bags of pick n mix... |
| 14:45.34 | AstainHellbring | rhodium interesting |
| 14:46.10 | *** join/#htc-linux mitsutaka (~mitsutaka@p1227-ipbf3907marunouchi.tokyo.ocn.ne.jp) |
| 14:52.32 | *** join/#htc-linux t3g (~t3g@p3E9E3007.dip.t-dialin.net) |
| 14:55.48 | *** join/#htc-linux mitsutaka (~mitsutaka@p1227-ipbf3907marunouchi.tokyo.ocn.ne.jp) |
| 15:00.40 | *** join/#htc-linux L_miller (~IceChat7@bs.americas.lc.americanstandard.com) |
| 15:01.26 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/ip.86.134.32.198) |
| 15:10.28 | *** join/#htc-linux Erikson_ (~Erik@p54B772C6.dip.t-dialin.net) |
| 15:11.53 | jonpry | hello |
| 15:13.28 | *** join/#htc-linux noobhands (~noobhands@cpc13-hitc6-2-0-cust129.9-2.cable.virginmedia.com) |
| 15:14.36 | NetRipper | sykosoft, http://netripper.pastebin.com/fUpQ4eg8 the table has about 2.2 million records.. the query is to determine the last entry for a given channel.. it takes about 7 seconds :) |
| 15:19.17 | Cotulla | hey jonpry |
| 15:19.31 | jonpry | hi cotulla |
| 15:19.42 | jonpry | how's that .32? |
| 15:20.17 | *** join/#htc-linux Samsunguy (~Samsunguy@65.120.149.2) |
| 15:20.50 | *** join/#htc-linux GPFerror_ (~GPF@ip72-208-193-231.ph.ph.cox.net) |
| 15:22.10 | jonpry | i wrote new microp-ksc for 35, but it locks up the phone |
| 15:22.43 | jonpry | sure sign of good code |
| 15:22.50 | Cotulla | nice booting initrd |
| 15:22.57 | Cotulla | I make decision to boot it from nand directly |
| 15:23.02 | Cotulla | no SD :P |
| 15:23.18 | Cotulla | so I added flashing MAGLDR stuffs and flashed it |
| 15:23.29 | jonpry | ah, going with old slow memory |
| 15:23.37 | jonpry | *small slow |
| 15:23.49 | Cotulla | I didn't port microp yet |
| 15:24.01 | jonpry | i think it is just i2c is down |
| 15:24.25 | jonpry | so keyboard interrupt tries to make i2c command, and fails |
| 15:27.50 | jonpry | actually that is not it. microp reads version correctly |
| 15:29.52 | *** join/#htc-linux Markinus (~Miranda@212.255.18.217) |
| 15:30.48 | Cotulla | jonpryi wrote new microp-ksc for 35, but it locks up the phone |
| 15:30.49 | Cotulla | jonprysure sign of good code |
| 15:30.49 | Cotulla | lol |
| 15:30.50 | Cotulla | :D |
| 15:31.00 | Cotulla | good code must show warnings, but not die! |
| 15:31.19 | Cotulla | it should work, if u ever remove keyboard from RHO while it's on! |
| 15:32.02 | jonpry | its like its stuck in the irq handler |
| 15:32.13 | jonpry | i think maybe gpio int have to be cleared on 35 |
| 15:34.28 | Cotulla | btw how is ur battery driver? |
| 15:34.48 | jonpry | i think its good. i just don't have any data to test it with |
| 15:35.14 | Cotulla | hehe |
| 15:35.33 | Cotulla | I think I gotta use other algo, reversed. maybe not so good, but at least working somehow |
| 15:36.12 | jonpry | but I can estimate battery capacity |
| 15:36.35 | Cotulla | but it need wake up each time? |
| 15:36.45 | jonpry | i'm not sure |
| 15:36.58 | jonpry | to get battery parameters it takes lots of data |
| 15:37.09 | Cotulla | hm |
| 15:37.15 | Cotulla | anyway u need check if it will work |
| 15:37.18 | jonpry | like maybe keep awake hole time and run battery all the way down |
| 15:37.23 | jonpry | *whole |
| 15:37.39 | *** join/#htc-linux crawling (crawling@a94-132-169-99.cpe.netcabo.pt) |
| 15:37.44 | Cotulla | as well what about panel on/off? is it stable on all devices? if not, I gotta copy WM init code |
| 15:38.06 | jonpry | i think it is, its just that mdp resume is not stable |
| 15:38.20 | Cotulla | hm |
| 15:38.33 | jonpry | which might not be a problem on .32 mdp |
| 15:39.10 | Cotulla | yes |
| 15:39.17 | Cotulla | but WM init contains much more values |
| 15:39.26 | Cotulla | than WisTilt2 implementation |
| 15:40.20 | *** join/#htc-linux mitsutaka (~mitsutaka@p1227-ipbf3907marunouchi.tokyo.ocn.ne.jp) |
| 15:40.32 | Cotulla | I implemented USB seems now |
| 15:40.45 | jonpry | i think if you have people bot android and count percentage of failed boots, it will be the same as percentage of failed wakes |
| 15:40.52 | jonpry | s/bot/boot/ |
| 15:41.05 | Cotulla | hm maybe |
| 15:41.18 | Cotulla | but my idea that we have not such testers like htc |
| 15:41.38 | Cotulla | so it's better in the most cases do stuffs like htc, because they tested it well already |
| 15:41.39 | jonpry | i can't get adb to work right. hangs right after connect |
| 15:42.14 | Cotulla | for me adb works :) |
| 15:45.12 | jonpry | getting it to work just like htc, is like using vial |
| 15:49.58 | *** join/#htc-linux Detule (~gjoneski@bender.math.duke.edu) |
| 15:50.48 | *** join/#htc-linux Alex[sp3dev] (~alexander@ip-95-220-12-212.bb.netbynet.ru) |
| 15:50.57 | jonpry | hi Alex[sp3dev] |
| 15:51.10 | Alex[sp3dev] | hi jonpry |
| 15:51.15 | Alex[sp3dev] | jonpry: i can has sound |
| 15:51.21 | jonpry | oO |
| 15:51.21 | Alex[sp3dev] | s/has/haz/ |
| 15:51.22 | Alex[sp3dev] | lol |
| 15:51.34 | jonpry | i wrote a ksc driver |
| 15:51.51 | jonpry | it doesn't have led/backlight yet, big can of worms |
| 15:51.53 | Alex[sp3dev] | jonpry: it doesn't count as a driver if it hangs. |
| 15:52.04 | jonpry | well theres nothing wrong with it |
| 15:52.14 | Alex[sp3dev] | aha. check unbalanced irqs |
| 15:52.45 | jonpry | that would show up in dmesg |
| 15:52.46 | Alex[sp3dev] | btw, i have tried to make a simple driver that disables irq in the handler and enables in workqueue.. the interrupt comes only one time.. somehow |
| 15:53.13 | Alex[sp3dev] | now i want your opinion |
| 15:53.17 | jonpry | i should be so lucky |
| 15:53.21 | Alex[sp3dev] | on how to implement sound routing and audioparams |
| 15:54.04 | jonpry | well its not pretty no matter what |
| 15:54.18 | jonpry | cause you have msm_snd trying to setup the routing |
| 15:55.08 | Alex[sp3dev] | jonpry: i think this stuff should be handled by userspace.. at least because audioparam.c is a copy of audioparams4.csv and it's license is unclear.. |
| 15:55.28 | Alex[sp3dev] | but as for routing, it should be done in kernel. just have no idea how |
| 15:55.46 | *** join/#htc-linux emwe (~emwe@cable-86-56-10-158.cust.telecolumbus.net) |
| 15:55.51 | jonpry | so you want htc_acoustic? |
| 15:56.05 | emwe | hiho |
| 15:56.10 | Alex[sp3dev] | if i do not, can we just drop audioparam stuff? |
| 15:56.14 | Alex[sp3dev] | emwe: high |
| 15:56.17 | Alex[sp3dev] | oops |
| 15:56.17 | jonpry | hi emwe |
| 15:56.20 | Alex[sp3dev] | hi i mean ;) |
| 15:56.38 | Alex[sp3dev] | been hacking 35 all the day |
| 15:56.40 | emwe | hi guys. read logs. topa just seems to have luck with 4mb aligned memory zones? |
| 15:56.56 | emwe | yeah, saw your commits. just need to get ahold of everything |
| 15:57.02 | Alex[sp3dev] | emwe: well, maybe. but i advise you to pull that commit |
| 15:57.18 | emwe | just the CONFIG_HOLES_IN_ZONE, right? |
| 15:57.23 | emwe | anything else? |
| 15:57.24 | Alex[sp3dev] | emwe: yep |
| 15:57.32 | emwe | CONFIG_HAS_HOLES_MEMORY_MODEL? |
| 15:57.36 | Alex[sp3dev] | HOLES_IN_ZONE and HOLES_MEMORY_MODEL |
| 15:57.39 | emwe | i see |
| 15:58.15 | emwe | Alex[sp3dev]: regarding "new/early server" so it seems only 5225 needs it. 6225 doesn, apparently. |
| 15:58.20 | Alex[sp3dev] | emwe: btw, i have completely reworked smd, rpc and amss. now most of stuff is passed via pdata. and now i have unified our smd router with android. to send 'rpc bye' command you just need to add the cmdline parameter |
| 15:58.32 | Cotulla | heh |
| 15:58.36 | Cotulla | Alex <3 pdata? |
| 15:58.46 | Alex[sp3dev] | emwe: well, i have implemented it via pdata, so we're not polluting code with machine checks and compile-time macros |
| 15:58.49 | jonpry | Alex[sp3dev] i think you can ditch all kernel audio param stuff if you use acoustic. |
| 15:58.49 | emwe | Alex[sp3dev]: yes, saw all your work. just need to find a calm minute ;) |
| 15:58.54 | Alex[sp3dev] | Cotulla: i love dynamic stuff ;) |
| 15:59.00 | Cotulla | I hate pdata |
| 15:59.01 | Cotulla | because |
| 15:59.15 | Cotulla | it always have defintions of structures in some header |
| 15:59.18 | Cotulla | which located in the ass |
| 15:59.31 | Alex[sp3dev] | jonpry: wait a minute. htc-acoustic is for passing audioparams from userspace, aite? |
| 15:59.38 | jonpry | yeah |
| 15:59.45 | Alex[sp3dev] | why aren't we using it? |
| 15:59.48 | Cotulla | using machine_is_xxx u also get dynamic stuffs |
| 16:00.05 | jonpry | Alex[sp3dev] cause we didn't know how it worked before |
| 16:00.14 | Alex[sp3dev] | Cotulla: yes, but when you need to add/remove some machine, you have to patch a lot of files. that is a bad practice |
| 16:00.19 | Cotulla | accoustick rpc not supported |
| 16:00.20 | jonpry | and the source in android tree is not real, just stub |
| 16:00.21 | Cotulla | :P |
| 16:00.22 | Alex[sp3dev] | jonpry: now do we? |
| 16:00.26 | jonpry | yes |
| 16:00.47 | Cotulla | Alex[sp3dev], but the fate that we won't add new machines... list is fixed |
| 16:00.50 | emwe | Alex[sp3dev]: after playing audio, when it disables audpp again, smd sends of cmd=6 (RPCROUTER_CTRL_CMD_REMOVE_CLIENT) and then cmd=7 (RPCROUTER_CTRL_CMD_RESUME_TX) to id=0:0 for me and the wait for reply timeouts. do you also see that? (error in aumgr_disable) |
| 16:01.23 | Alex[sp3dev] | emwe: ahum. i will check if you want |
| 16:02.10 | emwe | Alex[sp3dev]: only the second call (cmd=7) times out because the id=0:0 is wrong. on cmd=6 it is id=-1070070291:c0380b35 and on cmd=7 it is 0:0 ... on .27 both remote-ids are identical and it works. |
| 16:02.26 | emwe | so after playing sound, waiting a while, userland is blocked because the wait for reply. |
| 16:02.33 | Alex[sp3dev] | jonpry: i suggest that now you guys check out my changes and make patches for 6125 accordingly and in the meantime i'll fix microp-ksc |
| 16:02.39 | emwe | that's why i didn't push my seriously dirty qdsp hacks, yet. |
| 16:03.08 | Alex[sp3dev] | emwe: ok, what's the test case scenario? |
| 16:03.28 | emwe | change vol, wait for audpp task to be disabled in the logs and change vol again |
| 16:03.59 | Alex[sp3dev] | damn.. without microp-ksc i have remapped volume buttons to something else |
| 16:04.47 | emwe | btw, thanks for dropping smd_rpcrouter_wince again ;) |
| 16:05.01 | emwe | and i think we can just go by registering smd channels on board |
| 16:05.20 | Alex[sp3dev] | emwe: i'm registering smd servers in board, yes |
| 16:05.26 | emwe | of course, this leads to the ever lasting discussion of per board or not. the channels are all the same ;) |
| 16:05.29 | emwe | no, i mean the smd channels |
| 16:05.40 | emwe | and yes, early servers. saw that. |
| 16:05.42 | Alex[sp3dev] | smd_tty? |
| 16:05.45 | emwe | yap |
| 16:05.53 | Alex[sp3dev] | they're also registered in board now |
| 16:06.03 | Alex[sp3dev] | i have actually separated it into amss_5225.c |
| 16:06.14 | Alex[sp3dev] | it registers smd and tries to register adsp if it available |
| 16:06.27 | emwe | i just had a quick look early at work today. not locked deep enough. |
| 16:07.00 | Alex[sp3dev] | emwe: most of changes were commited about 2 hours ago |
| 16:07.18 | emwe | i think i also missed that structure field change i saw in your commits. where two fields are upside-down |
| 16:07.27 | emwe | rpc_something... |
| 16:07.31 | Alex[sp3dev] | yeah |
| 16:07.39 | Alex[sp3dev] | i think it caused ARM9 to die for me |
| 16:07.40 | emwe | what was the outcome of that? |
| 16:07.45 | emwe | hm. |
| 16:08.02 | Alex[sp3dev] | but that needs to be verified |
| 16:08.04 | emwe | i should get that raph going for .35 so i can verify 5225 and 6225 |
| 16:08.16 | emwe | 6125 i mean |
| 16:09.12 | emwe | smem_alloc/find also needs to be fixed, yet. any idea on that apart from duplicating the methods to handle the different structures? |
| 16:09.19 | emwe | (like on .27) |
| 16:11.38 | Alex[sp3dev] | emwe: i thought 35 has v1 and v2 structures by default. probably the only thing is interrupt handling.. i think we can make an option to handle it in amss_6125.c and handle it's custom layout ther |
| 16:11.47 | Alex[sp3dev] | i don't have 6125 to test |
| 16:12.44 | *** join/#htc-linux gauner1986 (~Miranda@p5B382F4C.dip.t-dialin.net) |
| 16:12.56 | Cotulla | heh it's why I am using 32 |
| 16:13.04 | Alex[sp3dev] | why? |
| 16:13.09 | emwe | Alex[sp3dev]: smd_alloc_elm is for channel alloc. that one is v1ed and v2ed in .27 with their replicated methods. |
| 16:13.10 | Cotulla | because doubt there such problems |
| 16:13.12 | Cotulla | with v1 v2 and etc |
| 16:13.18 | *** join/#htc-linux honeycomb_sucks (~kvirc@95-28-72-91.broadband.corbina.ru) |
| 16:13.18 | gauner1986 | because it's quality tested by htc? |
| 16:13.19 | gauner1986 | :) |
| 16:13.23 | Cotulla | it's also reason |
| 16:13.32 | Alex[sp3dev] | Cotulla: this problem is only specific to 6125. all other amss have the same interrupt handler layout |
| 16:13.43 | Cotulla | I am using 6125 |
| 16:13.47 | Cotulla | and looks like no problem |
| 16:14.08 | Alex[sp3dev] | i'll need to look into it again. maybe our hacks in 27 are unnecessary |
| 16:14.33 | emwe | i need smd_allo_elm to be extended by 4byte to make smem_find() work for smd channel allocation |
| 16:14.57 | Alex[sp3dev] | emwe: uhh.. i don't think you do. this padding can be ignored |
| 16:15.02 | emwe | and smsm_interrupt_info by 9*4 byte |
| 16:15.15 | Cotulla | which problem u have with 6125? |
| 16:15.53 | Alex[sp3dev] | some structures differ from other amss, so we wonder how to dynamically handle 6125 without breaking support for others |
| 16:15.57 | emwe | how can it be ignored if the smem reported size doesn't match and the method fails because sizeof(smd_allo_elm)*64 doesn't fit? |
| 16:16.14 | emwe | after fixing the size smd alloc wen't fine. |
| 16:16.20 | Cotulla | just call structures xxx_6125 |
| 16:16.32 | Alex[sp3dev] | emwe: i'll need to diff your files against mine |
| 16:17.28 | emwe | Cotulla: yeah, but my skills fail on me how to handle different structures in *one* method. |
| 16:17.35 | emwe | (smd_channel_probe_worker()) |
| 16:17.55 | Alex[sp3dev] | emwe: we could just supply alternative handler via the behated pdata |
| 16:18.32 | emwe | Alex[sp3dev]: how much i like your idea, but how re-portable is that stuff again when we have to link into "official" code that deep. |
| 16:18.49 | emwe | no matter if the official code sucks or not. |
| 16:19.03 | Alex[sp3dev] | emwe: as soon as it doesn't change *default* behaviour and doesn't break other board, i think it's fine |
| 16:20.03 | jonpry | emwe: the different adsp structures only differ by the unknown parameter right? |
| 16:20.07 | Alex[sp3dev] | if we do it properly, i think it'd be good to submit it to mainline. but right now it seems i have broken some stuff. when we're done with our amss, we'll need to recreate amss_XXXX.c for android amss so that native devices ain't broken |
| 16:20.40 | emwe | i think i will hold on with any dynamic lookup on main .35 tree until there's some cool stuff you come up with :) |
| 16:20.48 | Cotulla | make two smd_channel_probe_worke |
| 16:20.56 | Cotulla | smd_channel_probe_worker_6125 and smd_channel_probe_worker_5225 |
| 16:21.03 | emwe | jonpry: smd_alloc_elm, yes, by one uint32_t |
| 16:21.04 | Alex[sp3dev] | Cotulla: will probably do |
| 16:21.05 | Cotulla | and put description what is different |
| 16:21.23 | emwe | Cotulla: that's what is done on .27. is there no "other" way somehow? |
| 16:21.39 | jonpry | emwe, so we could just use the bigger struct everywhere, and when the size is important, just use the size from pdata |
| 16:21.49 | Alex[sp3dev] | jonpry: nope |
| 16:21.51 | *** join/#htc-linux Samsunguy (~Samsunguy@65.120.149.2) |
| 16:22.02 | Alex[sp3dev] | the problem is that 'unknown' field is in the middle |
| 16:22.03 | Cotulla | emwe, it's looking logical |
| 16:22.13 | Cotulla | with description that is different |
| 16:22.27 | jonpry | i thought it was at end |
| 16:22.27 | Alex[sp3dev] | so i think on it later.. tired of this stuff for today |
| 16:22.33 | Cotulla | or u can make |
| 16:22.37 | emwe | Cotulla: yes, of course. i rather have one method in order to DRY. but that's perhaps just too naive. |
| 16:22.39 | Alex[sp3dev] | jonpry: not interrupt info, but alloc_elm |
| 16:22.39 | Cotulla | some common structure |
| 16:22.48 | jonpry | Alex[sp3dev]: you want me to send you the ksc stuff i did? maybe it just works on your kernel |
| 16:22.50 | Cotulla | which holds data in the own format |
| 16:22.56 | Alex[sp3dev] | jonpry: do please |
| 16:22.57 | Cotulla | and convert each structure type to it |
| 16:23.16 | Cotulla | or u can use structure type from one version as base |
| 16:23.23 | Alex[sp3dev] | Or we can convert this to a union.. and select how to handle it depending on amss version |
| 16:23.24 | Cotulla | and convert other version to it |
| 16:23.35 | Cotulla | union won't work I think |
| 16:23.40 | emwe | Cotulla: something like that, yes. in a calm minute... ;) |
| 16:23.57 | Cotulla | code like this |
| 16:23.57 | Cotulla | if (!shared[n].ref_count) |
| 16:23.57 | Cotulla | continue; |
| 16:23.58 | emwe | jonpry: you had a chance to test that HOLES* stuff on your rhod? |
| 16:24.04 | Cotulla | won't work without changes with union |
| 16:25.10 | Alex[sp3dev] | emwe: as for smsm_interrupt_info, you can ignore this extra 9 uints. for 5225 we had 1 uint in 27.. i have ignored it. since we're not reading it anyway, it won't matter |
| 16:25.22 | *** join/#htc-linux siulmagic (~IceChat7@24.54.255.153) |
| 16:26.20 | emwe | Alex[sp3dev]: we are not reading it? |
| 16:26.35 | Alex[sp3dev] | emwe: we are reading, but not using it after |
| 16:26.52 | emwe | oh ^^ ;) |
| 16:27.24 | Alex[sp3dev] | emwe: i think i'll hack it in the easiest way ;) |
| 16:27.49 | Alex[sp3dev] | just add second probe worker and a "is_alloc_elm_v2" field to pdata |
| 16:29.03 | Cotulla | u discuss it 10 minuts already :o |
| 16:29.08 | Cotulla | just copy it and move forward :) |
| 16:29.39 | emwe | Cotulla: ah, same butchering and messing like .27. no whonder you get it on so fast. |
| 16:29.40 | Alex[sp3dev] | Cotulla: yes.. someone has already hacked everything moving forward for 27 and we need to rewrite everything from scratch now |
| 16:30.36 | emwe | looking on .27 you can't judge what code was there and was hacked up in later at some places. and that is a real pain. |
| 16:31.06 | Cotulla | why it hack? |
| 16:31.12 | Cotulla | two functions for different versions |
| 16:31.23 | emwe | no, i meant the whole tree in my sentence. |
| 16:31.25 | phh | two versions of stuff is needed |
| 16:31.35 | emwe | hi phh. |
| 16:31.35 | phh | 6125 (or whatever rhod/topa is) has different size than 5225/6225 |
| 16:31.47 | Cotulla | or u can ever make different files |
| 16:31.48 | Alex[sp3dev] | no, hack is hacking in machine_is_poop() into smd.c and stuff like that. but i will do it via pdata and no more talks about that |
| 16:31.51 | Cotulla | like smem_6125.c |
| 16:31.56 | Cotulla | and smem_5225.c |
| 16:31.58 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 16:32.18 | emwe | phh: just wanted to evaluate some more elegant stuff. looks like not so possible. |
| 16:32.28 | *** join/#htc-linux balans (~barry@82-170-217-205.ip.telfort.nl) |
| 16:32.29 | phh | Alex[sp3dev]: google original code is using #ifdef MACHINE_SOMETHING btw |
| 16:32.34 | L_miller | arrrghhh - how is nand? |
| 16:32.40 | Alex[sp3dev] | phh: google code sucks anyway |
| 16:32.45 | Alex[sp3dev] | #ifdef is compile-time |
| 16:33.02 | phh | oh really ? |
| 16:33.12 | Cotulla | it's not sucks |
| 16:33.14 | phh | it's just that you usually take them as reference. |
| 16:33.24 | Cotulla | u need different kernel for each device :) |
| 16:33.29 | phh | "oh they do a pmem per board, let's do that too!" |
| 16:33.35 | Alex[sp3dev] | Cotulla: u need different kernel, not me |
| 16:33.44 | Cotulla | I will use one for TPZ & RHO |
| 16:33.45 | Cotulla | :P |
| 16:34.09 | Alex[sp3dev] | phh: yes, per-board stuff must be done. because 27 code is so cryptic now that it's hard to follow |
| 16:34.10 | emwe | Cotulla: that's eays, same amss. that's where the crap begins if amss params are different. |
| 16:34.20 | Cotulla | yes |
| 16:34.22 | phh | Alex[sp3dev]: "code is wrong, so make it totally wrong" |
| 16:34.22 | phh | <3 |
| 16:34.29 | Cotulla | but I think better go from reality |
| 16:34.36 | Cotulla | 6 devices with MSM7200A |
| 16:34.43 | Cotulla | with 3 different AMSS versions |
| 16:34.48 | phh | the changes gave by jbruneaux (iirc) seemed fine to me |
| 16:34.59 | Cotulla | it's all that kernel needed |
| 16:35.21 | Cotulla | and btw |
| 16:35.58 | Alex[sp3dev] | phh: what is wrong about making it per board? even gpio strength/pull up can differ between boards for mmc.. and as for pmem.. well, i don't want to have pmem.c and board file depend on each other (i.e., for ram) |
| 16:36.13 | phh | Alex[sp3dev]: 95% of the code is the same ? |
| 16:36.20 | phh | only the values of gpio are different ... |
| 16:36.36 | Alex[sp3dev] | phh: well, vregs are different as well |
| 16:36.58 | phh | it's just names, it goes well in platform_data ... |
| 16:37.07 | Alex[sp3dev] | anyway, if you want, go do it all yourself. i'm not going to try to support 10 devices prior to getting at least one working |
| 16:37.17 | Cotulla | :P |
| 16:37.28 | Cotulla | I agree to make them separate |
| 16:37.30 | phh | and you're telling me you're going to support diamond ? |
| 16:37.38 | Cotulla | just clean copy for each device |
| 16:37.38 | noobhands | haha |
| 16:37.48 | arrrghhh | why can't we have separate boardfiles? |
| 16:37.49 | arrrghhh | runs |
| 16:38.18 | Cotulla | dunno, I put most stuffs separate in my tree and common things as hl72_*.* files |
| 16:38.23 | Alex[sp3dev] | phh: when i'm done with kovsky, i'll forwards-port other devices.. and note. if we ever make it to nand, i want to integrate upstream, therefore i'm trying to do it cleanly |
| 16:38.58 | phh | Alex[sp3dev]: again, torvalds is against that fucking arm thing of copying everything everywhere |
| 16:39.06 | emwe | Alex[sp3dev]: but you must admit that there is code duplication all over the place. there's no way to deny that. and that's just plainn stupid as well. |
| 16:39.09 | phh | still it can go upstream, because he doesn't take care of that |
| 16:39.36 | Alex[sp3dev] | phh: again, let's do it so that it's clean and just works. and not waste our life on this bullshit anymore |
| 16:39.46 | phh | how is that clean ? |
| 16:39.52 | phh | "ok i'm done copying" |
| 16:39.56 | phh | "oh i've forgotten PM" |
| 16:39.57 | Cotulla | maybe torvalds never developed for arm? |
| 16:40.00 | phh | "bah i'll do it only for kovs" |
| 16:40.12 | arrrghhh | lol |
| 16:40.24 | Cotulla | "bah i'll do it only for kovs" - it's right, because he have only kovsky |
| 16:40.34 | Cotulla | why he must fuck with other virtual devices for him? |
| 16:40.39 | phh | . |
| 16:40.41 | Alex[sp3dev] | phh: wtf do you want me to? to stop working on it at all? i can and it will even be good for me and my study.. |
| 16:40.50 | Cotulla | as well know which hardware installed there? |
| 16:40.57 | phh | Alex[sp3dev]: stop thinking what you're doing is clean. |
| 16:41.58 | emwe | Cotulla: it's not about asking for support devices he doesn't own, but trying to stop duplicating code again and again for *6* boards where 95% of the hooks are identical and just the board-specific values are different. |
| 16:42.00 | Cotulla | clear clear... it won't be clear for brain anyway |
| 16:42.31 | Cotulla | emwe, how developer with one device can know that nothing else is broken? |
| 16:42.31 | Alex[sp3dev] | phh: my smd and adsp is handled via pdata, not compile-time or that ugly amss_para.c thing. it is clean. duplicating code is not clean.. but then, we need to rewrite msm sdcc driver to have common routines there.. or we'll have to proxyfy/subclass it in our drivers.. which is very fragile in case of upgrades |
| 16:42.46 | Cotulla | somebody will overclock wlan for example |
| 16:42.55 | Cotulla | and he will compile only for his device |
| 16:42.58 | Cotulla | then he will commit it :P |
| 16:43.16 | arrrghhh | Cotulla, testers |
| 16:43.18 | Cotulla | next day people will found: oppss no sd and no wlan in the recent kenerl |
| 16:43.19 | arrrghhh | lots of pigs |
| 16:43.43 | Cotulla | and they modified clock a day before |
| 16:43.54 | Cotulla | they will start to think that clocks broke mmc & wlan |
| 16:44.01 | Cotulla | and will spend few hours to check clocks |
| 16:44.08 | Cotulla | while problem inside mmc :) |
| 16:45.18 | Cotulla | as well embedded hardware usually have too many difference parameters |
| 16:45.40 | Cotulla | like wlan on kovsky needs 150 ms delay and on diamond it may need only 100ms |
| 16:45.46 | emwe | Cotulla: i see where you are coming from. but then have some pdata for that. but sometimes the officical code isn't prepared for that at times... |
| 16:45.53 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 16:46.00 | *** join/#htc-linux t3g (~t3g@p3E9E3007.dip.t-dialin.net) |
| 16:46.02 | Cotulla | btw RHO have different WLAN, so it must be in the separate file |
| 16:46.18 | phh | Cotulla: yeah true |
| 16:46.22 | Alex[sp3dev] | Cotulla: oh, first good idea from you here |
| 16:46.30 | Cotulla | as well, when u have several files |
| 16:46.39 | Cotulla | it's easy to look to code |
| 16:46.49 | Cotulla | easy to check it |
| 16:47.15 | Cotulla | like: if u have direct GPIO numbers, u just go and search name of GPIO and got number. |
| 16:47.49 | Cotulla | if u pass GPIO number via pdata: u need: 1)detect which pdata used 2)found this pdata on the other side 3)be sure it's right pdata 4)get gpio from it and look |
| 16:48.14 | Alex[sp3dev] | Cotulla: aite, it's better to hardcode it in 4 files and correct all 4 files if it's wrong |
| 16:48.16 | Cotulla | dunno about u, I prefer clear code, when u look on it and it's very easy to understand that's up there :) |
| 16:48.45 | Cotulla | different people will correct them... who own device |
| 16:49.06 | emwe | Cotulla: yes, and you fix it for your board and the other 5 are forgotten because you don't fix a perhaps comming thing (not a gpio, but other code) and then all other 5 boards miss that fix. |
| 16:49.24 | emwe | Cotulla: no, people will not. that has happened in the past according to phh |
| 16:49.46 | Cotulla | :) |
| 16:49.58 | Cotulla | it's my opinion, my position of view :) |
| 16:50.03 | phh | and it was at the time there was a lot of devs ... |
| 16:50.12 | phh | (but many bad devs) |
| 16:50.17 | Cotulla | phh, real devs? |
| 16:50.42 | Alex[sp3dev] | emwe: Cotulla just comes from the proprietary world where no one wants to share code |
| 16:50.46 | emwe | Cotulla: yes of course. and nobody forces you to step back from it ;) i think this channel allows discussion ;) |
| 16:50.49 | ali1234 | real devs know how to bisect to find bugs |
| 16:50.52 | phh | especially for kovsky/blackstone, they had devs that just copied my work for wifi, breaking their own stuff /o\ |
| 16:50.53 | Cotulla | or "hey here number, ow...lets increase it twice!!! hey OMFG it looks like it start to work faster!!!! commit it now :D" |
| 16:51.45 | Cotulla | next day: "hm hm it worked yesterday, but now it crashes sometimes. hm hm hm maybe memory corrupts. lets look to memory settings. OMFG who did this???" |
| 16:52.43 | Cotulla | but it maybe okay to make common mmc. |
| 16:52.45 | phh | Cotulla: you've already gone through that ? :p |
| 16:52.54 | Alex[sp3dev] | emwe: ok, i have committed that stuff for you. let's forget about that once and for all |
| 16:53.06 | Cotulla | common for 5 devices and separate for RHO |
| 16:53.22 | emwe | Alex[sp3dev]: now just commit some "time", please ;) |
| 16:53.37 | Alex[sp3dev] | emwe: what? |
| 16:54.02 | emwe | Alex[sp3dev]: time. free time. hobby time. |
| 16:54.55 | Cotulla | but it can be only true for mmc. it seems not very different for every device. other modules are usually more different. |
| 16:55.12 | phh | h2w is different for each device ? |
| 16:55.29 | Cotulla | I don't know much about it now |
| 16:55.46 | jonpry | emwe, i haven't tested holes, but i had same problem as alex |
| 16:56.04 | Cotulla | and it can be cloned for some device, if it won't work good |
| 16:56.11 | Alex[sp3dev] | jonpry: since applying the second patch for holes, i'm not experiencing it anymore |
| 16:56.13 | Cotulla | if some extra logic needed for some device |
| 16:56.18 | emwe | jonpry: then i've been just lucky with 4mb aligned regions. |
| 16:56.32 | emwe | jonpry: (haven't checked our memlayout though to assert that) |
| 16:57.34 | jonpry | yeah i don't totally understand what "holes" are. but 4mb sounds about right as that is arm big page size |
| 16:58.23 | jonpry | but i am reluctant to use that hole code, it has screwed me before |
| 16:58.46 | Cotulla | they are not 16? |
| 16:59.01 | jonpry | i think it is best to use like no ram, until system is running well enough that you have some chance of finding out it is broken |
| 16:59.01 | Alex[sp3dev] | jonpry: we're using holes on 27.. it was introduced when mem layout was reworked by phh iirc |
| 16:59.14 | Cotulla | yes supersections - 16mb |
| 16:59.17 | phh | you can't do dual banks without hole |
| 16:59.21 | Cotulla | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211i/I1002400.html |
| 16:59.25 | phh | because radio makes memory discontiguous |
| 16:59.29 | Cotulla | mapping sizes are 4KB, 64KB, 1MB, and 16MB |
| 17:00.03 | Cotulla | 4k & 64k by coarse table, 1mb by sections, 16mb by super sections |
| 17:00.22 | jonpry | phh: i think you are wrong |
| 17:00.44 | jonpry | even without radio, banks are always separated |
| 17:00.48 | phh | jonpry: na |
| 17:00.52 | phh | sometimes they are not separated |
| 17:00.57 | phh | but that's doesn't happen often |
| 17:00.59 | jonpry | its possible |
| 17:01.03 | phh | so ok, you can delete the "because radio blabla" |
| 17:01.05 | *** join/#htc-linux Erikson (~Erik@p54B772C6.dip.t-dialin.net) |
| 17:01.34 | jonpry | but unlikely, sdram controllers alway separated enough for some non existantly large pieces of ram |
| 17:01.50 | phh | jonpry: latest topaz has one-die ram :p |
| 17:02.27 | jonpry | well anyways, why would there be special option to deal with the 90% case |
| 17:02.36 | phh | ? |
| 17:02.47 | phh | I think I missed something. |
| 17:02.49 | jonpry | 90% of systems with more than one bank, have physical hole |
| 17:02.54 | phh | yes |
| 17:03.04 | jonpry | and hole option not for that |
| 17:03.25 | *** join/#htc-linux GlemSom (~glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk) |
| 17:03.30 | phh | ok, I hadn't understand you complain about the fact it's an option, i thouoght it was about it at all |
| 17:04.13 | jonpry | i think cotulla is right, 16MB boundaries are the key |
| 17:04.42 | jonpry | Alex[sp3dev]: i emailed you my contraption |
| 17:04.56 | jonpry | its all free of that ksc_kovsky stuff :p |
| 17:04.59 | Alex[sp3dev] | http://comments.gmane.org/gmane.linux.ports.arm.kernel/77195 - in flatmem, memory bank end addresses must be MAX_ORDER_NR_PAGES aligned |
| 17:05.23 | Cotulla | why they just can't implement normal memory managment? |
| 17:05.36 | Cotulla | with sections & coarse tables? |
| 17:05.38 | Alex[sp3dev] | Cotulla: because they're lazy |
| 17:05.52 | Cotulla | I guess they want problems on their ass |
| 17:05.53 | *** join/#htc-linux toastcfh (teamwin@teamw.in) |
| 17:07.01 | Cotulla | hm my config already have CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y |
| 17:07.21 | Cotulla | there also HOLES_IN_ZONE=y |
| 17:07.24 | jonpry | MAX_ORDER = 11, so NR_PAGES = 1024 |
| 17:07.27 | Alex[sp3dev] | lucky bastard |
| 17:07.31 | jonpry | or 4MB |
| 17:09.52 | *** join/#htc-linux gauner1986 (~Miranda@46.115.96.149) |
| 17:10.19 | jonpry | lol, the code just rounds up bank end to align it |
| 17:10.34 | Alex[sp3dev] | which code? |
| 17:10.52 | jonpry | http://lxr.free-electrons.com/source/arch/arm/mm/init.c#L435 |
| 17:11.28 | Alex[sp3dev] | jonpry: that is not in 35 |
| 17:14.10 | *** join/#htc-linux crawling_ (crawling@a94-132-169-99.cpe.netcabo.pt) |
| 17:16.00 | jonpry | looks like wrong architecture too |
| 17:16.18 | *** join/#htc-linux crawling (~crawling@a94-132-169-99.cpe.netcabo.pt) |
| 17:17.59 | *** join/#htc-linux |Jeroen| (~jeroen@d5152B25B.access.telenet.be) |
| 17:20.07 | *** part/#htc-linux t3g (~t3g@p3E9E3007.dip.t-dialin.net) |
| 17:25.12 | *** join/#htc-linux Samsunguy (~Samsunguy@65.120.149.2) |
| 17:25.29 | *** join/#htc-linux Vetta- (~asd@stgt-5f7012ca.pool.mediaWays.net) |
| 17:26.46 | Cotulla | anybody know where native android devices turns on USBPHY power? |
| 17:49.45 | jonpry | Alex[sp3dev]: where is your .35 tree? |
| 17:51.26 | *** join/#htc-linux mastermerlin1 (~Adium@p4FEE5191.dip.t-dialin.net) |
| 17:51.31 | *** join/#htc-linux gauner1986 (~Miranda@46.115.96.149) |
| 17:52.14 | Alex[sp3dev] | jonpry: http://gitorious.org/~ast/linux-on-qualcomm-s-msm/alex-linux-xperia the android-2.6.35 branch |
| 17:52.18 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 17:52.20 | *** join/#htc-linux lknd (~kvirc@95-28-72-91.broadband.corbina.ru) |
| 17:52.43 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 17:54.37 | *** join/#htc-linux dan1j3l (~danijel@93-141-110-166.adsl.net.t-com.hr) |
| 18:01.01 | *** join/#htc-linux kiozen (~kiozen@rgnb-5d878b3b.pool.mediaWays.net) |
| 18:01.32 | *** join/#htc-linux b__ (521ff2e0@gateway/web/freenode/ip.82.31.242.224) |
| 18:01.34 | b__ | WAAAGWANN |
| 18:01.42 | arrrghhh | do what now |
| 18:01.45 | *** join/#htc-linux Segnale007 (~Segnale00@host235-5-dynamic.22-79-r.retail.telecomitalia.it) |
| 18:09.59 | *** join/#htc-linux Berger (noreply@c65wn1.wifi.halden.net) |
| 18:11.22 | jonpry | Alex[sp3dev], i forgot to mention that you need to set has_clamshell=0 in pdata |
| 18:12.29 | jonpry | er i guess kovsky has clamshell |
| 18:12.31 | *** join/#htc-linux Nautis (6318d8ca@gateway/web/freenode/ip.99.24.216.202) |
| 18:17.24 | *** join/#htc-linux gauner1986 (~gauner198@p5B382F4C.dip.t-dialin.net) |
| 18:17.45 | *** join/#htc-linux rob_w (~bob@ppp-188-174-80-205.dynamic.mnet-online.de) |
| 18:21.32 | emwe | Alex[sp3dev]: the rpc-reply wait timeout i mentioned earlier was because of the switched-up rpc_audmgr_cb_func_ptr fields. working fine now. thx for finding that one in the visually undocumented .27... |
| 18:22.01 | Alex[sp3dev] | emwe: great |
| 18:22.58 | Cotulla | ))) |
| 18:23.01 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
| 18:23.14 | *** join/#htc-linux balans1 (~Gebruiker@82-170-217-205.ip.telfort.nl) |
| 18:23.16 | Alex[sp3dev] | emwe: right, another struct to hack?) |
| 18:23.34 | Alex[sp3dev] | i wonder why wifi sdio doesn't work for me on 35 |
| 18:23.58 | emwe | tiwlan? userland wifi_loader doesn't even like to . dunno if related |
| 18:24.28 | emwe | Alex[sp3dev]: stinebd asked if we could get compat-wireless working isntead of tiwlan |
| 18:24.28 | Alex[sp3dev] | emwe: no, the wifi card is not detected. messing with wifi power in kovsky mmc |
| 18:24.43 | Alex[sp3dev] | emwe: basically, i want wl12xx to work for us |
| 18:24.47 | emwe | ah cool |
| 18:25.11 | emwe | i think theres some issue with wpa_supplicant and both stacks. but i think stinebd can explain that better |
| 18:25.46 | Alex[sp3dev] | userspace is bryan's stuff.. i need to get kernel side working first |
| 18:26.22 | emwe | yes, of course. there's issues with bcm and tiwlan using the same shipped wpa_supplicant or something |
| 18:26.40 | emwe | a hack/change to wpa_supplicant is required for on of the two and has impact on the other.... |
| 18:26.40 | Alex[sp3dev] | huh. you know what i always say? android sucks |
| 18:26.43 | emwe | lol |
| 18:26.48 | emwe | i like it :P |
| 18:26.52 | emwe | but let's not start about that |
| 18:27.05 | emwe | stinebd can explain that better. |
| 18:27.06 | Alex[sp3dev] | if those mofos'd just used standard libraries instead of reinventing the wheel.. |
| 18:27.18 | emwe | then you'd have more time for your studies :) |
| 18:27.38 | emwe | i am afk a bit. |
| 18:28.14 | *** join/#htc-linux greg- (greg-@port-13434.pppoe.wtnet.de) |
| 18:29.22 | arrrghhh | Alex[sp3dev], i kinda have an understanding of what's going on with wifi and wpa_supplicant |
| 18:29.34 | arrrghhh | basically WEP doesn't work on bcm with the current wpa_supplicant |
| 18:29.40 | Alex[sp3dev] | arrrghhh: no, i'm working on kernel now |
| 18:29.46 | arrrghhh | ok |
| 18:30.09 | Alex[sp3dev] | i bet it will 'just work' if we manage to get wl12xx running |
| 18:31.13 | *** join/#htc-linux onen|openBmap (~quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
| 18:34.41 | emwe | Alex[sp3dev]: yes, that's what stinebds been saying because tiwlan would be away then. |
| 18:35.31 | Cotulla | what means [ 0.399505] 0x05ac00000000-0x105000000000 : "system" |
| 18:35.31 | Cotulla | [ 0.399719] mtd: partition "system" is out of reach -- disabled? |
| 18:36.00 | Alex[sp3dev] | maybe that you've made to stretch beyond chip end? |
| 18:36.11 | jonpry | is that many gigabytes? |
| 18:36.23 | Alex[sp3dev] | jonpry: nanobytes |
| 18:36.25 | Cotulla | ohh |
| 18:36.27 | Cotulla | shit |
| 18:36.27 | Cotulla | yes |
| 18:36.41 | Cotulla | 5808 GB |
| 18:36.41 | Cotulla | O_o |
| 18:36.45 | Cotulla | 5TB |
| 18:36.53 | Cotulla | something wrong somewhere |
| 18:39.37 | *** join/#htc-linux AgentBlair (~AgentBlai@adsl-67-124-200-190.dsl.sndg02.pacbell.net) |
| 18:44.59 | *** join/#htc-linux gauner1986 (~gauner198@p5B382F4C.dip.t-dialin.net) |
| 18:52.20 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
| 19:03.34 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 19:05.40 | *** join/#htc-linux Markinus7299 (~Miranda@212.255.18.217) |
| 19:16.19 | jonpry | Alex[sp3dev], you get hangs with keypad too? |
| 19:17.03 | Alex[sp3dev] | jonpry: not yet. striking with wifi |
| 19:17.17 | jonpry | ic |
| 19:18.16 | Alex[sp3dev] | what could it mean if mmc1 is queing 'unknown' cis tuples and then kernel kills it because of some slowdown warning? |
| 19:18.38 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-18-145-141.client.mchsi.com) |
| 19:19.02 | jonpry | like ratelimit? |
| 19:19.17 | Alex[sp3dev] | well, will boot and give you dmesg |
| 19:20.51 | *** join/#htc-linux GPFerror (~GPF@ip72-208-193-231.ph.ph.cox.net) |
| 19:21.52 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 19:22.16 | Alex[sp3dev] | jonpry: http://pastebin.com/YEeHg4hT |
| 19:24.07 | jonpry | i don't think that is a problem |
| 19:24.34 | Alex[sp3dev] | maybe we just should not enable interrupt and handle that to wl12xx driver so that when crap comes from wifi it handles it? |
| 19:24.56 | jonpry | you can tell the subsystem that a tuple is "real" then it won't print to dmesg |
| 19:25.07 | jonpry | but either way it will be delivered over the interface |
| 19:25.23 | Alex[sp3dev] | ah. guess i need to look into initializing wl12xx then |
| 19:25.41 | jonpry | or just power it off |
| 19:25.54 | jonpry | your probably getting data off of the wire :p |
| 19:26.01 | *** join/#htc-linux kvaster_ (~kvaster@93.84.112.82) |
| 19:26.25 | jonpry | there is a wifi reset pin somewhere no? |
| 19:26.33 | Alex[sp3dev] | no |
| 19:27.14 | jonpry | hmm, there is one for rhod |
| 19:27.19 | jonpry | but bcm |
| 19:28.05 | *** join/#htc-linux Erikson (~Erik@p54B772C6.dip.t-dialin.net) |
| 19:28.20 | jonpry | you have wifi vreg's? |
| 19:28.25 | Alex[sp3dev] | yes |
| 19:28.34 | jonpry | cycle power maybe? |
| 19:28.57 | Alex[sp3dev] | maybe. if i cycle power gpio, it doesn't come up at all |
| 19:29.52 | jonpry | still get this? mmc1: card claims TO support voltages below the defined range. These will be ignored. |
| 19:30.03 | Alex[sp3dev] | yes. why 'still' ? |
| 19:30.08 | jonpry | i think that is good sign |
| 19:30.18 | jonpry | means card is powered on and alive |
| 19:30.29 | Alex[sp3dev] | then i'll powercycle vreg |
| 19:30.30 | jonpry | so if you can get that without spam, all is well |
| 19:33.13 | *** join/#htc-linux Noellenchris (~kvirc@pool-173-61-114-241.cmdnnj.fios.verizon.net) |
| 19:34.16 | *** join/#htc-linux Pr0z (Pr0z@bzq-84-109-110-46.red.bezeqint.net) |
| 19:35.53 | *** join/#htc-linux leobaillard (~leobailla@secteur7.org) |
| 19:37.21 | *** join/#htc-linux balans1 (~Gebruiker@82-170-217-205.ip.telfort.nl) |
| 19:38.37 | *** join/#htc-linux toer (~tore@179.81-166-86.customer.lyse.net) |
| 19:41.53 | *** join/#htc-linux Samsunguy (~Samsunguy@65.120.149.2) |
| 19:42.09 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 19:46.59 | *** join/#htc-linux RaiderX (~RaiderX@91.109.42.113) |
| 19:47.41 | *** join/#htc-linux DJWillis (djwillis@cpc3-bath5-2-0-cust220.aztw.cable.virginmedia.com) |
| 19:48.26 | *** join/#htc-linux stroughtonsmith (~steven@86-44-84-134-dynamic.b-ras2.bbh.dublin.eircom.net) |
| 19:48.30 | RaiderX | Hi |
| 19:51.55 | *** join/#htc-linux jonpry (~jon@63.245.31.4) |
| 19:52.40 | *** join/#htc-linux snq (~snq@son.iqid.eu) |
| 20:02.29 | *** join/#htc-linux crawling (~crawling@a94-132-169-99.cpe.netcabo.pt) |
| 20:06.17 | *** join/#htc-linux ollip79 (~ollip79@brsg-4dbb1726.pool.mediaWays.net) |
| 20:09.03 | *** join/#htc-linux crawling (crawling@a94-132-169-99.cpe.netcabo.pt) |
| 20:10.04 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/ip.86.134.32.198) |
| 20:12.18 | *** join/#htc-linux ollip79 (~ollip79@brsg-4dbb1726.pool.mediaWays.net) |
| 20:12.25 | *** part/#htc-linux ollip79 (~ollip79@brsg-4dbb1726.pool.mediaWays.net) |
| 20:17.01 | RaiderX | Cotulla |
| 20:19.25 | *** join/#htc-linux imilka (~imilka@95-28-72-91.broadband.corbina.ru) |
| 20:19.36 | RaiderX | any news on magldr support for WP7 NoDo? |
| 20:20.14 | *** join/#htc-linux crawling_ (crawling@a94-132-169-99.cpe.netcabo.pt) |
| 20:20.49 | NeoMatrixJR | ~seen viruscrazy |
| 20:20.52 | apt | i haven't seen 'viruscrazy', NeoMatrixJR |
| 20:33.46 | *** join/#htc-linux crawling (crawling@94.132.169.99) |
| 20:35.30 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 20:38.33 | *** join/#htc-linux Fjodor (~sune@2001:16d8:ee1e:0:226:18ff:fe2d:dc4f) |
| 20:42.57 | *** join/#htc-linux arrrghhhTP2 (~arrrghhh_@68-241-175-130.pools.spcsdns.net) |
| 20:43.21 | *** part/#htc-linux RaiderX (~RaiderX@91.109.42.113) |
| 20:47.46 | *** join/#htc-linux imilka1 (~kvirc@95-28-72-91.broadband.corbina.ru) |
| 20:51.42 | *** join/#htc-linux Sisco (~Sisco@unaffiliated/sisco) |
| 20:51.44 | Sisco | I have a HTC G2 "bricked", I try PC10IMG method, but get "Main Version is older", how can I fix this? |
| 20:52.16 | arrrghhhTP2 | Sisco: you'll have better luck in ##android |
| 20:52.26 | arrrghhhTP2 | This room is for porting to Android. |
| 20:52.35 | Sisco | Haha okay thank you |
| 20:52.38 | arrrghhhTP2 | Np |
| 21:00.38 | *** join/#htc-linux programmer8922 (~Evan@67.219.164.162) |
| 21:08.37 | *** join/#htc-linux dekar (~dekar@drms-590ec5d5.pool.mediaWays.net) |
| 21:09.35 | *** join/#htc-linux gauner1986 (~Adium@p5B382F4C.dip.t-dialin.net) |
| 21:09.37 | *** join/#htc-linux mes (~mes@sentry.lazo.ca) |
| 21:12.43 | mes | any one else having problems with gitorious? I get: fatal: object c95fd72c3bb96886a9862d27533ef20d650e32be is corrupted |
| 21:16.51 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net) |
| 21:18.34 | WisTilt2 | emwe: did those tests on the arm9 suspend/resume and looks like on resume there is only around 150-200ms wakeup delay at worst. |
| 21:19.00 | WisTilt2 | never saw anything hang on the rpc calls |
| 21:20.40 | WisTilt2 | jonpry: you get my email? hopefully i sent it to the right one |
| 21:21.03 | *** join/#htc-linux manusfreedom_ (~manusfree@tra78-1-82-235-115-79.fbx.proxad.net) |
| 21:25.18 | *** join/#htc-linux DuperMan (~Duper@109-186-15-140.bb.netvision.net.il) |
| 21:26.04 | *** join/#htc-linux pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net) |
| 21:27.42 | *** join/#htc-linux stroughtonsmith (~steven@86-44-84-134-dynamic.b-ras2.bbh.dublin.eircom.net) |
| 21:28.03 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/ip.86.134.32.198) |
| 21:39.01 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
| 21:41.56 | *** join/#htc-linux ImCoKeMaN (~imcokeman@pool-96-249-148-95.hrbgpa.fios.verizon.net) |
| 21:56.11 | *** join/#htc-linux ftoz (~root@cst-prg-233-2.vodafone.cz) |
| 21:56.20 | *** join/#htc-linux eval- (~eval@g231173210.adsl.alicedsl.de) |
| 21:58.25 | eval- | how much have the android bits (ashmem, pmem, logger, binder) changed across kernel versions? do the .27/.29 trees have things backported from newer kernels to support froyo/gingerbread? |
| 22:00.01 | *** join/#htc-linux arrrghhhTP2 (~arrrghhh_@68-241-175-130.pools.spcsdns.net) |
| 22:01.04 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 22:03.22 | emwe | WisTilt2: re. ah thanks for the info. though 150-200ms added to some other wakeup procedures still adds up. thanks for evaluating that, nevertheless! |
| 22:03.56 | *** join/#htc-linux KrassRattus (5898f0be@gateway/web/freenode/ip.88.152.240.190) |
| 22:04.06 | KrassRattus | hello |
| 22:04.29 | KrassRattus | can everybody help me |
| 22:04.34 | KrassRattus | i'm from germany |
| 22:04.37 | arrrghhh | everybody at once?' |
| 22:04.46 | arrrghhh | doesn't sound like a problem |
| 22:04.52 | MN-- | im from uk |
| 22:04.56 | WisTilt2 | emwe: np. sometimes it was under 100ms but mostly in the 150-200ms range. |
| 22:04.59 | KrassRattus | i have a HTC Touch Pro 2 |
| 22:05.13 | arrrghhh | KrassRattus, this isn't a support channel, if that's what you're looking for. |
| 22:05.19 | arrrghhh | come over to #xdandroid, we can help you there. |
| 22:05.23 | KrassRattus | yes |
| 22:05.26 | MN-- | KrassRattus: if you need support go to #xdandroid |
| 22:05.32 | arrrghhh | wins |
| 22:05.38 | arrrghhh | :P |
| 22:05.45 | MN-- | hangs his head in shame |
| 22:05.48 | MN-- | :P |
| 22:05.49 | emwe | WisTilt2: but good to know that area is ok ;) |
| 22:06.06 | arrrghhh | lol |
| 22:07.05 | Cotulla | u may start to sold support certificates |
| 22:07.10 | Cotulla | :P |
| 22:11.29 | arrrghhh | WisTilt2, how goes it sir |
| 22:13.48 | WisTilt2 | arrrghhh, just looking over the ril stuff a bit. did you try that AT command last night by chance? |
| 22:14.29 | arrrghhh | that SERV one? |
| 22:14.46 | arrrghhh | i was successful with the BSINFO one |
| 22:14.47 | WisTilt2 | yeah, both actually but was curious what you'd get with the SERV |
| 22:14.53 | arrrghhh | hrm |
| 22:14.55 | arrrghhh | didn't try the SERV |
| 22:15.05 | arrrghhh | and oddly enough today, i wasn't able to get the BSINFO one working correctly either |
| 22:15.14 | arrrghhh | so either the method we're using to debug it is wrong |
| 22:15.21 | arrrghhh | or it's just difficult to debug the radio... |
| 22:15.32 | *** join/#htc-linux g3rm (~germo@89-77-81-175.dynamic.chello.pl) |
| 22:15.35 | arrrghhh | basically the stop ril-daemon command only seems to work a small percentage of the time. |
| 22:15.56 | arrrghhh | and if the ril-daemon is still running, trying to pass commands to the radio thru adb locks up the phone. |
| 22:15.56 | WisTilt2 | well, sending the BSINFO then plugging in the returned values into the array looks like it will be pretty easy to do. |
| 22:16.06 | *** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net) |
| 22:16.24 | arrrghhh | cool. |
| 22:16.42 | WisTilt2 | should work inside of ril during power up i'd think |
| 22:16.56 | arrrghhh | i wasn't really clear on what the SERV command was for... |
| 22:16.56 | arrrghhh | i can try it when i get home, like i said i had a bunch of issues with it at work today |
| 22:17.02 | arrrghhh | even snagged one of my friend's RHOD's, had just as much trouble. |
| 22:17.09 | WisTilt2 | that command should return your registered network info |
| 22:17.30 | arrrghhh | ah |
| 22:17.30 | arrrghhh | ok |
| 22:17.46 | arrrghhh | bleh, i still have 3.5hrs left at work :/ |
| 22:18.13 | arrrghhh | stupid job, keeping me from working on android :P |
| 22:18.24 | WisTilt2 | :( i came to the office a couple hours ago to mess with this stuff. easier here on my 2 widescreens |
| 22:18.53 | WisTilt2 | when you own the company you can play when you want :) |
| 22:19.51 | WisTilt2 | emwe: one more thing on that area... where did we get the 2 mode numbers from? |
| 22:19.54 | arrrghhh | heh |
| 22:20.14 | arrrghhh | yea the proxy here really hinders testing... |
| 22:20.25 | arrrghhh | kinda need the phone for IRC, but i also need it for testing... bleh. |
| 22:20.45 | WisTilt2 | you need several phones at your desk, that will go over with your boss im sure |
| 22:20.46 | emwe | WisTilt2: if git log doesn't tell, perhaps the old htc-voque tree on androidhtc call tell. |
| 22:21.01 | emwe | WisTilt2: assume it came over on import already. |
| 22:21.06 | arrrghhh | WisTilt2, lol |
| 22:21.19 | arrrghhh | i had 2 RHODs at one point, it was kinda entertaining. |
| 22:21.28 | WisTilt2 | emwe: k, ill take a look. i dont see any bitmasks in the arm docs that match those so just wondering where they came from. |
| 22:24.11 | WisTilt2 | i think jonpry fell asleep down under a coconut tree. i need to pick his brain on some console stuff |
| 22:24.38 | emwe | WisTilt2: it's in the git logs. phh added it on 2010-01-30 and following commits |
| 22:24.58 | *** join/#htc-linux SG (~chatzilla@cpe-76-186-50-40.tx.res.rr.com) |
| 22:24.58 | arrrghhh | jonpry wanted to talk to you about the netloc stuff for CDMA too WisTilt2 |
| 22:25.05 | arrrghhh | sorry 'bout last night, i nodded off :P |
| 22:25.24 | WisTilt2 | emwe: thanks, that saves me looking for it:) |
| 22:25.50 | WisTilt2 | arrrghhh, np. figured your gf was all over your case and you had to spend time with her. |
| 22:25.58 | *** join/#htc-linux SG_ (~chatzilla@cpe-76-186-50-40.tx.res.rr.com) |
| 22:26.01 | *** join/#htc-linux crawling (~crawling@a94-132-169-99.cpe.netcabo.pt) |
| 22:26.33 | arrrghhh | lol |
| 22:26.34 | arrrghhh | not anymore than usual |
| 22:26.59 | *** join/#htc-linux SG__ (~chatzilla@cpe-76-186-50-40.tx.res.rr.com) |
| 22:28.16 | *** join/#htc-linux Samsunguy_ (~chatzilla@cpe-76-186-50-40.tx.res.rr.com) |
| 22:29.09 | *** join/#htc-linux XBmod (~xmicky@ANice-152-1-61-227.w86-193.abo.wanadoo.fr) |
| 22:33.10 | *** join/#htc-linux ElFinLazz (~elfinlazz@112.154.189.103) |
| 22:38.24 | *** join/#htc-linux Wally (~wally@c-75-73-178-169.hsd1.mn.comcast.net) |
| 22:39.50 | *** join/#htc-linux nineX_ (~nunya@216-43-173-182.ip.mcleodusa.net) |
| 22:40.40 | *** join/#htc-linux swc|666 (~x00@unaffiliated/swc666/x-4934821) |
| 22:56.58 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 23:19.10 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
| 23:27.54 | *** join/#htc-linux arrrghhh (~arrrghhh@68-241-175-130.pools.spcsdns.net) |
| 23:31.53 | *** part/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |
| 23:38.01 | *** join/#htc-linux MN--2 (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 23:42.21 | *** join/#htc-linux Erikson (~Erik@p54B772C6.dip.t-dialin.net) |
| 23:44.37 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
| 23:59.43 | *** join/#htc-linux GNUtoo|oeee (~GNUtoo@host68-143-dynamic.54-79-r.retail.telecomitalia.it) |