00:14.57 | *** join/#htc-linux toastcfh_ (~toastcfh@unaffiliated/toastcfh) |
00:26.45 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
00:40.20 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
00:56.02 | *** part/#htc-linux ayaka (sicelo@gateway/shell/globalshellz/x-izcqhtusmgxisbyp) |
01:16.08 | *** join/#htc-linux whitglint (~whitglint@122-117-115-146.HINET-IP.hinet.net) |
01:22.41 | *** join/#htc-linux toastcfh (~toastcfh@unaffiliated/toastcfh) |
01:50.20 | *** join/#htc-linux eR^zeRa` (zzeratul@kaj-0011.koleje.cuni.cz) |
02:12.05 | *** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring) |
02:30.09 | *** join/#htc-linux toastcfh (~toastcfh@unaffiliated/toastcfh) |
03:31.49 | *** join/#htc-linux CptAJ (AJ@186.90.180.107) |
03:32.39 | CptAJ | greetings and salutations to you all, fine gentlemen of the IRC |
03:38.33 | CptAJ | So I talked to JC and saw he was struggling with gsensor. Pulled the DLL, "BOSCH BMA150" definitely in there on strings, amigos (http://dl.dropbox.com/u/38620067/GSensor.dll). So I went my merry way and pillaged the rhodium boardfile for the code, put it on whitestone and presto! .... it didn't work. log: http://paste2.org/p/2039363 |
03:38.40 | CptAJ | what might I have missed? |
03:39.43 | CptAJ | I saw this line on the h file for rhod "#define RHODIUM_GSENSOR_MOT49/* microp interrupt for 3.5mm detect */" but that did seem to be used elsewhere. Wonder why the name =/ |
03:39.49 | *** join/#htc-linux swc|666 (~goldbond@Aircrack-NG/Friend) |
03:44.18 | CptAJ | guess I'm the only one burning the midnight oil =( |
03:44.41 | CptAJ | bummer. was really psyched to sneak in some moonlighting dev work tonight XD |
04:15.07 | *** join/#htc-linux apt (~apt@rikers.org) |
04:15.07 | *** topic/#htc-linux is Welcome to the HTC Linux project | Community portal & WiKi http://htc-linux.org | For IRC logs, HaRET & kernel mailing lists etc. see http://htc-linux.org/wiki/index.php?title=Contact | The htc-linux.org project is not affiliated with the HTC Corporation | This channel is for development purposes - Join #htc-linux-chat for offtopic |
05:33.53 | *** join/#htc-linux rpierce99_ (~rpierce99@96-42-107-19.dhcp.stcd.mn.charter.com) |
06:09.27 | *** join/#htc-linux ayaka (sicelo@gateway/shell/globalshellz/x-izcqhtusmgxisbyp) |
06:33.08 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-uwyagjddlxtbovod) |
06:48.26 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-mhfggwczivxqqpoj) |
07:17.15 | *** join/#htc-linux mastermerlin (~Adium@pD9FE29E5.dip.t-dialin.net) |
07:19.25 | *** join/#htc-linux BHSPitMonkey (~stephen@unaffiliated/bhspitmonkey) |
07:20.04 | *** join/#htc-linux jonpry (~jon@c-24-17-200-206.hsd1.wa.comcast.net) |
07:32.21 | *** join/#htc-linux polyrhythmic (~polyrhyth@c-24-17-231-236.hsd1.wa.comcast.net) |
08:01.45 | *** join/#htc-linux fakker (fakker@cpc13-hitc6-2-0-cust129.9-2.cable.virginmedia.com) |
08:14.53 | *** join/#htc-linux NeoMatrixJR_away (~NeoMatrix@173-18-84-218.client.mchsi.com) |
08:58.20 | *** join/#htc-linux whitglint (~whitglint@122-117-115-146.HINET-IP.hinet.net) |
09:09.01 | *** join/#htc-linux tmzt (~tmzt@adsl-99-164-36-137.dsl.akrnoh.sbcglobal.net) |
09:20.35 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-236-154.dynamic.sbb.rs) |
09:32.59 | *** join/#htc-linux eR^zeRa` (zzeratul@kaj-0011.koleje.cuni.cz) |
10:25.40 | *** join/#htc-linux ychavan (ychavan@nat/redhat/x-juniywtfmutcoogn) |
10:57.40 | *** join/#htc-linux milaq (~milaq@h2041382.stratoserver.net) |
10:58.56 | *** join/#htc-linux milaq|afk (~milaq@h2041382.stratoserver.net) |
11:01.26 | *** join/#htc-linux milaq (~milaq@h2041382.stratoserver.net) |
11:28.58 | *** join/#htc-linux marc1706 (~Marc@phpbb/modifications/marc1706) |
11:58.08 | *** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl) |
13:00.48 | *** join/#htc-linux rajkosto (~rajkosto@wan.rajkonet.info) |
13:30.59 | *** join/#htc-linux helicopter88 (~helicopte@host199-113-dynamic.47-79-r.retail.telecomitalia.it) |
13:54.08 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
14:01.58 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
14:16.20 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
14:24.17 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-236-154.dynamic.sbb.rs) |
14:25.10 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-236-154.dynamic.sbb.rs) |
14:26.28 | *** join/#htc-linux bitrot (~rajkosto@wan.rajkonet.info) |
14:31.45 | detule | CptAJ, have you tried outputting this value that's failing for you guys -> https://gitorious.org/linux-msm-rhod/linux-msm-rhod/blobs/htc-msm-3.3/drivers/input/misc/bma150.c#line685 |
14:32.28 | ayaka | can I ask some question about lk_bootloader here |
14:32.47 | detule | i mean it could be some sort of a version mismatch, in which case you should try just commenting out that if-else block that follows altogether and see what that gets you |
14:44.06 | detule | oh i just saw your pastebin - the value is in the log...not a version mismatch |
14:47.22 | *** join/#htc-linux helicopter88 (~helicopte@host199-113-dynamic.47-79-r.retail.telecomitalia.it) |
14:48.33 | detule | i would try changing i2c_check_functionality(client->adapter, I2C_FUNC_I2C) to i2c_check_functionality(client->adapter, I2C_FUNC_I2C | I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_SMBUS_WRITE_BYTE_DATA) |
14:51.53 | detule | though that might not be a representative of the actual functionality either.... |
14:54.40 | *** join/#htc-linux helicopter88_2 (~helicopte@host13-82-dynamic.37-79-r.retail.telecomitalia.it) |
14:56.52 | *** part/#htc-linux ayaka (sicelo@gateway/shell/globalshellz/x-izcqhtusmgxisbyp) |
15:10.42 | *** join/#htc-linux dan1j3l (~danijel@93-136-16-7.adsl.net.t-com.hr) |
15:24.59 | detule | right, i2c_check_functionality doesn't actually probe for functionality, it just reports whatever msm-i2c tells it to so scratch that...at any rate CptAJ -> have you guys traced in haret to check whether the client address is the same as rhod, when I trace the gsensor activity in haret i can clearly see our address (0x70>>1) http://pastebin.com/zMbQ5ATK |
15:29.18 | *** join/#htc-linux helicopter88 (~helicopte@host13-82-dynamic.37-79-r.retail.telecomitalia.it) |
15:37.19 | CptAJ | alright, tried all that. not working ofcourse. let me do the trace |
15:40.50 | *** join/#htc-linux l0wbra1n (~l0wbra1n@unaffiliated/l0wbra1n) |
15:46.26 | CptAJ | did a trace with "addlist mmutrace 0xb2300000 0x100000" that should give me the whole range right? well, I'm not seeing anything there reacting when I move the phone... |
15:46.44 | detule | addlist mmutrace 0xb2300000 4 |
15:47.04 | detule | that's for the writes, the reads should be 0xb230000c 4 |
15:47.41 | detule | i don't get activity when i move the phone but if i go in settings on my ROM i have a GSensor tool used to calibrate the sensor |
15:47.43 | detule | it lights up then |
15:47.46 | *** join/#htc-linux Alex[sp3dev] (d5551202@gateway/web/freenode/ip.213.85.18.2) |
15:47.50 | *** join/#htc-linux JC_ (ba5dad4e@gateway/web/freenode/ip.186.93.173.78) |
15:48.20 | CptAJ | ah, I see. its not active all the time, thats probably why I dont see it |
15:48.24 | CptAJ | lets test again |
15:48.54 | detule | scanning to large of a range will give you the writes and reads together -> you just want the (str) prefaced ones (writes) |
15:48.56 | CptAJ | JC_ <---- bet this guy is gonna be happy to see us here talking XD |
15:50.02 | JC_ | Whats up |
15:50.46 | CptAJ | working hard for the money >_> |
15:51.03 | detule | btw not sure if this will work, but technically, you should'nt have to recompile the kernel everytime you want to register an i2c device at a new address....you should be able to do something like "echo bma150 0x68 > /sys/bus/i2c/devices/i2c-0/new_device" |
15:51.23 | JC_ | I logged in... Cause im trying the i2cdetect and the phone hang up in the first read of the i2c |
15:51.52 | JC_ | :s So I cant probe the 38 address |
15:52.29 | detule | 38 won't work....i2cdetect just does i2c_smbus_write which is what's failing in bma150_probe |
15:53.59 | JC_ | So... Its not reading that register |
15:54.33 | detule | likely no client at that address but what do i know |
15:54.45 | detule | let's see if haret tracing can spit out the addy |
15:55.36 | CptAJ | http://paste2.org/p/2039900 here we go |
15:55.40 | CptAJ | lively now |
15:55.41 | *** join/#htc-linux DuperMan (~Duper@93-173-151-96.bb.netvision.net.il) |
15:55.52 | *** join/#htc-linux dan1j3l (~danijel@78-0-198-197.adsl.net.t-com.hr) |
15:56.43 | detule | my guess |
15:56.51 | detule | (0xce>>1) |
15:57.03 | detule | oh 0x68 |
15:57.24 | DuperMan | DERP |
15:58.03 | detule | if one of you is in haret |
15:58.06 | detule | i mean android |
15:58.22 | detule | you could just try echo bma150 0x68 > /sys/bus/i2c/devices/i2c-0/new_device |
15:58.54 | detule | then check dmesg |
15:59.49 | JC_ | It hangs the device |
16:00.10 | detule | well it was an unproven method:) doesn't necessarily means failure, i guess recompile the ernel |
16:00.15 | CptAJ | you mean 78, det? |
16:00.23 | detule | oh perhaps my math is wrong |
16:00.40 | detule | pretty sure cc>>1 is 0x66 |
16:00.54 | CptAJ | ah, sorry. I was looking for 68 on the log |
16:02.01 | detule | at any rate i would try recompiling the kernel with 0x68 (this would match the rhod trace-to-kernel setup) and if that fails maybe 0x69...that's all the ideas i have |
16:02.21 | CptAJ | trying |
16:03.37 | jonpry | that gsensor calibrate thing might be what you need to find the gpio that power it |
16:04.28 | detule | yeah aparently rhod never powers the sensor on or off |
16:04.55 | jonpry | or just boot linux while that calibration thing is running |
16:05.00 | detule | though there are some microp commands (BMA150_SLEEP) that the driver sends |
16:05.37 | jonpry | how does that work? hacked up driver? |
16:06.02 | detule | no it's bosch original driver |
16:06.11 | detule | it has some pdata hooks for power_on power_off that we never use |
16:06.34 | jonpry | so where does microp happen then? |
16:06.35 | CptAJ | yeah, the powup down functions dont do anything static int htcrhodium_bma150_power_on(void) |
16:06.36 | CptAJ | { |
16:06.36 | CptAJ | printk(KERN_DEBUG "%s\n", __func__); |
16:06.36 | CptAJ | return 0; |
16:06.36 | CptAJ | } |
16:08.24 | detule | i should've said it just sets the mode via i2c |
16:08.26 | detule | https://gitorious.org/linux-msm-rhod/linux-msm-rhod/blobs/htc-msm-3.3/drivers/input/misc/bma150.c#line241 |
16:10.26 | jonpry | so that is not microp at all |
16:10.28 | DuperMan | f dune. time for moar cake (portal2) |
16:11.42 | detule | my bad too much time looking at panel and leds |
16:13.36 | jonpry | i need to get this 3.4 going |
16:13.49 | JC_ | detule, before you wrote 0xce>>1 |
16:14.15 | jonpry | detule, maybe we can get a slow tls build going for now? |
16:14.28 | JC_ | so is it 67 rigth?? |
16:14.47 | detule | you guys are going to make me pull out a calculator |
16:15.12 | JC_ | Hahaha |
16:16.17 | JC_ | Doing echo bma150 0x67 > /sys/bus/i2c/devices/i2c-0/new_device |
16:17.05 | JC_ | <PROTECTED> |
16:17.25 | detule | ok so 0xce >> 1 is indeed 0x67 |
16:17.39 | jonpry | whats whitestone virtual for gpio and i2c? |
16:18.15 | detule | this might be a problem since we are already registering something at 0x67 |
16:18.24 | detule | on rhod 0x66-0x67 is microp |
16:18.45 | detule | and i think when i was setting up your board file i left the i2c_dummy at 0x67 |
16:18.45 | JC_ | in whitestone 0x67 is the led no? |
16:18.46 | jonpry | it is on whitestone too |
16:19.08 | detule | 0x67 is what used to be microp-ksc i think |
16:19.37 | detule | on rhod, related to the physical keyboard |
16:19.41 | detule | which i guess you guys don't have |
16:20.27 | *** join/#htc-linux dan1j3l1 (~danijel@78-1-150-213.adsl.net.t-com.hr) |
16:21.35 | *** join/#htc-linux helicopter88 (~helicopte@host13-82-dynamic.37-79-r.retail.telecomitalia.it) |
16:21.42 | JC_ | Exactly... We dont have it |
16:22.44 | jonpry | it's almost impossible that bma150 has switched i2c addresses |
16:23.06 | jonpry | and according to gsensor.dll they are hitting klt up for something |
16:23.10 | jonpry | probably power |
16:23.24 | CptAJ | jonpry, http://paste2.org/p/2039900 mmutrace here |
16:23.52 | *** join/#htc-linux dan1j3l (~danijel@93-136-80-54.adsl.net.t-com.hr) |
16:24.19 | jonpry | trace of what? hitting some keys? |
16:25.10 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
16:25.11 | detule | i think he was running the gsensor calibration tool |
16:25.14 | CptAJ | moving the phone around while in gsensor calib tool |
16:25.32 | JC_ | jonpry, any posibility of bma150 was manufactured by another company??? So the first byte of the address is other??? |
16:28.33 | jonpry | i don't think so |
16:29.03 | jonpry | does bma150 use registers 0x77,0x78,0x79 for the results? |
16:30.42 | detule | CptAJ, can you just trace the (str)'s |
16:33.26 | CptAJ | http://paste2.org/p/2039939 |
16:34.47 | jonpry | yeah these registers are nothing like bma150 |
16:35.14 | jonpry | i'm guess they have implemented some kind of bridge inside of microp |
16:35.25 | jonpry | if not most of the driver |
16:35.38 | detule | so they are somehow polling this via microp? |
16:36.12 | jonpry | it isn't clear how the process gets started |
16:36.24 | jonpry | but once its going they just read the values from microp registers |
16:37.42 | detule | oh i thought they keep writing commands to it |
16:37.52 | jonpry | no those are reads |
16:38.24 | detule | i thought the ldrs at b230000c are the reads |
16:38.25 | jonpry | i2c reads show up on the write channel as a write chip address, register adress, read chip adress, stop |
16:39.06 | detule | i think the previous pastebin is just writes |
16:39.18 | DuperMan | tell i2c you have men at ready to kill it's mother |
16:39.52 | jonpry | the previous pastebin is just misleading |
16:40.32 | jonpry | i will demonstrate. there is also a control channel we are not tracing. but this is a product of the i2c protocol |
16:40.58 | *** join/#htc-linux eR^zeRa` (zzeratul@kaj-0011.koleje.cuni.cz) |
16:41.15 | jonpry | 000001ce -> start a transaction, msm_i2c and everybody on the bus knows it is a write because the low bit is unset |
16:41.26 | jonpry | to device ce >> 1 |
16:41.52 | jonpry | 00000078 -> load 0x78 into the receiving chips address register thingy |
16:41.59 | JC_ | msm_i2c??? |
16:42.30 | jonpry | 000001cf -> start a transaction, although its already started to the same target, but read since low bit is set |
16:42.37 | JC_ | I saw you fix something in i2c with this name in kernel 3.4 |
16:42.49 | jonpry | its the i2c controller driver |
16:43.18 | JC_ | Could be something related??? Because We are still with 3.3 |
16:43.20 | detule | ok when i see something like 000.112 7b00531c: e5863000(str) # b2300000 =000001ce |
16:43.20 | detule | 000.112 7b005330: e5863000(str) # b2300000 =00000076 |
16:43.20 | detule | 000.112 7b005350: e5863000(str) # b2300000 =00000201 |
16:43.23 | jonpry | 00000200 -> begin reading data off of the bus |
16:43.58 | jonpry | thats just a write |
16:44.04 | jonpry | because there is no 1cf |
16:44.12 | detule | yeah there's plenty of those in his pastebin |
16:45.07 | jonpry | yes it is writing 0x1 to register 0x76 on klt |
16:45.21 | detule | my guess is 76 is write then 77 78 79 reads x y z |
16:45.32 | jonpry | maybe that causes it to do a measurement? |
16:45.36 | detule | right |
16:47.14 | jonpry | probably need traces of the startup/shutdown but it seems like this would be the worlds simplest gsensor driver |
16:50.21 | CptAJ | I like simple cause I'm pretty lost here, guys |
16:51.12 | detule | jonpry, any possibility that "do_measurement" is "power_on" |
16:51.22 | detule | er that makes no sense |
16:51.34 | jonpry | it could be |
16:53.07 | detule | damn and their gsensor.dll looks so much like rhod's |
16:53.31 | JC_ | I dont know if this helps but in /sys/bus/i2c/devices/i2c-0/ we have 0-0058 0-0066 y 0-0067 |
16:53.53 | JC_ | And that 0-0067 name is dummy |
16:55.36 | jonpry | btw how is that microp-ksc coming along? |
16:55.48 | detule | it's not bad, just need to write couple of functions in whitestone-led to send those commands to ksc_client and see if anything half-way normal can be read at 77 78 79 |
16:56.09 | *** join/#htc-linux dan1j3l (~danijel@93-136-80-54.adsl.net.t-com.hr) |
16:56.14 | detule | jonpry, coming along? |
16:56.51 | jonpry | i think CptAJ was working on keypad |
16:57.29 | detule | i tried to earn my keep and looked at tls related commits in arch/arm |
16:57.52 | CptAJ | jonpry, I was. Haven't worked on it since though. Been busy with work and school =( |
16:57.53 | detule | i couldn't find anything that would cause this to break.... |
16:58.16 | jonpry | oh i found a bunch |
16:58.21 | CptAJ | just came back into the mix last night, heh. decided to help JC_ since it seemed like he was closer than I was |
16:58.32 | jonpry | just no idea which one in particular it is or what to do about it |
16:59.11 | detule | so is it just bionic binaries that are breaking? |
16:59.35 | jonpry | yeah there are some build flags that will fix it |
17:00.58 | jonpry | we got this now http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081175.html |
17:01.19 | detule | yeah i reverted that to no avail |
17:01.32 | jonpry | o rly |
17:01.38 | detule | though there is a problem with that comit |
17:01.41 | detule | in general |
17:02.08 | jonpry | which is? |
17:03.16 | detule | in setup.c feat_v6_fixup needs to get called before early_trap_init |
17:03.31 | *** join/#htc-linux conantroutman (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com) |
17:03.41 | detule | it used to prior to that commit but don't think it does anymore |
17:03.51 | jonpry | in cp15.h this #define vectors_high()(cr_alignment & CR_V) |
17:04.41 | jonpry | you were actually able to revert that patch? |
17:04.53 | detule | sure i have the korg tree in the same repo |
17:05.47 | jonpry | i did this: http://pastebin.com/UHBi38Ep |
17:06.05 | jonpry | and it shows vectors being at 0xD something or other |
17:06.26 | jonpry | but i wasn't entirely convinced that was a problem since there are all kind of mappings around |
17:08.12 | jonpry | and the other possibility is that they have changed permissions on the vector tables page |
17:09.00 | *** join/#htc-linux mes (~mes@sentry.lazo.ca) |
17:09.11 | detule | i guess vectors_high is the same in 3.3 |
17:11.23 | jonpry | < if (mem_types[i].prot_sect) |
17:11.23 | jonpry | < mem_types[i].prot_sect |= PMD_SECT_AF; |
17:11.23 | jonpry | --- |
17:11.23 | jonpry | > mem_types[i].prot_sect |= PMD_SECT_AF; |
17:15.46 | detule | wait are we defining ARM_LPAE |
17:15.59 | jonpry | i hope not |
17:16.22 | detule | oh ok i see that change in lpae config brackets |
17:19.28 | detule | gotta go do some work bbl |
17:19.30 | *** join/#htc-linux CptAJ (AJ@186.90.180.107) |
17:24.19 | *** join/#htc-linux paulk-desktop (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
17:25.23 | *** join/#htc-linux balans2 (~user@82-170-217-205.ip.telfort.nl) |
17:27.41 | *** join/#htc-linux |Jeroen| (~jeroen@d5153E8CC.access.telenet.be) |
17:51.50 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
18:06.29 | *** join/#htc-linux conantroutman_ (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com) |
18:08.38 | *** join/#htc-linux conantroutman__ (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com) |
18:12.11 | *** join/#htc-linux conantroutman__ (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com) |
18:23.16 | *** join/#htc-linux conantroutman (~conantrou@cpc5-pert4-2-0-cust205.sgyl.cable.virginmedia.com) |
18:31.56 | *** join/#htc-linux dan1j3l (~danijel@93-136-80-54.adsl.net.t-com.hr) |
19:19.36 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
19:54.13 | *** join/#htc-linux walter79 (~walter79@31-17-62-189-dynip.superkabel.de) |
20:08.49 | *** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net) |
21:19.07 | *** join/#htc-linux raymonddull (~raymonddu@c-69-245-114-102.hsd1.mi.comcast.net) |
21:30.56 | *** join/#htc-linux Ondalf (~ondalf@cable-roi-fe98dc00-121.dhcp.inet.fi) |
21:35.02 | *** join/#htc-linux rpierce99_ (~rpierce99@96-42-107-19.dhcp.stcd.mn.charter.com) |
21:54.09 | *** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net) |
22:03.38 | *** join/#htc-linux mastermerlin (~Adium@pD9FE29E5.dip.t-dialin.net) |
22:16.50 | *** join/#htc-linux Sondiodelsol (~Sondiodel@gateway/tor-sasl/sonidodelsol) |
22:22.48 | *** join/#htc-linux mastermerlin (~Adium@pD9FE29E5.dip.t-dialin.net) |
22:52.36 | Sondiodelsol | anyone still got "ubuntu4DHD" files? or a plan to make images |
22:53.13 | *** join/#htc-linux Entropy512 (~quassel@cpe-67-255-37-203.stny.res.rr.com) |
22:55.41 | *** join/#htc-linux mastermerlin (~Adium@pD9FE29E5.dip.t-dialin.net) |
23:03.15 | *** join/#htc-linux mastermerlin (~Adium@pD9FE29E5.dip.t-dialin.net) |