| 00:12.14 | NetRipper | cr2, this is what i have so far.. note the TO_BE_REMOVED define.. which contains testing stuff and things required to compile.. http://www.netripper.com/raphael/msm_ts2.c |
| 00:16.09 | lupine_85 | NetRipper: looks cleaner :) |
| 00:16.17 | lupine_85 | (well, if you ignore the #ifdefs ;) ) |
| 00:16.42 | NetRipper | ;) |
| 00:17.44 | NetRipper | hm |
| 00:17.55 | NetRipper | IRQF_SHARED doesnt work it seems ;) |
| 00:17.57 | NetRipper | couldn't allocate irq |
| 00:19.51 | *** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) |
| 00:23.38 | NetRipper | hm, those max absx and max absy aren't 0-479, 0-639 |
| 00:24.43 | NetRipper | they're more like 132-847, 103-886 |
| 00:25.05 | NetRipper | at least those are the raw values |
| 00:25.06 | NetRipper | i get |
| 00:25.23 | NetRipper | anyway, bedtime.. good night |
| 00:28.29 | lupine_85 | yay, fso-illume-image seems to workish |
| 00:36.12 | lupine_85 | ooh |
| 00:36.17 | lupine_85 | illume is englightenment |
| 00:36.18 | *** part/#htc-linux exco (n=exco@e181105080.adsl.alicedsl.de) |
| 00:44.41 | lupine_85 | hah. sliding out the keyboard made enlightenment crash |
| 00:54.48 | lupine_85 | but so so pretty |
| 01:00.53 | *** join/#htc-linux lifegrasp (n=ckonkel@63.254.171.226) |
| 01:12.31 | lupine_85 | humm, should I set the DPI in X correctly? |
| 01:25.21 | *** part/#htc-linux p3t3r__ (n=peter@134.245.164.105) |
| 01:26.46 | *** join/#htc-linux zycho_ (n=zycho@a89-182-29-133.net-htp.de) |
| 01:28.34 | BHSPitLappy | lupine_85, in some cases it can mess up font rendering otherwise |
| 01:32.07 | lupine_85 | BHSPitLappy: mm, E17 seems to deal with it by having scalingh |
| 01:32.11 | lupine_85 | (so I turned that off :D) |
| 01:32.15 | lupine_85 | it now lokoks mostly OK |
| 01:33.12 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0x12-0x12 0 103 b |
| 01:33.13 | maejrep | <PROTECTED> |
| 01:33.13 | maejrep | 10: 06 |
| 01:33.25 | maejrep | not sure if that's what I should expect ;o |
| 01:35.26 | maejrep | hmm, but my module gets a different value: [ 109.503879] Initialized keyboard: version 06.85.00 |
| 01:35.40 | maejrep | guess the 85 is when reading 2 bytes |
| 01:35.58 | maejrep | (the 0 is just to make sure .. i'm not expecting a 3rd byte) |
| 01:37.58 | *** join/#htc-linux kaze (n=kaze@pac33-1-82-235-251-34.fbx.proxad.net) |
| 01:40.25 | tmzt | maejrep: doesn't that use read command and the chip expects different command? |
| 01:40.31 | tmzt | commands |
| 01:42.06 | maejrep | i2cdump -r 0x12 103 <-- 103 is (0xce >> 1). in this case, it's equivalent to sending to the controller: 0x1ce,0x12,0x1cf, and the 1 byte response we get back is the first byte of that "channel" |
| 01:42.55 | maejrep | I do get "8506" if I request w (word) values |
| 01:43.34 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0x12-0x12 0 103 w |
| 01:43.34 | maejrep | <PROTECTED> |
| 01:43.34 | maejrep | 10: 8506 |
| 01:44.19 | *** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com) |
| 02:27.46 | lupine_85 | w00t to tangogps running on my raph - though gpsd doesn't seem to be working |
| 02:27.59 | lupine_85 | project for tomorrow I think |
| 02:28.27 | maejrep | anyone know what branch hermes is in? |
| 02:33.42 | *** join/#htc-linux Guimli (n=guimli@ecu69-1-82-231-127-213.fbx.proxad.net) |
| 02:36.30 | *** join/#htc-linux kaze (n=kaze@pac33-1-82-235-251-34.fbx.proxad.net) |
| 02:42.32 | maejrep | jesus, i never thought it'd be this difficult to find a driver when I know exactly where it's supposed to be |
| 02:51.23 | *** join/#htc-linux kaze (n=kaze@pac33-1-82-235-251-34.fbx.proxad.net) |
| 02:54.44 | maejrep | finally found it |
| 02:54.59 | maejrep | and I'm pretty surprised by how similar some of the code is :x |
| 03:35.44 | *** join/#htc-linux ALoGeNo (n=alogeno@unaffiliated/alogeno) |
| 03:35.49 | ALoGeNo | hi |
| 03:50.41 | maejrep | hi |
| 04:13.34 | *** join/#htc-linux kaze (n=kaze@pac33-1-82-235-251-34.fbx.proxad.net) |
| 04:21.55 | *** join/#htc-linux the_sys0p (n=the_sys0@cpe-75-85-249-111.bak.res.rr.com) |
| 04:40.36 | maejrep | almost done with the keyboard driver ;x |
| 04:48.11 | parmaster | drivers are the bitch of all of this |
| 05:43.53 | *** join/#htc-linux kaze (n=kaze@pac33-1-82-235-251-34.fbx.proxad.net) |
| 05:51.19 | *** join/#htc-linux goxboxlive (n=goxboxli@mail2.hjellnesconsult.no) |
| 06:03.28 | tmzt | maejrep: cool, it's working? |
| 06:03.40 | maejrep | yes and no |
| 06:03.56 | maejrep | the driver works great now, but having some consistency issues with the data from i2c |
| 06:04.20 | maejrep | if I use i2cdump from command line, I get the data with no problems (afaict) |
| 06:04.45 | maejrep | but the driver is always getting a -EIO error on the ce,10 read |
| 06:05.02 | maejrep | which is, of course, the only important one I'm concerned with :/ |
| 06:05.59 | maejrep | http://www.privatepaste.com/c10MiXduxX |
| 06:09.53 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 06:14.47 | tmzt | you have read function to read from channels? |
| 06:15.05 | tmzt | 0x1ce,0x12,0x1cf |
| 06:15.34 | tmzt | what driver are you looking for? |
| 06:17.02 | maejrep | was looking for kevin2's spi keyboard driver, but I found it |
| 06:17.33 | tmzt | is there a handshaking/signaling thing missing here? |
| 06:19.26 | maejrep | i don't know how.. all the others work just fine |
| 06:19.35 | maejrep | and i2cdump works fine |
| 06:20.06 | maejrep | and I've actually seen this print data from that address, as I hit keys |
| 06:22.14 | tmzt | i2cdump waits until you press a key? |
| 06:22.24 | maejrep | no |
| 06:22.35 | maejrep | but i2c keeps the data buffered |
| 06:22.57 | maejrep | so if I press a key, I can run i2cdump 3 times, and the first time I get the press event, 2nd time I get the release event, and 3rd time I get 00's |
| 06:22.58 | tmzt | it there something that tells you how much data is available? |
| 06:23.07 | maejrep | no, I don't think so |
| 06:23.23 | tmzt | but you always get one byte or two depending on what you request? |
| 06:23.39 | maejrep | in the driver? |
| 06:23.41 | maejrep | or i2cdump? |
| 06:23.56 | tmzt | I mean the protocol |
| 06:24.10 | tmzt | can you dump the actual writes/reads with i2cdump? |
| 06:24.36 | maejrep | i'd have to recompile the kernel and reboot it |
| 06:24.43 | tmzt | Syntax: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]] |
| 06:24.43 | tmzt | <PROTECTED> |
| 06:24.43 | tmzt | <PROTECTED> |
| 06:24.43 | tmzt | <PROTECTED> |
| 06:24.45 | tmzt | <PROTECTED> |
| 06:24.51 | maejrep | i2cdump doesn't show that (its not bus specific) |
| 06:25.08 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0x10-0x11 0 103 w |
| 06:25.09 | maejrep | <PROTECTED> |
| 06:25.09 | maejrep | 10: 0037 4000 |
| 06:25.09 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0x10-0x11 0 103 w |
| 06:25.09 | maejrep | <PROTECTED> |
| 06:25.09 | maejrep | 10: 00b7 0000 |
| 06:25.11 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cdump -y -r 0x10-0x11 0 103 w |
| 06:25.13 | maejrep | <PROTECTED> |
| 06:25.16 | maejrep | 10: 0000 0000 |
| 06:26.38 | tmzt | I mean can you try i2cget? |
| 06:26.52 | tmzt | i2cdump was to dump the chip and figure out what was going on |
| 06:27.00 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 06:27.31 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cget -y 0 0x67 0x10 w |
| 06:27.31 | maejrep | 0x0037 |
| 06:27.31 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cget -y 0 0x67 0x10 w |
| 06:27.31 | maejrep | 0x00b7 |
| 06:27.31 | maejrep | root@htcraphael:/media/mmcblk0p1# ./i2cget -y 0 0x67 0x10 w |
| 06:27.32 | maejrep | 0x0000 |
| 06:27.35 | maejrep | same |
| 06:28.19 | maejrep | I know I'm reading the correct addresses, because maybe 1% will actually work and show the expected values |
| 06:28.35 | maejrep | but it's only the 10 address that's giving me problems |
| 06:29.27 | maejrep | and its caused by an error status in the i2c chip's status register |
| 06:29.46 | tmzt | what else is in there? |
| 06:29.52 | tmzt | the status register |
| 06:30.44 | maejrep | like what? |
| 06:31.09 | maejrep | I don't know exactly what the status register is at the time of error |
| 06:31.17 | tmzt | I mean what bits are set there when |
| 06:31.30 | tmzt | what address is it? |
| 06:31.32 | maejrep | yeah, don't know that |
| 06:31.50 | maejrep | I'm adding a dump_status call to the -EIO line in the code |
| 06:32.05 | maejrep | but even then I don't know that it's going to give me any information |
| 06:32.14 | maejrep | s/any/any useful/ |
| 06:35.50 | tmzt | http://www.nongnu.org/avr-libc/user-manual/group__twi__demo.html |
| 06:37.09 | tmzt | http://embedded.com/story/OEG20010718S0073 |
| 06:41.12 | maejrep | [ 87.452098] STATUS (0x000000c8): NAK FAIL 0xc0 |
| 06:41.13 | tmzt | the first one might be similar to how the microp works |
| 06:41.15 | maejrep | and [ 87.580541] STATUS (0x000063c8): MST ACT NAK FAIL 0xc0 |
| 06:42.10 | tmzt | so these are standard or where did you get those names? |
| 06:42.53 | maejrep | what names? |
| 06:43.00 | maejrep | MST ACT NAK FAIL ? |
| 06:43.06 | maejrep | thats from the i2c-msm bus driver |
| 06:43.27 | maejrep | <PROTECTED> |
| 06:43.27 | maejrep | <PROTECTED> |
| 06:44.05 | maejrep | and that's it, no more information |
| 06:45.22 | *** join/#htc-linux Kuma (n=John@f054218032.adsl.alicedsl.de) |
| 06:45.38 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 06:50.42 | tmzt | so the status register is on the msm chip (the host)? |
| 06:50.50 | maejrep | yes |
| 06:50.50 | tmzt | I mean a status register on the chip itself |
| 06:54.52 | *** join/#htc-linux kiozen (n=oeichler@p5492A1F2.dip0.t-ipconnect.de) |
| 07:05.20 | tmzt | how many bytes does the ce driver read on irq? |
| 07:06.19 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 07:08.33 | maejrep | [ 26.806722] i2c: write: 000001ce |
| 07:08.34 | maejrep | [ 26.811045] STATUS (0x0000a700): MST ACT |
| 07:08.34 | maejrep | [ 26.817271] i2c: write: 00000210 |
| 07:08.34 | maejrep | [ 26.820069] STATUS (0x000000c8): NAK FAIL 0xc0 |
| 07:08.34 | maejrep | [ 26.831961] msm_i2c msm_i2c.0: Error during data xfer (-5) |
| 07:08.34 | maejrep | [ 33.908959] i2c: write: 000001ce |
| 07:08.36 | maejrep | [ 33.911665] STATUS (0x0000a700): MST ACT |
| 07:08.38 | maejrep | [ 33.917890] i2c: write: 00000210 |
| 07:08.40 | maejrep | [ 33.920108] STATUS (0x00000000): |
| 07:08.42 | maejrep | [ 33.946303] i2c: write: 000001cf |
| 07:08.44 | maejrep | makes no sense :( |
| 07:08.54 | maejrep | one odd thing is the "210" |
| 07:09.00 | tmzt | are you using the _read function in your driver now instead of _transfer? |
| 07:09.07 | maejrep | the windows driver doesn't send the 0x200 bit |
| 07:09.12 | maejrep | no |
| 07:09.19 | tmzt | 002.491 7803d940: streq r2, [r5] # b2300000 =00000200 |
| 07:09.25 | tmzt | from your dump |
| 07:09.34 | maejrep | yes, but that's on the read, not the write |
| 07:09.46 | maejrep | 007.137 7803d720: str r3, [r5] # b2300000 =000001ce |
| 07:09.46 | maejrep | 007.137 7803d790: str r3, [r5] # b2300000 =00000010 |
| 07:09.46 | maejrep | 007.137 7803d878: str r3, [r5] # b2300000 =000001cf |
| 07:09.46 | maejrep | 007.137 7803d940: streq r2, [r5] # b2300000 =00000200 |
| 07:09.46 | maejrep | 007.137 7803d944: ldr r3, [r3] # b230000c==00000088 |
| 07:10.45 | tmzt | what does the conditional operation mean? |
| 07:12.24 | maejrep | what conditional operation? |
| 07:12.41 | maejrep | streq? |
| 07:14.16 | maejrep | hmm, with the debugging enabled, its now reading correctly in the module :| |
| 07:14.36 | maejrep | [ 143.960256] <<< 0xce, 0x10 -> b8 00 |
| 07:14.37 | maejrep | [ 143.965322] ::: Scancode = 38; currently pressed: 0 |
| 07:14.37 | maejrep | [ 143.970256] Input keycode = 51 |
| 07:15.06 | tmzt | I was wondering about the speed, started looking at the msm-i2c driver |
| 07:15.41 | *** join/#htc-linux cr2 (n=cr2@ip-90-187-200-87.web.vodafone.de) |
| 07:15.43 | maejrep | seems like if its being slowed down, it works :o |
| 07:17.53 | tmzt | do you have the clock registered with the driver? |
| 07:18.19 | tmzt | i2c_clk |
| 07:18.33 | tmzt | do we have that one in the raph clock driver? |
| 07:20.08 | cr2 | hi |
| 07:20.26 | *** join/#htc-linux pichurri (n=pichurri@users3.ilo.org) |
| 07:20.43 | tmzt | probe would have failed if it couldn't get the i2c_clk, and it looks like i2c clock is in the i2c memory block |
| 07:20.46 | tmzt | cr2: hello |
| 07:20.53 | cr2 | tmzt: i think currently the clk api includes only sd |
| 07:21.12 | cr2 | and only in a hacked way |
| 07:21.13 | kiozen | jesus!, cr that early!? |
| 07:21.31 | tmzt | writel(clk_ctl, dev->base + I2C_CLK_CTL) |
| 07:21.35 | cr2 | kiozen: before going to work :) |
| 07:21.36 | tmzt | I think it's on the a11 |
| 07:22.02 | kiozen | anyway, scary :) |
| 07:22.05 | maejrep | i2c works, so either its working with a gimp clock, or the clock is already setup correctly |
| 07:22.13 | cr2 | tmzt: is it inside the clock api ? |
| 07:22.22 | tmzt | well you appear to be having timing errors |
| 07:22.38 | tmzt | drivers/i2c/busses/i2c-msm.c |
| 07:23.31 | tmzt | clk = clk_get(&pdev->dev, "i2c_clk); |
| 07:23.36 | cr2 | maejrep: still something to think about. it's easy to existing clock api |
| 07:23.42 | tmzt | then dev->clk = clk; |
| 07:24.41 | cr2 | we will need the same for mddi and mdp soon |
| 07:24.46 | tmzt | clk_enable and clk_disable |
| 07:25.10 | tmzt | that's all it appears to do with it, so theres a CKEN on the a9 but it's configued in the i2c block of a11? |
| 07:25.55 | cr2 | kiozen: have you seen my comment on n560 ? |
| 07:26.14 | tmzt | who had the list of clock registers, a0,a4,b0,b4,etc. |
| 07:26.15 | tmzt | ? |
| 07:26.16 | cr2 | tmzt: it's all arm11 for us |
| 07:26.49 | cr2 | i guess they are shared between arm9 and 11 |
| 07:27.10 | tmzt | can we trace clock writes on haret or is this all going to be spl? |
| 07:27.13 | tmzt | s/be/be in/ |
| 07:27.28 | cr2 | we can |
| 07:27.33 | tmzt | is it disabled when keyboard is closed? |
| 07:27.49 | cr2 | but it's already all documented |
| 07:29.13 | cr2 | to operate i2c you need to enable the clock (with the right speed) and setup the alt gpios 3c and 3d (afair) |
| 07:29.16 | maejrep | keyboard is not the only thing on i2c |
| 07:29.57 | cr2 | camera(s),psoc too |
| 07:30.10 | cr2 | what else ? |
| 07:30.21 | maejrep | navi |
| 07:30.41 | cr2 | psoc |
| 07:31.10 | cr2 | accelerometer |
| 07:31.26 | cr2 | is an i2c device too |
| 07:32.53 | cr2 | g1 relies in certain parts on the oemsbl setup too |
| 07:33.04 | cr2 | which is bad |
| 07:34.26 | tmzt | cr2: what is streq? |
| 07:34.46 | tmzt | I mean what does it test |
| 07:35.09 | tmzt | 003.501 7803d940: streq r2, [r5] # b2300000 =00000200 |
| 07:37.25 | swetland_ | it stores IFF the Z flag is set |
| 07:37.50 | tmzt | hey, working on keyboard driver with i2c to an atmel |
| 07:37.55 | tmzt | maejrep is writing it |
| 07:38.32 | tmzt | the clock has to be enabled with the clk api even though it's configured in the i2c block? |
| 07:39.51 | tmzt | 01:56 < creamdog> hmm, https://dl-ssl.google.com/android/eclipse/ seems to be down |
| 07:39.53 | maejrep | cr2: [ 38.042424] <<< 0xce, 0x12 -> 06 85 |
| 07:40.04 | maejrep | is that the kind of response you would expect for the version? |
| 07:40.06 | tmzt | this has been the case for a least a week off and on it appears |
| 07:40.32 | tmzt | sorry, should have been in #android |
| 07:41.08 | maejrep | tmzt: with the debugging output it appears to be working correctly :/ |
| 07:41.25 | maejrep | [ 47.982376] <<< 0xce, 0x10 -> 25 00 |
| 07:41.25 | maejrep | [ 47.987686] ::: Scancode = 25; currently pressed: 1 |
| 07:41.25 | maejrep | [ 47.991033] Input keycode = 47 |
| 07:41.26 | maejrep | [ 48.802468] <<< 0xce, 0x10 -> a5 00 |
| 07:41.26 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 07:41.26 | maejrep | [ 48.810820] ::: Scancode = 25; currently pressed: 0 |
| 07:41.26 | maejrep | [ 48.815642] Input keycode = 47 |
| 07:41.33 | Untouchab1e | Good morning :) |
| 07:41.46 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 07:41.51 | cr2 | tmzt: we need to implement the lowlevel clock api. it's already done (more or less) for SD |
| 07:41.59 | tmzt | swetland: the clock has to be enabled with the clk api even though it's configured in the i2c block? |
| 07:42.44 | cr2 | maejrep: ok, i'll check how to decode the device id response |
| 07:43.33 | cr2 | maejrep: can you create the stub psoc driver too ? and pick the dev id too ? (wiki) |
| 07:43.45 | swetland | tmzt: I believe so |
| 07:43.59 | cr2 | tmzt: clk api is only a software layer |
| 07:45.14 | cr2 | tmzt: somebody needs to write into the lowlevel regs. g1 code does it in both ways: directly and through proc_comm |
| 07:46.17 | swetland | I think the only time we hit the clock block directly is for the gptimer/pwm |
| 07:46.54 | swetland | though that's dead code for EVT devices |
| 07:47.25 | tmzt | EVT? |
| 07:47.37 | tmzt | some manufacturing thing |
| 07:47.48 | tmzt | ? |
| 07:48.18 | tmzt | have tried to follow the openmoko discussions but it didn't come immediately to mind |
| 07:48.33 | cr2 | swetland: you have the pmic voltage setting api, but never use it on g1 ? |
| 07:48.50 | swetland | EVT = engineering verification (first hw dev phase), DVT = design verification (phase 2), PVT = production verification (last phase) |
| 07:48.55 | swetland | sdio driver uses it, no? |
| 07:48.57 | tmzt | cr2: that sleep function you found used on wm, is that something else missing on g1? |
| 07:49.43 | cr2 | tmzt: it's all in the undocumented cpu part |
| 07:49.54 | swetland | there were several hw revs in EVT and DVT, and there is still some code in the tree that deals with those older revisions |
| 07:50.06 | tmzt | the keyboard driver it seems |
| 07:50.23 | tmzt | are all the keymaps at kernel level? |
| 07:51.14 | swetland | well yes and no |
| 07:51.43 | maejrep | tmzt: I was able to login :) |
| 07:51.47 | swetland | there's a kernel keymap in the board file that maps row/col to linux keycode |
| 07:52.01 | cr2 | swetland: the backlight is controlled through an external chip on raphael/diamond anyway. |
| 07:52.19 | swetland | and on dream |
| 07:52.56 | swetland | in earlier revs the bl controller was pwm based. in later revs it's step based (pulsing the control pin steps it through different states) |
| 07:53.38 | swetland | because the pwm based controller needed clock frequencies higher than 32KHz to handle full range, so we couldn't power collapse + tcxo shutdown with the lcd on |
| 07:53.53 | cr2 | ok |
| 07:54.38 | cr2 | going to work now. |
| 07:55.44 | tmzt | maejrep: do you get similar success with udelay's? |
| 07:56.02 | maejrep | I already have mdelay()s in it |
| 07:56.26 | tmzt | are you using i2c_transfer? |
| 07:56.32 | maejrep | yes |
| 07:56.54 | tmzt | it would seem then the only delays that matter are in msm-i2c, if you are doing bulk read/writes |
| 07:58.16 | maejrep | but the error happens during write |
| 07:58.31 | maejrep | which is the first step :| |
| 07:59.07 | maejrep | at least I think its on write |
| 07:59.16 | maejrep | I'll try i2c_master_send and recv |
| 08:00.09 | maejrep | oh right, that's why I wasn't using i2c_master_send/recv: i'd have to switch between ce and cc, and i2c_master_* use the client->addr |
| 08:01.01 | tmzt | why do you need both addresses? |
| 08:01.14 | tmzt | I'm looking at the dump and see both address but I wonder why |
| 08:03.31 | maejrep | cc,50,1 is how you reset the irq |
| 08:03.34 | maejrep | so that's definitely required |
| 08:03.41 | tmzt | ah, right |
| 08:03.42 | maejrep | the others are just setting backlights afaik |
| 08:03.45 | maejrep | anyway |
| 08:04.01 | maejrep | I just split up the i2c_transfer calls into 2 i2c_msg's, and put a 30ms delay between |
| 08:04.04 | tmzt | do you reset the irq immediately after receiving it? |
| 08:04.04 | maejrep | and it works now ;x |
| 08:04.18 | tmzt | without debug? |
| 08:04.34 | maejrep | some debugging, but very minimal |
| 08:05.15 | maejrep | http://www.privatepaste.com/b91HO3sJiX |
| 08:06.08 | maejrep | changed this: r = i2c_transfer(client->adapter, msgs, 2); |
| 08:06.19 | maejrep | into this: r = i2c_transfer(client->adapter, msgs, 1); mdelay(30); r = i2c_transfer(client->adapter, msgs+1, 1); |
| 08:06.24 | tmzt | what I'm asking is why you have to write to 50 multiple times in the isr |
| 08:06.42 | maejrep | just one would suffice i'm sure |
| 08:06.49 | maejrep | I added the other one to see if it would help |
| 08:06.54 | tmzt | what is 50 00 and 50 01 |
| 08:09.33 | maejrep | :D |
| 08:09.51 | tmzt | well, I know you said enabled/disable the interrupt or something |
| 08:09.53 | maejrep | 50,00 turns off notifications (stops the irq essentially, without disabling the irq) |
| 08:10.03 | maejrep | and 50,01 requests notifications |
| 08:10.27 | tmzt | so you send 50 00 at the beginning of your irs and 50 01 at the end? |
| 08:10.33 | tmzt | /s/irs/isr/ |
| 08:10.50 | maejrep | yes, but it doesn't matter -- i've removed the 50,00 and it still works |
| 08:10.53 | tmzt | /\\// |
| 08:11.14 | maejrep | so in its current state, its usable :D |
| 08:11.35 | tmzt | s'\\'/' |
| 08:11.41 | maejrep | hah even CTRL+C works |
| 08:12.49 | tmzt | ok, notifications are turned off by the chip after the first interrupt, which is why you didn't receive subsequent ones before? |
| 08:13.00 | maejrep | right |
| 08:13.17 | maejrep | so the 50,01 just resets the gpio27 line to high |
| 08:13.22 | tmzt | and you have raph800 right, but this will probably work on raph100/500? |
| 08:13.28 | tmzt | and maybe x1 |
| 08:13.52 | tmzt | does the level really change? |
| 08:14.17 | maejrep | the gpio? yes |
| 08:14.33 | maejrep | I was dumping the IN reg, and before it was always low after the first interrupt |
| 08:14.49 | tmzt | and it went hight after 50,01? |
| 08:14.51 | maejrep | now with the 50,1 in there, the IN reg goes high after that |
| 08:15.06 | tmzt | s!hight!high! |
| 08:15.30 | tmzt | ok |
| 08:15.50 | maejrep | as for raph*, yes it should work, except the keymap will need to change |
| 08:15.56 | maejrep | we already know raph110 is different |
| 08:16.08 | tmzt | and you have the version check? |
| 08:16.35 | maejrep | it displays the version currently, doesn't check it yet |
| 08:16.42 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 08:16.48 | maejrep | gonna wait on cr2 to confirm that "6.85" is accurate |
| 08:16.56 | maejrep | or 8506 |
| 08:18.04 | maejrep | i'll do some more cleanup tomorrow and have a patch ready |
| 08:18.08 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 08:18.08 | maejrep | need sleep now |
| 08:18.48 | maejrep | will also need to build it out for things like making shift and ctrl sticky |
| 08:20.19 | tmzt | that should be an input method in the window manager, not kernel I think |
| 08:20.33 | tmzt | I wonder if there is a generic led ioctl for shift as well as caps |
| 08:20.55 | maejrep | well, shift works if you hold it |
| 08:21.13 | maejrep | i guess accessibility controls to enable sticky keys would do fine ;p |
| 08:21.25 | maejrep | http://www.privatepaste.com/91Cvq1Q6lh - current keymap for raph800 |
| 08:21.46 | tmzt | I would like to see something like this for evdev driver in the Xinput2 code |
| 08:22.00 | tmzt | like tslib is moving to, I need a d-pad mouse driver |
| 08:22.26 | tmzt | if this kind of translation can be done in X and made generic |
| 08:23.17 | *** join/#htc-linux _workkaze (n=kaze@ABordeaux-152-1-74-161.w86-196.abo.wanadoo.fr) |
| 08:27.27 | *** join/#htc-linux Othello (i=Othello@gateway/tor/x-2a75a2781f01342d) |
| 08:44.25 | *** join/#htc-linux daspsycho_work (n=TimJorda@213.155.79.202) |
| 08:45.58 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
| 09:06.03 | *** join/#htc-linux apt (i=ibot@rikers.org) |
| 09:06.03 | *** topic/#htc-linux is HTC Linux Channel: Find logs at http://apt.rikers.org/%23htc-linux/ | please check http://handhelds.org/moin/moin.cgi/HTC_2dPhones | http://wiki.xda-developers.com/index.php?pagename=Xanadux | <cr2> let's define a common setup. |
| 09:09.33 | *** join/#htc-linux radem205 (n=aaa@92-108-47-154.dynamic.upc.nl) |
| 09:11.02 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 09:12.44 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 09:31.22 | *** join/#htc-linux Rubberducky (n=Rubberdu@83.101.31.21) |
| 09:31.42 | Rubberducky | hello |
| 09:31.46 | Rubberducky | i've got a questuin |
| 09:31.47 | Rubberducky | anyone here? |
| 09:33.39 | tmzt | yeah, hi again |
| 09:33.57 | Rubberducky | i now found out that packet injection with the acx100 is supported out of the box |
| 09:34.01 | Rubberducky | with kernel version 2.6.24 |
| 09:34.10 | Rubberducky | but the hh one is 2.6.21 |
| 09:34.19 | Rubberducky | how do i get 2.6.24 on my blueangel? |
| 09:34.40 | tmzt | not yet |
| 09:34.44 | tmzt | how is acx driver? |
| 09:34.49 | Rubberducky | doesn't work.. |
| 09:35.03 | Rubberducky | when i patch the HH acx drivers with the patch |
| 09:35.04 | tmzt | you can upgrade your mac80211 from a 2.6.24 MAYBE |
| 09:35.13 | Rubberducky | what? |
| 09:35.22 | NetRipper | maejrep, nice work :) |
| 09:35.48 | Rubberducky | ? |
| 09:35.55 | tmzt | copy net/wireless/mac80211 from 2.6.24 into 2.6.21 but there is no gurantee this will work |
| 09:36.35 | Rubberducky | and why is it so hard to have kernel version 2.6.24 on my BA? |
| 09:36.44 | tmzt | does it have asic3? |
| 09:37.04 | Rubberducky | and if i copied over the header files and the lib files to my phone, can i compile the acx patched ones on my phone? |
| 09:37.07 | Rubberducky | what is asic3? |
| 09:38.00 | *** join/#htc-linux timebomb (n=tb@p5B3E6417.dip.t-dialin.net) |
| 09:38.19 | Rubberducky | ? |
| 09:39.08 | Rubberducky | http://www.handhelds.org/moin/moin.cgi/BlueAngel it says SD-MMC (./) There is no ASIC3 SDIO host support in the kernel |
| 09:39.12 | Rubberducky | is that of any use? |
| 09:40.43 | tmzt | if you want SD card at all |
| 09:41.07 | Rubberducky | no i don't |
| 09:41.10 | tmzt | it means we can't move to a newer kernel until that's fixed, there is a lot of focus on the msm devices right now |
| 09:41.33 | tmzt | then you need to port the board from hh kernel to 2.6.27+ |
| 09:41.44 | Rubberducky | how? |
| 09:41.45 | tmzt | use magician.c in there as a guide |
| 09:42.10 | Rubberducky | where is magician c? |
| 09:42.30 | Rubberducky | what is magician.c |
| 09:42.33 | tmzt | arch/arm/mach-pxa/ |
| 09:42.49 | Rubberducky | i've got no idea what you're talking about.. sorry |
| 09:43.14 | tmzt | I would try copying the wireless stack first or using ieee80211-compat |
| 09:43.23 | tmzt | ok, look in arch/arm/mach-pxa in 2.6.21-hh20 |
| 09:43.28 | Rubberducky | and what is the most simple? |
| 09:43.36 | Rubberducky | trying to get patched drivers on 2.6.21 |
| 09:43.37 | tmzt | you should see a directory called htcblueangel |
| 09:43.45 | Rubberducky | or getting a newer kernel on my phone? |
| 09:47.11 | Rubberducky | ? |
| 09:49.16 | Rubberducky | when i make zImage i get these errors: |
| 09:50.03 | Rubberducky | pastebin.com/m274cdaab |
| 09:51.56 | Rubberducky | fixable? |
| 09:54.10 | Rubberducky | ??? |
| 09:55.10 | *** part/#htc-linux daspsycho_work (n=TimJorda@213.155.79.202) |
| 09:56.59 | Rubberducky | tmzt? |
| 09:59.29 | tmzt | yeah, don't build _MEM and _CS at least |
| 09:59.37 | tmzt | I don't know how you got this driver |
| 10:00.19 | Rubberducky | that is the included driverin the kernel tree |
| 10:00.21 | Rubberducky | in the acx folder |
| 10:00.29 | Rubberducky | i just copied and applied the injection patch |
| 10:00.58 | tmzt | you have more than one version it appears, #acx100 is probably the place to ask about this but there is not often anyone there |
| 10:01.20 | tmzt | also, what patch? it appears to be creating files that were combined before, the mem and cs drivers at least |
| 10:01.45 | Rubberducky | on the aircrack-ng acx100 page |
| 10:02.01 | Rubberducky | can i manually edit the drivers for injection? |
| 10:02.03 | Rubberducky | or is that too hard? |
| 10:02.07 | Rubberducky | or impossible |
| 10:02.08 | tmzt | very hard |
| 10:02.27 | tmzt | acx is a hard problem |
| 10:03.33 | Rubberducky | damn |
| 10:03.40 | Rubberducky | and the problem is the patch then? |
| 10:03.44 | tmzt | the modern acx driver is mac80211, which needs a newer kernel |
| 10:03.49 | tmzt | url? |
| 10:05.21 | Rubberducky | http://www.aircrack-ng.org/doku.php?id=acx |
| 10:05.28 | Rubberducky | i'm folowing the Driver installation thing |
| 10:07.56 | tmzt | are you using both patches in order? |
| 10:10.32 | Rubberducky | http://patches.aircrack-ng.org/acx-20070101.patch |
| 10:10.39 | Rubberducky | only that patch |
| 10:10.47 | Rubberducky | what the 2nd one? |
| 10:10.56 | tmzt | http://acx100.sourceforge.net/wiki/Patch_2.6.22 |
| 10:10.59 | tmzt | in your page |
| 10:11.16 | tmzt | start over with the wget step |
| 10:11.26 | tmzt | don't use uname it won't work for cross-compiling |
| 10:11.33 | lupine_85 | desires maejrep's code :D |
| 10:11.39 | tmzt | apply both patches |
| 10:11.43 | tmzt | in order |
| 10:11.48 | tmzt | lupine_85: tommorow |
| 10:11.55 | lupine_85 | yepyep :) |
| 10:12.10 | tmzt | how is raw ts? |
| 10:12.11 | Rubberducky | i don't make the driver |
| 10:12.15 | Rubberducky | i just patch it |
| 10:12.16 | lupine_85 | you guys all be awesome :D |
| 10:12.38 | Rubberducky | there is only 1 patch.. |
| 10:12.38 | tmzt | and copy it to the tree? |
| 10:12.42 | Rubberducky | yes |
| 10:12.48 | Rubberducky | i patch, copy to the tree |
| 10:12.52 | tmzt | there are two patches, the first is to make the driver work on 2.6.21 |
| 10:12.54 | Rubberducky | and then make make modules |
| 10:12.57 | lupine_85 | raw ts = ts2? NetRipper's still WIPping it I think |
| 10:12.58 | tmzt | read the page you linked |
| 10:12.58 | Rubberducky | and make modules isntall |
| 10:13.21 | tmzt | just ... make modules |
| 10:13.26 | Rubberducky | ok |
| 10:13.29 | lupine_85 | tmzt: angstrom |
| 10:13.35 | lupine_85 | + illume is beautiful |
| 10:13.37 | Rubberducky | so i patch the HH drivers |
| 10:13.40 | Rubberducky | copy to kernel tree |
| 10:13.42 | Rubberducky | make modoles |
| 10:13.44 | Rubberducky | modules |
| 10:13.54 | Rubberducky | so i ever change the zImage file |
| 10:13.59 | Rubberducky | make modules |
| 10:14.01 | tmzt | the keyboard crashing is weird |
| 10:14.21 | Rubberducky | correct? |
| 10:14.40 | tmzt | are you sourcing the Kconfig? |
| 10:14.49 | tmzt | do you see the other patch now? |
| 10:16.56 | Rubberducky | what is sourcing kconifg? |
| 10:17.00 | Rubberducky | yes i found the other patch |
| 10:17.07 | Rubberducky | so first i patch for kernel 2.6.21 |
| 10:17.11 | Rubberducky | and then for injection |
| 10:17.14 | tmzt | in net/wireless/Kconfig you source acx100/Kconfig |
| 10:17.17 | Rubberducky | then copy to kernel tree |
| 10:17.22 | tmzt | right |
| 10:17.26 | Rubberducky | what is 'sourcing' |
| 10:17.36 | tmzt | read the file |
| 10:17.39 | tmzt | you'll see |
| 10:18.07 | Rubberducky | drivers/net? |
| 10:18.09 | tmzt | also, htcblueangel will probably have some init code for the acx driver that won't work with yours, if it's the mem driver |
| 10:18.16 | tmzt | drivers/net/wireless |
| 10:18.24 | Rubberducky | does that mean it won't work? |
| 10:18.34 | tmzt | for now, but get it to compile |
| 10:19.28 | Rubberducky | and i copy to /drivers/net/wireless/acx in kernel treE? |
| 10:19.33 | tmzt | I could be wrong here, it might pick up the pdata/resources |
| 10:19.36 | tmzt | yes |
| 10:19.47 | tmzt | then add source acx/Kconfig to drivers/net/wireless/Kconfig |
| 10:19.51 | tmzt | same as the other lines |
| 10:21.43 | Rubberducky | there is a line source "drivers/net.../acx/Kconfig" |
| 10:21.45 | Rubberducky | is that ok? |
| 10:21.47 | Rubberducky | it's already there |
| 10:21.50 | tmzt | yes |
| 10:22.08 | tmzt | lupine_85: is the SW_ for keyboard slide implemented anywhere? |
| 10:22.46 | tmzt | lupine_85: there should be a driver in drivers/input that can handle it, I would still like to know what broke e17 |
| 10:22.54 | tmzt | lupine_85: could it be vkeyb switch?? |
| 10:23.31 | tmzt | Rubberducky: try building and paste the errors if any again |
| 10:23.38 | Rubberducky | ok |
| 10:23.48 | tmzt | Rubberducky: I will look then I need to go, you can paste other stuff to me later if you want to |
| 10:24.09 | Rubberducky | ok |
| 10:24.13 | Rubberducky | thanks anyway:D |
| 10:25.00 | Rubberducky | make modules_install? |
| 10:25.04 | tmzt | make modules |
| 10:25.11 | Rubberducky | no install? |
| 10:25.14 | tmzt | no |
| 10:25.15 | Rubberducky | and after that? |
| 10:25.19 | Rubberducky | what do i copy where? |
| 10:25.31 | tmzt | nothing, just get the output |
| 10:26.46 | Rubberducky | it worked:-) |
| 10:26.47 | Rubberducky | and now? |
| 10:26.57 | tmzt | make modules_install make zImage copy to device |
| 10:27.13 | tmzt | copy /lib/modules/... to device /lib/modules |
| 10:27.25 | tmzt | except you say you are not using sd, then you make a new initramfs |
| 10:27.34 | Rubberducky | i use sd |
| 10:27.41 | Rubberducky | i don't use sd |
| 10:27.42 | Rubberducky | when |
| 10:27.45 | Rubberducky | my system is booted |
| 10:27.48 | Rubberducky | as an as car |
| 10:27.50 | Rubberducky | d |
| 10:27.55 | Rubberducky | but my phone boot's the OS from sd |
| 10:27.55 | tmzt | or, copy acx_*.ko |
| 10:28.05 | tmzt | what is the last few lines of output anyway? |
| 10:28.25 | Rubberducky | building modules, stage 2 |
| 10:28.30 | Rubberducky | MODPOST 119 modules |
| 10:28.36 | Rubberducky | that's the last one |
| 10:28.37 | tmzt | it did work, great |
| 10:28.44 | tmzt | will be back later |
| 10:28.53 | Rubberducky | and i copy liub modules from my kernel26 dir? |
| 10:29.32 | Rubberducky | damn make zimage gives same error again... |
| 10:30.50 | Rubberducky | i applied both patches |
| 10:31.06 | Rubberducky | make modules worked perfectly |
| 10:31.20 | Rubberducky | make zimage gives the errors again (see pastebin) |
| 10:32.16 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 10:34.24 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 10:35.34 | Untouchab1e | Anyone with a Diamond here? |
| 10:37.02 | Untouchab1e | I just need someone to verify that this: http://connect-utb.com/index.php?option=com_jdownloads&Itemid=58&task=viewcategory&catid=5 Android build works |
| 10:37.29 | Rubberducky | ? |
| 10:38.01 | Untouchab1e | What dont you understad? |
| 10:38.06 | Untouchab1e | understand* |
| 10:38.50 | Rubberducky | :p |
| 10:38.54 | Rubberducky | no touch diamons |
| 10:39.28 | Untouchab1e | If you dont have a Diamond, you cant help me :) |
| 10:46.18 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
| 10:46.30 | kimhoon | i've got a diamond |
| 10:47.10 | Untouchab1e | if you want to test, just let me know if it works :) |
| 10:47.38 | kimhoon | can you sent the link one more time :P |
| 10:48.05 | Untouchab1e | http://connect-utb.com/index.php?option=com_jdownloads&Itemid=58&task=viewcategory&catid=5 |
| 10:48.13 | kimhoon | thanks |
| 11:12.14 | *** join/#htc-linux daspsycho_work (n=TimJorda@213.155.79.202) |
| 11:18.40 | Rubberducky | tzmt? |
| 11:19.53 | Untouchab1e | brb |
| 11:45.35 | lupine_85 | tmzt: dunno what E17 is doing. I shall investigate further tonight, possibly |
| 11:46.07 | lupine_85 | I reckon I've found my mobile DE of choice, so I'd best fix it! :D |
| 11:54.58 | lupine_85 | (mind you, not a huge lot of point looking into it in detail until I get my grubby hands on msm_ts2 and the keyboard driver ;) ) |
| 12:22.12 | *** join/#htc-linux metter (n=metter@243-38.0-85.cust.bluewin.ch) |
| 12:23.52 | *** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net) |
| 12:45.09 | *** join/#htc-linux dcordes (n=zsirc@ip-77-25-15-55.web.vodafone.de) |
| 12:45.53 | dcordes | lupine_85 glad to hear fso-image work well now |
| 12:46.09 | dcordes | cab you make calls? |
| 12:46.19 | dcordes | s/cab/can/ |
| 12:46.42 | lupine_85 | dcordes: dunno |
| 12:46.51 | lupine_85 | I haven't done much with it yet |
| 12:46.51 | dcordes | can you try? |
| 12:47.02 | lupine_85 | don't have a phone app installed AFAIK |
| 12:47.17 | dcordes | fso-image should have one |
| 12:47.19 | lupine_85 | I'm happy to have a go with the AT modem(?) if you're willing to work me through it |
| 12:47.27 | lupine_85 | I'm in fso-illume-image |
| 12:47.32 | dcordes | of course |
| 12:47.39 | lupine_85 | which includes fso-image |
| 12:47.45 | lupine_85 | what would it be called? |
| 12:47.49 | dcordes | did you install frameworkd-devel ? |
| 12:48.01 | dcordes | I don't know |
| 12:49.09 | lupine_85 | It is indeed framework-devel |
| 12:49.17 | dcordes | nice |
| 12:49.28 | *** join/#htc-linux mrincred (n=wmirc_us@68-26-167-83.pools.spcsdns.net) |
| 12:49.38 | dcordes | in /etc/frameworkd.conf set the modem to qualcomm_msm |
| 12:50.00 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 12:51.32 | dcordes | also set loglevel to DEBUG, log to file and set a log_destination = path |
| 12:52.44 | Untouchab1e | Hi dcordes |
| 12:52.46 | Untouchab1e | hows it going? |
| 12:53.13 | dcordes | Untouchab1e good, you? |
| 12:55.52 | lupine_85 | dcordes: OK, done, and frameworkd restarted |
| 12:56.00 | lupine_85 | is doing this on the vkeyb :/ |
| 12:56.13 | dcordes | start it with frameworkd -s ogsmd -d |
| 12:56.29 | dcordes | why not using usb console? |
| 12:56.42 | lupine_85 | I'm at work right now :D |
| 12:56.58 | lupine_85 | lunch break |
| 12:59.21 | lupine_85 | ok, it's runing |
| 12:59.58 | Untouchab1e | All good here, thought I should take care of making running the Android builds you guys release as easy to get and run as possible |
| 13:00.18 | Untouchab1e | so that you guys dont have to worry about all the people who just wants to try Android |
| 13:00.46 | dcordes | sounds like a god idea |
| 13:01.21 | dcordes | lupine_85 check the log |
| 13:02.55 | Untouchab1e | So how is the progress going? any news? |
| 13:04.15 | *** join/#htc-linux FANTASY (n=catwoman@217.118.82.1) |
| 13:04.48 | FANTASY | . |
| 13:05.02 | FANTASY | Хай ол |
| 13:05.16 | lupine_85 | finds the log looong |
| 13:05.27 | Untouchab1e | hah |
| 13:05.42 | lupine_85 | keeps going DEBUG no plugin: factory function not found in module .... |
| 13:06.00 | *** part/#htc-linux FANTASY (n=catwoman@217.118.82.1) |
| 13:06.13 | Untouchab1e | What are you working on? |
| 13:06.56 | lupine_85 | me, right now? Getting Angstrom more functional |
| 13:07.11 | Untouchab1e | cool |
| 13:07.13 | Untouchab1e | any luck? hehe |
| 13:08.07 | lupine_85 | *shrug* |
| 13:08.13 | lupine_85 | I has enlightenment on my phone |
| 13:08.20 | lupine_85 | what more can I ask for? :D |
| 13:09.09 | dcordes | it's niceinnit |
| 13:09.12 | lupine_85 | :) |
| 13:09.22 | lupine_85 | I've never used it on the desktop |
| 13:09.22 | dcordes | you should check the shr-image |
| 13:09.32 | lupine_85 | what's in that? |
| 13:09.36 | dcordes | but they keep the shr metadata sperately |
| 13:09.52 | dcordes | I tried e17 on the beagle |
| 13:10.55 | dcordes | shr.bearstech.com |
| 13:11.25 | dcordes | it's the illume stuff with a lot of patches, a new dialer etc etc |
| 13:12.32 | dcordes | the dialer (openmoko-dialer3) introduces frameworkd-glib though which doesn't have frameworkd-devel support |
| 13:12.57 | Rubberducky | tmzt? |
| 13:13.55 | lupine_85 | ah |
| 13:14.10 | dcordes | lupine_85 idk why you get the debug errr |
| 13:14.34 | dcordes | don't know the framewrkd conf from thetop of my head |
| 13:14.54 | lupine_85 | well, it's missing files, half of them |
| 13:15.21 | dcordes | did it install frameworkd-evel-config ? |
| 13:15.30 | lupine_85 | not sure about tht |
| 13:16.12 | lupine_85 | is being spammed by brightness stuff - .Device.Display doesn't exist |
| 13:16.30 | dcordes | clear skies here too |
| 13:16.31 | lupine_85 | I shall play more when I have an actual computer for using |
| 13:16.50 | dcordes | yea I only have the kais and tethered laptop |
| 13:17.23 | lupine_85 | it'd be fine if I had the keyboard driver ;) |
| 13:17.40 | lupine_85 | (and net of some kind, of course) |
| 13:17.44 | dcordes | maejrep[w] |
| 13:17.54 | lupine_85 | yepyep. tonight the baby gets revealed D: |
| 13:17.56 | lupine_85 | erm, :D |
| 13:18.13 | lupine_85 | returns to writing his calendar application |
| 13:18.19 | dcordes | you're fast with the vkeyb!!1 |
| 13:18.37 | lupine_85 | practice :) |
| 13:33.45 | *** join/#htc-linux ALoGeNoff (n=alogeno@135.Red-81-35-93.dynamicIP.rima-tde.net) |
| 13:45.10 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
| 14:01.34 | *** join/#htc-linux liberostelios (n=liberost@79.107.37.132) |
| 14:01.53 | liberostelios | hi |
| 14:05.04 | radem205 | How is it going with the smd code? |
| 14:07.54 | liberostelios | i guess there's noone here... :P |
| 14:08.06 | liberostelios | i am really interested in helping this project |
| 14:08.36 | liberostelios | and i know a few things about linux and programming. |
| 14:08.37 | dcordes | liberostelios kaiser? |
| 14:08.45 | liberostelios | no, diamond |
| 14:09.10 | liberostelios | my username in xda-developers is stadicon |
| 14:09.16 | dcordes | ok |
| 14:09.25 | liberostelios | but i don't post a lot, anyway :) |
| 14:09.28 | dcordes | you got cdma diam? |
| 14:09.37 | DJWillis | dcordes: do you have the Kaiser pinmux handy? |
| 14:09.54 | radem205 | dcordes: do you know if dzo made progress with the smd code? |
| 14:10.18 | liberostelios | don't know exactly the variation |
| 14:10.23 | liberostelios | it's a vodafone diamond |
| 14:10.33 | liberostelios | but i guess it's just the typical... |
| 14:11.27 | liberostelios | the only "strange" i noticed is that haret doesn't not recognise my phone as "diamond" but as a "generic MSM7xxxA" device |
| 14:33.08 | lupine_85 | liberostelios: UK voda? |
| 14:33.37 | liberostelios | well, i am from greece and i bought it here |
| 14:33.45 | liberostelios | but i guess it's the same with the UK version |
| 14:33.46 | lupine_85 | ah, fair enough |
| 14:33.51 | lupine_85 | (UK is GSM) |
| 14:34.01 | lupine_85 | dunno about greece :D |
| 14:34.19 | liberostelios | GSM here too ;) |
| 14:34.28 | liberostelios | and 3G etc. |
| 14:34.43 | liberostelios | i can give you some information about firmwares etc. if you want... |
| 14:34.46 | lupine_85 | DIAM100 then, I guess? |
| 14:35.05 | liberostelios | yes, should be. |
| 14:35.16 | liberostelios | because i don't get the problem with the messed up colors. |
| 14:35.39 | lupine_85 | has a RAPH100 of awesome |
| 14:36.40 | liberostelios | is there anything i can work with? |
| 14:36.48 | liberostelios | i mean, testing or programing... |
| 14:37.05 | liberostelios | i know a few things about linux and setting up a distro. |
| 14:37.49 | lupine_85 | it's mostly pick something that annoys you, and make it a bit shinier, I think |
| 14:38.02 | lupine_85 | feel free to work on getting the wifi running ;) |
| 14:40.16 | lupine_85 | or pick your distro of choice and find something that doesn't work and make it work |
| 14:40.31 | lupine_85 | will be doing that with angstrom/illume, he thinks |
| 14:41.11 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 14:48.42 | NetRipper | lupine_85, do you have that illume X image somewhere? i'm anxious to see the eye-candy you're talking about |
| 14:48.46 | NetRipper | ;) |
| 14:49.13 | lupine_85 | I can upload it |
| 14:49.41 | NetRipper | if you could? :) |
| 14:50.47 | lupine_85 | fso-illume-image-htcraphael.tar.gz 2% 816KB 164.2KB/s 03:51 ETA |
| 14:51.57 | lupine_85 | it's from home which is all with the ADSL :/ |
| 14:52.04 | dcordes | lupine_85 did you retry frameworkd? |
| 14:52.22 | lupine_85 | nope, I've been writing a calendar application |
| 14:52.23 | lupine_85 | :p |
| 14:53.26 | dcordes | the mokos are planning opimd module for frameworkd |
| 14:56.01 | NetRipper | dcordes, lupine_85, updated git with some patches (http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.25) |
| 14:56.15 | dcordes | cant click |
| 14:56.25 | NetRipper | copy/paste then ;) |
| 14:56.54 | NetRipper | lupine_85, latest zImage (of that git) can be found here: http://www.netripper.com/raphael/zImage-git-20090115-00 if you have some spare time, please test and let me know if it all works accordingly |
| 14:57.15 | NetRipper | (especially your pressure patch) |
| 14:58.02 | *** join/#htc-linux metter (n=metter@243-38.0-85.cust.bluewin.ch) |
| 14:58.38 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 14:59.56 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 14:59.57 | *** join/#htc-linux addman3333 (n=azachars@nat/sun/x-f4f0c229a03dbc36) |
| 15:10.19 | *** join/#htc-linux milfadoodle (n=milfadoo@78-69-144-82-no19.tbcn.telia.com) |
| 15:18.27 | *** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com) |
| 15:20.13 | tmzt | Rubberducky: ping works in the channel too |
| 15:20.15 | *** join/#htc-linux piusvelte (n=chatzill@nat.philau.edu) |
| 15:20.34 | tmzt | Rubberducky: I think you need =M on the .config lines, the driver shouldn't affect zImage at all |
| 15:20.59 | tmzt | Rubberducky: and you have to use modules from the new kernel, make modules_install, then copy them from /lib/modules/... on the pc |
| 15:22.29 | tmzt | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-msm-2.6.25 |
| 15:23.35 | *** join/#htc-linux metter (n=metter@243-38.0-85.cust.bluewin.ch) |
| 15:27.13 | tmzt | lupine_85: I hope to make it work without touchscreen also, I like illume very much |
| 15:27.48 | tmzt | lupine_85: it will probably be this and android for me, depending on how good non-android webkit gets |
| 15:28.04 | tmzt | lupine_85: and some ideas from the palm device which I was already thinking about |
| 15:28.30 | tmzt | lupine_85: it might even be possible to make the pim database compatible with android's for people who want both |
| 15:28.48 | lupine_85 | well, illume isn't ts-dependent |
| 15:28.53 | lupine_85 | not even close |
| 15:29.56 | lupine_85 | you can always get a USB mouse ;) |
| 15:30.07 | lupine_85 | (or bluetooth, I guess) |
| 15:30.08 | tmzt | bluetooth probably |
| 15:30.10 | tmzt | yes |
| 15:30.12 | lupine_85 | :D |
| 15:30.32 | tmzt | I don't have usb host unless the transceiver supports it somehow and no way to power it |
| 15:31.02 | tmzt | how exactly do you open the menu from keyboard? |
| 15:31.03 | lupine_85 | needs to remember to turn the x cursor off |
| 15:31.21 | lupine_85 | dunno. I'm sure it must be keymappable |
| 15:32.06 | tmzt | I have to get framework working first though, and that requires decoding a networking protocol between the applications processor and the baseband processor |
| 15:32.13 | tmzt | over usb |
| 15:38.08 | *** join/#htc-linux MethoS (n=lem@host-091-097-244-151.ewe-ip-backbone.de) |
| 15:38.41 | *** join/#htc-linux slim_ (n=slim1@41.235.155.209) |
| 15:41.49 | tmzt | slim_: hey |
| 15:42.02 | slim_ | hello tmzt |
| 15:42.06 | slim_ | hello all |
| 15:42.58 | tmzt | logs are at irclog.iclem.net, bit slow right now |
| 15:44.01 | slim_ | that's good , i try to read in links that in topic |
| 15:44.38 | tmzt | those are a bit behind, the one I pasted is real-time mostly |
| 15:44.42 | NetRipper | lupine_85, would be nice if we would have multiple pressure levels.. so that you can drag the cursor around and press harder to make a click ;) |
| 15:45.43 | lupine_85 | NetRipper: $someone said that the touchscreen doesn't actually support that |
| 15:46.08 | lupine_85 | apparently the hardware doesn't report pressure at all, we just simulate it |
| 15:46.27 | lupine_85 | (by assuming that if the button is 'down', then there's pressure) |
| 15:46.39 | lupine_85 | I don't know if that's actually true or not though |
| 15:47.11 | lupine_85 | 22:58 < cr2> i think it can't measure pressure |
| 15:47.11 | lupine_85 | 22:58 < cr2> unlike tsc2046 |
| 15:47.11 | lupine_85 | 22:59 < cr2> the ts on raph is not really great. |
| 15:47.18 | slim_ | tmzt: my question was , if i can convert windows mobile into linux mobile, and it seem it work |
| 15:47.57 | tmzt | yeah, there is a program for windows mobile (ce) called HaRET which can boot into a linux kernel and replace ce in ram |
| 15:48.11 | tmzt | then you need a kernel with support for the device and drivers for it |
| 15:49.21 | slim_ | any recommendation for htc model that i can do this modification with it ? |
| 15:49.32 | tmzt | lupine_85: you don't have access to the raw plates? |
| 15:49.54 | tmzt | current devices are msm7x00A |
| 15:50.20 | tmzt | that would include raphael(Touch Pro), diamond, blackstone(HD), xperia x1 |
| 15:50.27 | lupine_85 | tmzt: I don't even know what that means :D |
| 15:50.34 | tmzt | wiki.xda-developers.com |
| 15:50.46 | lupine_85 | also: http://www.lupine.me.uk/fso-illume-image-htcraphael.tar.gz |
| 15:50.50 | lupine_85 | NetRipper: you wanted that? |
| 15:51.03 | tmzt | lupine_85: look at a tsc driver, I'm trying to find a good explaination of resistive touchscreens |
| 15:53.21 | *** part/#htc-linux addman3333 (n=azachars@nat/sun/x-f4f0c229a03dbc36) |
| 15:55.51 | NetRipper | lupine_85, im not sure if cr2 actually checked out the windows touch driver to check for pressure.. but "i think" is relative :) |
| 15:56.08 | NetRipper | lupine_85, thanks :) |
| 15:56.51 | NetRipper | lupine_85 used as initrd or do i mount it? and if initrd, do you have a patched haret.exe that allows loading large images? |
| 15:57.16 | tmzt | oh, cr2 said it doesn't report pressure, for some reason I though he said it was a tsc* chip |
| 15:57.19 | dcordes | NetRipper wiki has |
| 15:57.24 | tmzt | but this is all on the microp/psoc |
| 15:57.31 | tmzt | so we get what they report |
| 15:57.31 | lupine_85 | NetRipper: it's just a rootfs |
| 15:57.54 | lupine_85 | I have a partitioned SD card |
| 15:58.21 | lupine_85 | It's 40-odd MB so, with a 64MB RAM size, I doubt it'd be wise to mount it in RAM |
| 15:58.31 | lupine_85 | if partitioned, it doesn't need an initrd |
| 15:59.08 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 16:00.55 | NetRipper | dcordes, wiki has what? |
| 16:01.28 | NetRipper | lupine_85 ahh ok, that's all i needed to know :) |
| 16:01.30 | dcordes | max initrd size patched haret |
| 16:01.43 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 16:01.47 | NetRipper | dcordes, ah, thanks :) |
| 16:15.23 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 16:16.12 | *** join/#htc-linux MethoS- (n=lem@host-091-096-212-148.ewe-ip-backbone.de) |
| 16:25.42 | maejrep[w] | NetRipper: have you had a chance to trace your scancodes on raph100? |
| 16:32.13 | NetRipper | maejrep[w], can you tell me how? |
| 16:33.00 | NetRipper | if you provide a patch i can just printk every key? |
| 16:33.05 | NetRipper | or is there an easier way |
| 16:33.19 | maejrep[w] | mmutrace 0xb2300000 and 0xb230000c |
| 16:33.32 | maejrep[w] | yeah, the patch would print the scancodes as well |
| 16:33.41 | maejrep[w] | but I don't have it at work right now :x |
| 16:33.46 | NetRipper | ok |
| 16:33.52 | NetRipper | i'll check it out tonight |
| 16:33.57 | NetRipper | (in a few hours) |
| 16:34.29 | maejrep[w] | also i2cdump et al would allow you to see it as well |
| 16:34.41 | NetRipper | let me know if you have a stable patch, im anxious to see it :) |
| 16:34.48 | maejrep[w] | but that needs to be compiled and moved (i can upload my binaries tonight) |
| 16:34.51 | NetRipper | i'll do the haret way |
| 16:34.54 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 16:35.03 | NetRipper | if it's not too confusing ;p |
| 16:35.07 | maejrep[w] | and i2cdump also requires i2c-dev be compiled in |
| 16:35.12 | maejrep[w] | you've seen my i2c traces right? |
| 16:35.17 | NetRipper | no |
| 16:35.47 | maejrep[w] | where it shows something like "b2300000 =000001ce" ".. =00000010" ".. =000001cf" etc |
| 16:36.09 | tmzt | 8817Tbah5Q at privatepaste.com |
| 16:36.20 | maejrep[w] | the line imediately after the "1cf" line, which should be the first "b230000c==000000xx" line, has the scancode |
| 16:36.21 | NetRipper | ok |
| 16:37.11 | maejrep[w] | http://www.privatepaste.com/8817Tbah5Q |
| 16:37.22 | maejrep[w] | so in that example, the scancode is at line 20 |
| 16:37.46 | NetRipper | ok |
| 16:37.49 | maejrep[w] | and the release is 0x80 | <same scancode>, seen at line 67 |
| 16:38.33 | NetRipper | 0x8 for press 0x80 for release |
| 16:38.41 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 16:38.45 | NetRipper | 0x88 i mean |
| 16:38.48 | NetRipper | i see |
| 16:38.53 | maejrep[w] | 0x8 is the scancode. first one is a press, second one is release |
| 16:38.58 | maejrep[w] | the second one is 0x8 | 0x80 |
| 16:39.05 | NetRipper | ok |
| 16:39.13 | NetRipper | 0x80 is the flag for release? |
| 16:39.26 | maejrep[w] | yup |
| 16:39.28 | NetRipper | ok |
| 16:39.34 | maejrep[w] | (same as kevin2's spi driver btw...) |
| 16:39.54 | NetRipper | i'll look at it in a few hours |
| 16:40.02 | NetRipper | i've updated git with some patches btw |
| 16:40.08 | maejrep[w] | which makes me think that we might be able to a) get this to work in spi mode .. i'm pretty sure the chip datasheet says it can be put into spi mode, and b) use his htc-spi-kbd driver |
| 16:40.22 | NetRipper | not yet added CDMA.. will do that soon as well |
| 16:40.35 | tmzt | the datasheet is for the microcontroller, not the firmware? |
| 16:40.51 | tmzt | and this is using the dedictated i2c controller and is multi-slave? |
| 16:41.00 | NetRipper | most important is that msm_proc_comm_wince() is back as a seperate method, instead of intermixing it with the original msm_proc_comm |
| 16:41.19 | NetRipper | i gtg home now, bbl |
| 16:41.42 | maejrep[w] | yeah, cdma needs a different sd slot sense gpio, a different keyboard slider gpio, and a different default sdc id |
| 16:41.50 | maejrep[w] | also needs the rgb444 patch in msm_fb :P |
| 16:41.57 | tmzt | dcordes: do you think that fso image would work on g1 (except X)? |
| 16:41.59 | maejrep[w] | tmzt: could be, I don't know much about that |
| 16:42.17 | cr2 | maejrep[w]: i've looked at the psoc/microp ident part |
| 16:42.46 | *** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net) |
| 16:42.51 | cr2 | maejrep[w]: there are a lot of combinations, as always |
| 16:42.56 | NetRipper | cr2, http://www.netripper.com/raphael/msm_ts2.c that's the driver i made so far.. take note of the TO_BE_REMOVED for an even cleaner implementation, but it's required for debugging and to make it compile |
| 16:43.07 | NetRipper | cr2, if you have any hints on getting the irq to fire, let me know :) |
| 16:43.13 | cr2 | can you read 0x12 & 0x20 blocks from i2c ? |
| 16:43.19 | NetRipper | gtg! |
| 16:43.28 | maejrep[w] | cr2: so 8506 is not constant? |
| 16:43.35 | maejrep[w] | i can't right now cr2, at [w] :p |
| 16:43.46 | cr2 | NetRipper: ok, i have some suggestion whatc to change in your driver |
| 16:44.24 | cr2 | maejrep[w]: i'm also at [w]. you will need such capability for many things |
| 16:44.28 | tmzt | cr2: can we read the raw plates? |
| 16:44.50 | cr2 | maejrep[w]: the raph100 id is completely different algorithm |
| 16:45.05 | cr2 | tmzt: only x/y |
| 16:46.03 | cr2 | maejrep[w]: do you have a link to the proc_comm_wince source ? |
| 16:46.22 | *** join/#htc-linux konsta (n=asds@host81-154-247-76.range81-154.btcentralplus.com) |
| 16:46.34 | *** join/#htc-linux metter (n=metter@243-38.0-85.cust.bluewin.ch) |
| 16:46.54 | cr2 | maejrep[w]: the raph800 voltages, and lcd init is very different. i'll try to write the docs, but then you'll need to write the code |
| 16:48.27 | maejrep[w] | ok |
| 16:49.05 | cr2 | i have split the 100,800 and 500 gpio docs |
| 16:49.27 | cr2 | please add the 800 pins that you know into wiki |
| 16:49.53 | cr2 | dcordes: are you here ? |
| 16:50.17 | maejrep[w] | cool, ok |
| 16:50.21 | *** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net) |
| 16:50.27 | maejrep[w] | I'd already done that for what I know for sure is different |
| 16:50.41 | maejrep[w] | (sd sense, keyboard slider, and sdc3 pins) |
| 16:50.56 | cr2 | ok, but i'll need the alt reg settings too. |
| 16:51.08 | maejrep[w] | how do I get that? :| |
| 16:51.12 | cr2 | i guess you can't fill them. |
| 16:51.28 | cr2 | the alt=3 for irq is not right |
| 16:51.38 | cr2 | so the lower bits can't be for the alt function |
| 16:52.00 | maejrep[w] | that's going over my head :) |
| 16:52.12 | cr2 | maybe swetland will tell us :) |
| 16:52.23 | cr2 | ok, i'll do it myself |
| 16:52.31 | tmzt | 12:32 < NetRipper> most important is that msm_proc_comm_wince() is back as a seperate method, instead of intermixing it with the original msm_proc_comm |
| 16:52.41 | tmzt | not maejrep* |
| 16:52.52 | cr2 | actually we don't need to split the alt reg setting into parts |
| 16:52.57 | tmzt | NetRipper apparently commited that |
| 16:53.14 | cr2 | but it's a nice to have, to be compatible with g1 |
| 16:53.47 | cr2 | maejrep[w]: the proc_comm_wince implementation may be a bit wrong |
| 16:53.48 | maejrep[w] | What do you mean by alt reg setting? |
| 16:54.11 | tmzt | cr2: have you dumped the whole TSSC? |
| 16:54.23 | cr2 | maejrep[w]: gpio config values pull+altfunc+drvstr |
| 16:54.35 | cr2 | tmzt: dumped ? |
| 16:54.38 | maejrep[w] | do we know where that can be found cr2 ? |
| 16:54.43 | maejrep[w] | ie, via dump |
| 16:54.47 | tmzt | and can you explain those, been trying to figure out for a day |
| 16:55.05 | tmzt | I mean with haret, dumped the whole tssc memory range |
| 16:55.35 | cr2 | maejrep[w]: we know the pull+altfunc+drvstr value, but not the single components |
| 16:55.45 | cr2 | maejrep[w]: don't mind, i'll fill the values |
| 16:56.06 | cr2 | tmzt: it's not necessary |
| 16:56.20 | tmzt | I mean for pressure, but we can use 0/1 |
| 16:56.25 | cr2 | tmzt: the driver should be amended to support the tssc init |
| 16:56.40 | *** part/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 16:56.47 | cr2 | tmzt: the rest is some msm irqsetup problem |
| 16:57.07 | tmzt | do you know why the delay is needed in atmelkbd? |
| 16:57.28 | cr2 | tmzt: there is no pressure measuremnt in the wince driver |
| 16:57.28 | tmzt | this is because of the slow microcontroller or a missing clock |
| 16:57.46 | cr2 | tmzt: there are many delays in the wince driver too |
| 16:58.01 | tmzt | mdelay(30)? |
| 16:58.15 | cr2 | the clock is not not missing |
| 16:58.32 | cr2 | but we should add the clock api interface for all known msm clocks |
| 16:58.42 | tmzt | well ok, but is it only set by wm before booting? |
| 16:58.50 | cr2 | tmzt: the delay is a minor problem |
| 16:58.59 | tmzt | sure |
| 16:59.18 | cr2 | no. we can control all the known (documented in the wiki) clocks |
| 16:59.23 | tmzt | we get the real press/releases now, maejrep* said the ctrl+key worked |
| 16:59.26 | tmzt | ? |
| 16:59.38 | tmzt | ckens also? |
| 16:59.40 | cr2 | ctrl ? |
| 16:59.57 | tmzt | control key, ctrl-c, etc. |
| 17:00.17 | cr2 | check the raphaelmemorymap page for MSM_CLK part |
| 17:00.21 | cr2 | ok |
| 17:00.22 | maejrep[w] | yeah the driver works as expected currently |
| 17:00.29 | maejrep[w] | shift, caps, ctrl, etc also |
| 17:00.46 | cr2 | good. |
| 17:00.52 | tmzt | so you get real press/releases, I thought you said you didn't before |
| 17:00.56 | cr2 | time to implement the backlight then |
| 17:01.24 | cr2 | i have not booted linux on raph for a long time |
| 17:01.41 | cr2 | becaouse of many burhing issues. |
| 17:02.12 | cr2 | bbl |
| 17:20.00 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 17:27.29 | maejrep[w] | hmm, delays in the wince driver? |
| 17:27.37 | maejrep[w] | strange that haret doesn't always show that delay |
| 17:29.15 | *** join/#htc-linux Rogro82 (n=rogro82@s5591104d.adsl.wanadoo.nl) |
| 17:30.16 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
| 17:46.33 | *** join/#htc-linux Armand (n=Armand@SantaYnez-11-116.resnet.ucsb.edu) |
| 17:53.44 | *** join/#htc-linux joey_973 (n=IceChat7@ip55-83-208-87.adsl2.static.versatel.nl) |
| 18:01.26 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 18:17.08 | *** join/#htc-linux pichurri (n=pichurri@194.230.146.185) |
| 18:24.59 | *** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net) |
| 18:26.36 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c0e3.pool.einsundeins.de) |
| 18:30.16 | *** join/#htc-linux TrinityAlive (n=TrinityA@218.153.81-79.rev.gaoland.net) |
| 18:31.34 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 18:31.34 | *** join/#htc-linux lpotter (n=ljp@58.173.176.153) |
| 18:38.01 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 18:39.46 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 18:46.58 | dcordes | lupine_85: can you make a tgz of one of your angstrom images which have configured and working raphael TS in X? |
| 18:47.22 | dcordes | alternatively paste ts relevant config/patching |
| 18:48.06 | tmzt | dcordes: I think the ts2 was just pasted, there is a define to disable of code to be removed |
| 18:48.51 | tmzt | http://www.netripper.com/raphael/msm_ts2.c |
| 18:49.05 | tmzt | this should work with tslib with the old instructions |
| 18:50.14 | dcordes | i.e. angstrom works ootb with that ts? |
| 18:50.21 | NetRipper | no no no |
| 18:50.28 | NetRipper | it's test code |
| 18:50.31 | dcordes | s/angstrom/tslib/ |
| 18:50.44 | NetRipper | and the tslib (pressure) patch has been committed in git now |
| 18:51.09 | dcordes | so git ts just works ootb tslib? |
| 18:51.23 | NetRipper | it should yes |
| 18:51.29 | NetRipper | untested for now |
| 18:51.34 | NetRipper | http://www.netripper.com/raphael/zImage-git-20090115-00 |
| 18:51.36 | NetRipper | is the binary |
| 18:52.11 | dcordes | ain't got no raph |
| 18:53.53 | tmzt | dcordes: yeah, what are you looking for then (and I should think sometimes) |
| 18:54.38 | *** join/#htc-linux famast (n=amast@host-208-68-238-61.biznesshosting.net) |
| 18:55.58 | *** join/#htc-linux mmarker (n=crichton@m3a5a36d0.tmodns.net) |
| 18:56.41 | dcordes | tmzt: lost track about the raphael ts sitatuion. was wondering if we have a solution that works with tslib |
| 18:57.28 | tmzt | dcordes: what we fixed where the driver flags like before, tslib works |
| 18:57.55 | tmzt | dcordes: on kaiser, you should be able to use the android ts or raw tsc2007? with tslib |
| 18:58.32 | tmzt | NetRipper: by testing you mean the driver not tslib right? |
| 18:59.39 | NetRipper | yes |
| 18:59.40 | NetRipper | the driver |
| 18:59.56 | tmzt | who had a function driver for rndis/usbnet? |
| 19:00.03 | tmzt | maejrep[w]? |
| 19:00.06 | NetRipper | git does |
| 19:00.11 | NetRipper | android |
| 19:00.17 | tmzt | ltg? |
| 19:00.22 | NetRipper | ltg? |
| 19:00.27 | tmzt | linuxtogo.org |
| 19:00.28 | dcordes | linuxtogo |
| 19:00.28 | NetRipper | ja |
| 19:00.29 | NetRipper | yes |
| 19:00.31 | NetRipper | i meant |
| 19:00.38 | tmzt | which branch? |
| 19:00.43 | NetRipper | any |
| 19:00.45 | NetRipper | well |
| 19:00.47 | NetRipper | sec |
| 19:00.54 | NetRipper | raph one |
| 19:01.01 | tmzt | htc-msm? |
| 19:01.04 | NetRipper | yes |
| 19:01.07 | NetRipper | htc-msm-2.6.25 |
| 19:01.14 | NetRipper | git.android.com will have it too |
| 19:01.18 | NetRipper | maybe its more up to date |
| 19:01.34 | tmzt | it will? |
| 19:01.48 | tmzt | I thought someone here fixed it |
| 19:01.54 | NetRipper | http://android.git.kernel.org/?p=kernel/msm.git;a=tree;f=drivers/usb/function;h=24bfc0a4d349e860db6e5ddf3d16890f7d90e12b;hb=HEAD |
| 19:01.58 | NetRipper | oh |
| 19:02.00 | NetRipper | yes |
| 19:02.07 | NetRipper | but it was just given different id's |
| 19:02.19 | NetRipper | i'll find the commit |
| 19:04.21 | dcordes | DJWillis: ping |
| 19:04.33 | tmzt | ltg's down? |
| 19:05.56 | NetRipper | it seems to |
| 19:10.30 | *** join/#htc-linux cworth (n=cworth@olra.theworths.org) |
| 19:13.54 | NetRipper | cr2, tell me your suggestions :) |
| 19:15.39 | *** join/#htc-linux exco (n=exco@e181093134.adsl.alicedsl.de) |
| 19:16.53 | tmzt | cworth: hey, logs at irclog.iclem.net |
| 19:20.47 | *** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring) |
| 19:21.31 | AstainZZZZZZ | hello |
| 19:21.43 | tmzt | hi |
| 19:21.55 | tmzt | you have raph right? |
| 19:22.20 | AstainHellbring | yes |
| 19:22.25 | AstainHellbring | raph100 and raph800 |
| 19:23.27 | tmzt | maejrep[w] has a working keyboard driver tested on 800, source is coming |
| 19:23.50 | tmzt | should work on 100 but needs to check the version information |
| 19:23.57 | AstainHellbring | nice! |
| 19:24.17 | tmzt | coming as in when cleaned up |
| 19:25.16 | AstainHellbring | thats awesome news |
| 19:26.42 | maejrep[w] | the driver should work, but what's going to be different is keymap |
| 19:27.06 | AstainHellbring | why different maejrep? |
| 19:27.22 | maejrep[w] | AstainHellbring: if you have time to go through collecting scancodes in haret, and updating the wiki, that'll make it easier to make the different keymaps |
| 19:27.33 | maejrep[w] | AstainHellbring: because the devices' keyboards are laid out differently? ;) |
| 19:27.56 | AstainHellbring | nope same layout |
| 19:28.11 | tmzt | how do you dump the version information? |
| 19:28.21 | tmzt | fuze is the one that's different |
| 19:28.35 | maejrep[w] | are you sure the layout is the same? |
| 19:28.38 | AstainHellbring | yah fuze is diff fuze is raph110 |
| 19:28.39 | maejrep[w] | I thought raph800 was different |
| 19:28.47 | maejrep[w] | does raph100 have the numbers on top row? |
| 19:29.00 | maejrep[w] | tmzt: with i2cdump |
| 19:29.14 | AstainHellbring | maejrep yes 100 has numbers on top row |
| 19:29.48 | tmzt | maejrep[w]: do we have keymap for fuze? |
| 19:30.07 | AstainHellbring | maejrep its practically the same keyboard from 100 to 800 |
| 19:30.27 | AstainHellbring | the FN commands on it are even the same |
| 19:31.03 | maejrep[w] | tmzt: yeah its already on the wiki |
| 19:31.09 | maejrep[w] | AstainHellbring: ah ok |
| 19:31.23 | maejrep[w] | anyone know if 500 is different then? |
| 19:31.55 | AstainHellbring | yes 500 is VERY different |
| 19:32.12 | AstainHellbring | nasty bastardized machine |
| 19:32.13 | tmzt | could even be matrix? |
| 19:33.31 | tmzt | was it tekk or parmaster who has one? |
| 19:34.03 | maejrep[w] | AstainHellbring: if you want to spot check a few keys though and have time, you can do: addlist mmutrace 0xb2300000 and addlist mmutrace 0xb230000c, ibit the irqs you don't want, then wirq and press a key |
| 19:34.12 | *** join/#htc-linux cr2 (n=cr2@ip-77-24-47-184.web.vodafone.de) |
| 19:34.15 | maejrep[w] | will look like: http://www.privatepaste.com/8817Tbah5Q |
| 19:35.00 | maejrep[w] | lines 20 and 67 have the scancodes (67 shows it masked with the key-release bit of 0x80, but line 20 is the actual scancode) |
| 19:36.34 | AstainHellbring | ok I can do that |
| 19:38.26 | NetRipper | maejrep[w], i added keymap for raph100 to wiki |
| 19:38.57 | NetRipper | do you also need to know the fn variant of a key? |
| 19:39.27 | NetRipper | could add it with like (..) behind it |
| 19:40.05 | AstainHellbring | if we need someone to do the raph500 I got a guy that can |
| 19:40.28 | *** join/#htc-linux NexVision (n=nunya@97.66.39.252) |
| 19:41.01 | NetRipper | well |
| 19:41.08 | NetRipper | i just mmutrace 0xb230000c |
| 19:41.13 | NetRipper | not the other address |
| 19:41.21 | NetRipper | then i do wirq 5 seconds |
| 19:41.26 | NetRipper | when i press a key |
| 19:41.34 | NetRipper | the first line has the keypress |
| 19:41.40 | NetRipper | the scancode |
| 19:41.52 | NetRipper | then i restart wirq 5 for the next key ;) |
| 19:46.26 | AstainHellbring | maejrep[w] based on that do you still need me to do scancodes? |
| 19:47.02 | NexVision | 6850 just came in |
| 19:47.39 | NexVision | gotta do receiving then i can test or play with whatever u need |
| 19:48.13 | AstainHellbring | points at NexVision he the guy with raph500... |
| 19:48.31 | StarLite | hows android on the raph series doing? |
| 19:48.53 | StarLite | keyboard working I read |
| 19:48.54 | StarLite | ? |
| 19:50.24 | tmzt | which raph? |
| 19:54.38 | pichurri | j0b0, hey, you there? |
| 19:58.31 | AstainHellbring | maejrep you built a zImage with the keyboard driver? |
| 20:00.48 | NetRipper | AstainHellbring, on wiki the raph100, 110 and 800 layouts are there.. raph500 still missing.. so i think it's still needed |
| 20:00.51 | NetRipper | :) |
| 20:01.21 | StarLite | which is the X1? |
| 20:01.32 | AstainHellbring | NetRipper can you walk NexVision through how to do the raph500 layout? |
| 20:01.45 | tmzt | xperia, sony |
| 20:02.11 | NetRipper | AstainHellbring, sure |
| 20:02.12 | StarLite | yeh, I know :P |
| 20:02.13 | NetRipper | NexVision, you here? |
| 20:02.21 | StarLite | but which raph model is that? |
| 20:02.29 | AstainHellbring | StarLite x1 is not a raph |
| 20:02.30 | tmzt | it's not |
| 20:02.39 | StarLite | aha |
| 20:02.41 | StarLite | ok :) |
| 20:02.54 | tmzt | but it should be similar keyboard controller which is what I'm hoping to find with a haret trace |
| 20:02.54 | j0b0 | hi pichurri yes i am |
| 20:03.10 | StarLite | what with all the diff raph layouts then? diff country layouts? |
| 20:03.24 | StarLite | or provider versions? |
| 20:03.29 | NetRipper | StarLite, its per operator |
| 20:03.39 | NetRipper | some providers think some layouts are more handy |
| 20:03.43 | StarLite | so branded versions then :) |
| 20:04.09 | AstainHellbring | StarLite the models are gsm raph(100) att gsm raph(fuze 110) US verizon CDMA raph(500) and US CDMA raph(800) |
| 20:04.40 | pichurri | j0b0, how are you? :) |
| 20:05.22 | j0b0 | fine tyvm. just playing around. yourself? |
| 20:05.45 | pichurri | j0b0, :), good, thanx! so, I was playing with the writel on the htc_fb_console, and it changes stuff, any ideas on the data being pushed? |
| 20:06.24 | pichurri | j0b0, also I saw the code from 2.6.27 and it changes a bit, specially on how the memory addresses are feed to the function... |
| 20:08.48 | pichurri | j0b0, by the way, android 1.0 works on blackstone, as I think tmzt said from looking at the spl, mmc drivers worked! |
| 20:08.50 | pichurri | :) |
| 20:09.03 | j0b0 | i think the code in htc_fb_console was borrowed from msm_fb or mddi |
| 20:09.32 | NetRipper | htc_fb_console is the very minimum, without any initialization, to get a console.. |
| 20:09.56 | NetRipper | druidu made that.. he basically only took the mda update function from mddi |
| 20:09.56 | pichurri | j0b0, true, thats where it changed on 2.6.27...have you seen druidu? tried to send him an email but it bounced... |
| 20:10.15 | NetRipper | druidu is busy on exams i last heard |
| 20:10.23 | NetRipper | he'll be back in a month or so probably |
| 20:10.37 | pichurri | NetRipper, the output is the same to the fb_msm output |
| 20:10.58 | pichurri | NetRipper, and as it is simpler, I'm working on that |
| 20:10.59 | NetRipper | pichurri, the htc_fb_console is also corrupted? |
| 20:11.07 | NetRipper | right |
| 20:11.10 | pichurri | NetRipper, yep, in exactly the same way |
| 20:11.14 | NetRipper | ok |
| 20:11.55 | pichurri | NetRipper, but, when I change the screen resolution and physical fb address the output changes completely...which makes me wonder why |
| 20:11.59 | pichurri | :p |
| 20:12.34 | NetRipper | you can get the correct physical address using haret |
| 20:13.13 | *** join/#htc-linux Zinbolic (n=Zy@84.238.80.215) |
| 20:13.33 | j0b0 | pichurri if you get results by modifying htc_console you probably want to move that over to mdp_dma_to_mddi |
| 20:14.11 | pichurri | that is the idea |
| 20:14.42 | *** join/#htc-linux Mullins (n=bw@89.204.227.183) |
| 20:14.46 | NetRipper | they first have to be _good_ results |
| 20:14.46 | NetRipper | ;) |
| 20:15.09 | j0b0 | yes. good point. not just any old result |
| 20:15.26 | NetRipper | it's odd though |
| 20:15.39 | NetRipper | haret is telling me a different physical address then used in htc_fb_console |
| 20:15.46 | *** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 20:15.49 | pichurri | really? |
| 20:15.52 | pichurri | which? |
| 20:16.27 | pichurri | NetRipper, also, there is an offset which I still don't understand... |
| 20:16.37 | NetRipper | htc_fb_console says base 0x16800000 + offset 0x0006a000 (=0x1686a000), haret tells me 0x1666a000 |
| 20:17.07 | pichurri | NetRipper, do you know why there is an offset? |
| 20:18.20 | NetRipper | it's probably because you cannot map more specific addresses |
| 20:22.14 | NetRipper | you can check what haret tells you, using this command: print %08x VRAM |
| 20:22.22 | NetRipper | then use that as physical |
| 20:22.32 | NetRipper | or well, apply the same principle of base + offset |
| 20:25.06 | NetRipper | pichurri, do you have a picture of the screen? |
| 20:25.25 | NetRipper | is the screwed up text going from top left to lower right, or top right to lower left? |
| 20:25.38 | pichurri | http://www.gavero.com/pichurri/blackstone/images/corrupted_output_2008-12-28_1_small.jpg |
| 20:26.01 | NetRipper | hm that's hard to see |
| 20:26.02 | NetRipper | lol |
| 20:26.07 | pichurri | NetRipper, hahaha |
| 20:26.19 | NetRipper | oh you got the blackstone |
| 20:26.21 | pichurri | NetRipper, its half moved to the right I think |
| 20:26.25 | pichurri | yeah |
| 20:26.38 | pichurri | there are two panels? |
| 20:26.47 | NetRipper | what happens if you dont correct resolution at all? |
| 20:27.03 | NetRipper | i.e. keep it 480x640 isntead of 480x800 |
| 20:27.38 | NetRipper | hm it does look like it's too crowded though |
| 20:28.39 | NetRipper | perhaps the screen has 24bpp or 32bpp |
| 20:28.40 | maejrep[w] | <NetRipper> do you also need to know the fn variant of a key? <-- no its the same |
| 20:28.40 | maejrep[w] | <NetRipper> do you also need to know the fn variant of a key? |
| 20:28.48 | maejrep[w] | er, sorry for the double paste |
| 20:29.04 | maejrep[w] | my assumption is the Fn key will act more like L_META or so |
| 20:29.13 | NetRipper | maejrep[w], you mean like.. the ! is always on top of the 1? |
| 20:29.18 | pichurri | NetRipper, http://www.gavero.com/pichurri/blackstone/images/corrupted_output_2008-12-28_1.jpg has more resolution... |
| 20:29.20 | maejrep[w] | so it will be controlled by Xkb config, etc |
| 20:29.30 | NetRipper | maejrep[w], ah ok |
| 20:29.43 | NetRipper | maejrep[w], you dont actually process fn's in your driver |
| 20:29.53 | NetRipper | you just tell linux that the fn was pressed |
| 20:29.53 | maejrep[w] | NetRipper: i mean, Fn is one scancode. '1' is another scancode. But Fn,1 is just the combination of the two key presses |
| 20:29.58 | maejrep[w] | right |
| 20:30.01 | NetRipper | alright |
| 20:30.03 | NetRipper | got it |
| 20:30.03 | maejrep[w] | I'm 90% sure :x |
| 20:30.15 | maejrep[w] | I don't recall if I tested holding Fn+another key |
| 20:30.15 | NetRipper | you better be! arrr |
| 20:30.15 | NetRipper | ;) |
| 20:30.19 | maejrep[w] | ;D |
| 20:30.49 | maejrep[w] | if you did, and you noticed a different scancode, that would be something else I have to look into, but if anything it might just modify the other ce,10 byte, or the ce,11 bytes |
| 20:31.19 | NetRipper | ok |
| 20:32.04 | NetRipper | colors are also screwed |
| 20:33.01 | NexVision | OK INVENTORY ALL RECEIVED |
| 20:33.05 | NexVision | sorry bout caps |
| 20:33.14 | NexVision | who needed me to do what on vzw raph |
| 20:33.14 | NetRipper | inventory? |
| 20:33.18 | NetRipper | ah |
| 20:33.27 | NetRipper | NexVision, fire up haret and connect to it ;) |
| 20:33.36 | NexVision | got a link |
| 20:33.42 | NexVision | been along time sine i messed with it |
| 20:33.45 | NexVision | been using g1 |
| 20:33.49 | NetRipper | emm, sec |
| 20:34.29 | NetRipper | www.netripper.nl/raphael/haret.exe |
| 20:34.38 | NetRipper | start it on the raph |
| 20:35.02 | NetRipper | listen for connections, then connect to it (port 9999) |
| 20:36.04 | NexVision | doing setup now |
| 20:36.10 | NetRipper | ok |
| 20:36.41 | maejrep[w] | NetRipper: are you serious? :| raph100 is really off by one on some of those? |
| 20:36.45 | maejrep[w] | that's a pita :P |
| 20:36.51 | NetRipper | maejrep[w], yes, lol |
| 20:36.54 | NetRipper | it's unfortunate |
| 20:37.01 | maejrep[w] | :( |
| 20:37.11 | NetRipper | i lol'ed too when i saw it |
| 20:37.24 | maejrep[w] | wow |
| 20:38.10 | *** join/#htc-linux orux (n=jose@89.130.46.3) |
| 20:38.30 | maejrep[w] | that's gonna be a c.f. in teh code :P |
| 20:39.07 | NetRipper | why? just make a table for each model ;) |
| 20:39.27 | NetRipper | though |
| 20:39.28 | maejrep[w] | right, but we only have mach types for RAPH and RAPH_CDMA :p |
| 20:39.32 | NetRipper | we have no way to detect 110 yet |
| 20:39.37 | NetRipper | nor 500 |
| 20:39.37 | maejrep[w] | kind of |
| 20:39.41 | NetRipper | we do? |
| 20:39.47 | maejrep[w] | 110 is very different in terms of hardware isn't it? as in like memory size |
| 20:39.51 | maejrep[w] | or is that raph500? |
| 20:39.59 | NetRipper | might be 110 yes |
| 20:40.05 | NetRipper | i recall something similar |
| 20:40.16 | maejrep[w] | we need a better way to determine actual model at runtime |
| 20:40.28 | cr2 | wtf is raph110 ? |
| 20:40.29 | maejrep[w] | smem has the model number doesn't it? |
| 20:40.32 | NetRipper | cr2, fuze |
| 20:40.33 | maejrep[w] | cr2: at&t fuze |
| 20:40.51 | NetRipper | cr2, dont tell me you thought it was a typo all this time |
| 20:40.52 | NetRipper | ;) |
| 20:41.10 | maejrep[w] | problem is raph500 is cdma also, but not very similar to raph800 |
| 20:41.17 | AstainHellbring | 500 is diff in mem sizes but 110 is same as 100 |
| 20:41.21 | maejrep[w] | and raph110 is gsm but very different from raph100 |
| 20:41.23 | cr2 | maejrep[w]: you have implemented the vreg_level function ? |
| 20:41.27 | NetRipper | AstainHellbring, ah |
| 20:41.29 | maejrep[w] | I don't think so? |
| 20:41.49 | NetRipper | cr2, you said you had hints for the msm_ts driver |
| 20:41.51 | maejrep[w] | we need a trac system setup to assign tickets ;) |
| 20:41.54 | pichurri | j0b0, have you tried changing colors on htc_fb_console? |
| 20:42.07 | cr2 | maejrep[w]: *data1 and *data2 look strange |
| 20:42.40 | cr2 | maejrep[w]: from what i can see in wince, it's more *in and *ot |
| 20:42.41 | maejrep[w] | cr2: I followed vogue mostly |
| 20:42.45 | pichurri | j0b0, its easier...and could be helpful for testing with raph800... |
| 20:42.48 | cr2 | yes, i know |
| 20:43.04 | maejrep[w] | smem shows "?" next to DATA2 and DATA_RESULT2 |
| 20:43.09 | maejrep[w] | on the wiki that is |
| 20:43.13 | maejrep[w] | so it may not be correct |
| 20:43.16 | cr2 | but on a 2 parameter call like vreg_level it's very important |
| 20:43.29 | j0b0 | pichurri i changed the color packing settings in msm_fb |
| 20:43.34 | cr2 | afaik vogue implements only void and 1 param calls |
| 20:43.36 | maejrep[w] | so how would we do 2 parameters if it's not DATA1 and DATA2? |
| 20:43.52 | cr2 | wince api is different |
| 20:43.57 | j0b0 | that works for the internal functions |
| 20:44.01 | j0b0 | that draw and blit |
| 20:44.03 | cr2 | and you just have reused the g1 api |
| 20:44.04 | maejrep[w] | I've only seen proc comm chatter for 1 param calls |
| 20:44.05 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 20:44.06 | j0b0 | but not for android |
| 20:44.17 | j0b0 | also, that is the wrong way round i'm afraid |
| 20:44.21 | maejrep[w] | and it uses the "DATA1" and "DATA_RESULT1" registers, haven't seen anything touch DATA2 or RESULT2 |
| 20:44.35 | maejrep[w] | so I'm not sure that it's correct myself |
| 20:44.36 | NexVision | ran it and told it to listen for network and its just spinning\ |
| 20:44.38 | NetRipper | j0b0, do you know how to change 16bpp to i.e. 24bpp? |
| 20:44.39 | cr2 | maejrep[w]: i'm pretty sure that you had 0x1a in your logs |
| 20:44.57 | NetRipper | NexVision, yes, you have to telnet to it, port 9999 |
| 20:45.03 | cr2 | maejrep[w]: it's something to ask dzo |
| 20:45.03 | j0b0 | i tries to draw 444 in the fb so that it show up correct, but it should make the 565 show up properly |
| 20:45.04 | maejrep[w] | cr2: for sd maybe? |
| 20:45.12 | pichurri | NetRipper, there is code for that on fbgrab.c |
| 20:45.16 | maejrep[w] | no, that was 0x15 and 16 |
| 20:45.30 | maejrep[w] | I don't think I saw 0x1a, but I can check my haret logs when I get home |
| 20:45.31 | j0b0 | you can influence the format to which the frame buffer gets dma's |
| 20:45.36 | j0b0 | with the flags in mdp |
| 20:45.49 | maejrep[w] | oh, maybe I saw 1a on initializing camera |
| 20:45.57 | maejrep[w] | shrugs |
| 20:45.57 | cr2 | maejrep[w]: i have not tracked the wince implementation up to the end, but from the api point of view it makes more sense |
| 20:46.09 | cr2 | yes, probably |
| 20:46.14 | maejrep[w] | more sense for what? one input, one output? |
| 20:46.20 | cr2 | yes |
| 20:46.21 | maejrep[w] | instead of 2 inputs which get modified for 2 outputs? |
| 20:46.51 | cr2 | and the 0x100|0x15 means (0x1) the number of parameters |
| 20:46.54 | maejrep[w] | ^ that's how g1 does it, so you may be right, i might have messed up by letting trout code influence it |
| 20:47.03 | NetRipper | j0b0, yes, but before that, the driver sets up the framebuffer in a specific way... maybe that layout is wrong already.. it sets it up as 16bpp.. maybe the panel wants 24bpp |
| 20:47.13 | maejrep[w] | ah, not just "has data"? |
| 20:47.22 | j0b0 | pichurri did you test the effects of MSB vs. LSB alignment, tight vs. loose packing, |
| 20:47.37 | maejrep[w] | I saw it happened when there was data, but again never saw it with 2 data params, so don't know what that looks like |
| 20:47.54 | j0b0 | NetRipper is that the mdp init code you mean? |
| 20:47.57 | cr2 | maejrep[w]: i will write down the structs used by void, 1par and 2par calls |
| 20:48.03 | maejrep[w] | cool |
| 20:48.04 | pichurri | j0b0, nop...thats dma2_cfg? |
| 20:48.09 | maejrep[w] | you're going off oem_misc.dll ? |
| 20:48.22 | cr2 | maejrep[w]: not only. |
| 20:48.26 | maejrep[w] | ah k |
| 20:48.27 | pichurri | j0b0, I've commented all the dma2_cfg, it changes nothing... |
| 20:48.37 | cr2 | maejrep[w]: the same api is reimplemented inside the wince kernel |
| 20:48.42 | j0b0 | i found that playing with those flags gives weirdness |
| 20:48.43 | maejrep[w] | ah |
| 20:48.51 | maejrep[w] | that's odd, and yet not at all surprising :P |
| 20:48.55 | NetRipper | j0b0, no, in the console_update() |
| 20:48.57 | cr2 | which has more weird calls, marked ? in wiki |
| 20:49.01 | maejrep[w] | lol |
| 20:49.04 | pichurri | j0b0, ok, testing |
| 20:49.35 | j0b0 | :) thats basically the same as in mdp_dma_to_mddi |
| 20:49.42 | cr2 | maejrep[w]: the input struct looks like |
| 20:49.44 | maejrep[w] | cr2: while you're here, 1) the restart_reason is different from trout, right? trout uses 776655aa i think. i saw you mentioned what it should be for us, but I don't know where that is now .. do you remember? |
| 20:49.46 | j0b0 | yes, i played with those, but not there |
| 20:50.19 | orux | hello pichurri, |
| 20:50.28 | maejrep[w] | and 2) which cmd is for soft-reset? Is that 0x22 "reset arm9" or 0x8e "notify arm9 reboot" ? |
| 20:50.37 | *** join/#htc-linux timebomb (n=tb@e176099190.adsl.alicedsl.de) |
| 20:50.38 | cr2 | struct { int8_t cmd; int8_t npar; int16_t dummy; int32_t par1; ... |
| 20:50.43 | NetRipper | maejrep[w], neither.. i tried btoh ;) |
| 20:50.49 | maejrep[w] | :X |
| 20:51.00 | maejrep[w] | NetRipper: one of them might work with the correct restart_reason |
| 20:51.02 | j0b0 | in mpd_init, it pushes the 'mdp_csc_table', which is some kind of init code i have no clue how to decipher |
| 20:51.07 | NetRipper | maejrep[w], that might be true |
| 20:51.11 | cr2 | sizeof() is usually 8, but for some calls it's bigger |
| 20:51.17 | pichurri | orux, hey there!!! |
| 20:51.23 | pichurri | orux, any progress? |
| 20:51.37 | orux | pichurri, i am playing with dma_cfg flags |
| 20:52.02 | cr2 | maejrep[w]: there are many such A2M ascii "reasons". something to be put into wiki too :) |
| 20:52.15 | maejrep[w] | orly |
| 20:52.28 | maejrep[w] | each one means something different? |
| 20:52.43 | cr2 | maejrep[w]: it's work in progress, i don't have it with me now |
| 20:52.56 | maejrep[w] | np |
| 20:53.00 | pichurri | orux, did you see what NetRipper said about physical address on haret and the hardcoded? |
| 20:53.12 | NetRipper | my god @ forum: "thank's...is there a date for the release?" |
| 20:53.12 | cr2 | hmm. need 32bit linux on the usb first ;) |
| 20:53.32 | cr2 | lol |
| 20:53.34 | maejrep[w] | heh |
| 20:54.16 | orux | pichurri, dma2_cfg is the same that wince uses |
| 20:54.35 | orux | i think dma2_cfg is good |
| 20:54.39 | cr2 | maejrep[w]: raph800 looks more smart than raph100 in microP area |
| 20:55.02 | cr2 | maejrep[w]: it can id the LED part, and the KEY part |
| 20:55.13 | cr2 | maejrep[w]: raph100 only the KEY part |
| 20:55.24 | cr2 | and the id methods are different |
| 20:55.30 | maejrep[w] | :x |
| 20:55.54 | maejrep[w] | as in, determine a revision number of some sort? or identify what kind of LED/KEY it is? |
| 20:55.56 | cr2 | so it'd be different _probe() / _init() functions |
| 20:56.05 | cr2 | revision |
| 20:56.14 | cr2 | for the firmware |
| 20:56.17 | maejrep[w] | I noticed in HSPL there's a "MicroP KEY" version and "MicroP LED" version |
| 20:56.18 | orux | pichurri, y can dump some mdp registers from haret |
| 20:56.30 | cr2 | maejrep[w]: exactly |
| 20:56.41 | cr2 | maejrep[w]: i have it more of less decoded |
| 20:56.59 | maejrep[w] | cool, but you're saying raph100 can't report the id for LED? |
| 20:57.02 | pichurri | orux, how which? |
| 20:57.02 | cr2 | maejrep[w]: btw, you'd use the right i2c ids |
| 20:57.02 | maejrep[w] | id/revision |
| 20:57.11 | pichurri | orux, sorry, first timer! :p |
| 20:57.20 | maejrep[w] | i'd use the right i2c ids for what? |
| 20:57.33 | cr2 | c4/2 for psoc, cc/2 and ce/2 for microP |
| 20:57.45 | cr2 | the i2c ids are 7bit |
| 20:57.53 | maejrep[w] | right |
| 20:58.00 | cr2 | and shifted left to leave space for the write bit |
| 20:58.02 | maejrep[w] | as in, they're correct on each? |
| 20:58.09 | cr2 | left |
| 20:58.09 | maejrep[w] | yup, read bit* |
| 20:58.25 | NexVision | netripper when i tell it to listen it pops up and tells me cant bind socket |
| 20:58.33 | NexVision | rebooted twice |
| 20:58.35 | cr2 | you take the id, shift it left, so the LSB is free for rw |
| 20:58.38 | NexVision | and telnet cant connect |
| 20:58.48 | maejrep[w] | cr2: yeah I have all that working |
| 20:58.56 | NetRipper | NexVision, telnet to port 9999 |
| 20:59.02 | cr2 | maejrep[w]: so you don't really need 0xcc>>1 to id the chip |
| 20:59.02 | maejrep[w] | but i2c-msm takes care of the shifting |
| 20:59.05 | NetRipper | NexVision, connect the phone via activesync |
| 20:59.18 | NetRipper | NexVision, then "telnet 169.254.2.1 9999" |
| 20:59.19 | maejrep[w] | cr2: I do have to send 0x66 and 0x67 for it to use cc and ce |
| 20:59.24 | NexVision | C:\Documents and Settings\Administrator>telnet 169.254.2.1 port9999 |
| 20:59.24 | NexVision | Connecting To 169.254.2.1...Could not open connection to the host, on port port9 |
| 20:59.24 | NexVision | 999: Connect failed |
| 20:59.25 | orux | for example, MDP_DMA_CONFIG (MSM_MDP_BASE + 0x10180) is at 0xaa210180 |
| 20:59.29 | cr2 | maejrep[w]: the "real" i2c id for navi is 0x62 |
| 20:59.33 | maejrep[w] | the "real" id is 66 and 67 |
| 20:59.34 | NetRipper | NexVision, dont add the word "port" |
| 20:59.36 | maejrep[w] | and yes 62 |
| 20:59.39 | NexVision | k |
| 20:59.59 | maejrep[w] | which is why I have to either a) use 0x62,66,67, or b) use ce>>1, etc |
| 21:00.12 | maejrep[w] | I've been doing ce>>1 because it's more clear which one it is |
| 21:00.13 | NetRipper | NexVision, the "busy" icon on the phone just means that it is waiting for the connection |
| 21:00.16 | NetRipper | :) |
| 21:00.18 | maejrep[w] | since the wiki is showing ce,cc,c4, etc |
| 21:00.20 | orux | pichurri, with haret: pdump 0xaa210180 0x4 |
| 21:00.25 | cr2 | maejrep[w]: it's the msm implementation issue. from the point of of the protocol the ids at 62,66, and 67 |
| 21:00.27 | NexVision | ok im in |
| 21:00.38 | maejrep[w] | yes I understand that :) |
| 21:00.40 | NetRipper | NexVision, ok, open up http://wiki.xda-developers.com/index.php?pagename=RaphaelKeyboard |
| 21:00.46 | maejrep[w] | and that's what I'm sending for i2c_client->addr |
| 21:00.47 | NetRipper | NexVision, you have an xda account? |
| 21:00.54 | NexVision | yeah |
| 21:00.57 | cr2 | maejrep[w]: wiki shows it because of the mmutrace and wince code |
| 21:00.59 | NexVision | im on the wiki |
| 21:00.59 | maejrep[w] | I'm just shifting it so that visually in the code I can tell which one it is easily |
| 21:01.00 | NetRipper | ok then at the bottom, click edit |
| 21:01.08 | cr2 | ok |
| 21:01.20 | pichurri | orux, you think that the places where writel writes, are correct? |
| 21:01.23 | NexVision | ok |
| 21:01.26 | NetRipper | NexVision, you're going to add a column there, __RAPH500__, i guess you'll figure out how that works |
| 21:01.29 | maejrep[w] | If you think we should use the real IDs and maybe define macros, that would probably be just as easy to work with |
| 21:01.35 | NetRipper | NexVision, back to your telnet session |
| 21:01.42 | cr2 | maejrep[w]: i had the htc_i2c_ids table in the wiki |
| 21:01.45 | NetRipper | NexVision, type "clearvar gpios" |
| 21:01.49 | orux | pichurri, i think yes |
| 21:01.55 | NetRipper | NexVision, then "addlist mmutrace 0xb230000c" |
| 21:02.00 | cr2 | maejrep[w]: and this table has only "real" ids |
| 21:02.13 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
| 21:02.15 | maejrep[w] | gotcha |
| 21:02.16 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 21:02.19 | Untouchab1e | Good evening |
| 21:02.25 | NetRipper | evening Untouchab1e |
| 21:02.36 | NetRipper | Untouchab1e, nice job responding to many on the forum :) |
| 21:02.47 | NexVision | k |
| 21:02.51 | orux | pichurri, the dumped values from haret are the same that htc_console writes |
| 21:02.56 | NexVision | im at a 3rd prompt now |
| 21:02.59 | NetRipper | NexVision, ok |
| 21:03.00 | Untouchab1e | hehe, thank you |
| 21:03.10 | NetRipper | NexVision, open the keyboard on the phone |
| 21:03.12 | Untouchab1e | I consider myself quite available, hehe |
| 21:03.21 | NexVision | k |
| 21:03.44 | orux | the problem is with the registers from mdp that htc_console dont write :) |
| 21:03.48 | cr2 | http://wiki.xda-developers.com/index.php?pagename=HTC_I2C_IDs |
| 21:03.49 | NetRipper | NexVision, in haret type "wirq 5"... it'll listen on the irqs for 5 seconds... then press a key (i.e. top left, i worked my way top left to bottom right).. |
| 21:04.01 | pichurri | orux, I got : |
| 21:04.02 | pichurri | aa210180 | 0032616a | ja2. |
| 21:04.07 | maejrep[w] | ahh yes I did see that cr2 |
| 21:04.23 | orux | and there are a lot on mdp_hw.h |
| 21:04.38 | NexVision | where in haret |
| 21:04.46 | NetRipper | in the console |
| 21:04.49 | NetRipper | telnet |
| 21:04.51 | orux | pichurri, ok |
| 21:04.53 | cr2 | NetRipper: can we create a SDIO controller usage table for different devices ? |
| 21:05.01 | NetRipper | cr2, yes i still have that on my todo |
| 21:05.04 | NexVision | ahh ok |
| 21:05.04 | pichurri | orux, that is the value pushed in writel(dma2_cfg, MDP_DMA_CONFIG); ? |
| 21:05.21 | NexVision | 4th now |
| 21:05.21 | orux | pichurri, yes |
| 21:05.47 | Untouchab1e | NetRipper, may I ask what you are currently working on? |
| 21:05.59 | cr2 | NetRipper: can you explain me why does the wifi not work on raph ? |
| 21:06.03 | NetRipper | NexVision, you'll get output like this: http://netripper.pastebin.com/d15b9b34 |
| 21:06.24 | NetRipper | cr2, err, you tell me? |
| 21:06.37 | NetRipper | cr2, the kernel does not have the driver, does it? |
| 21:06.44 | NetRipper | thought it was closed source |
| 21:06.52 | NexVision | http://netripper.pastebin.com/m1569bc31 |
| 21:06.57 | NexVision | thats what i got |
| 21:07.07 | cr2 | NetRipper: it's not included into the git, but the source is available |
| 21:07.18 | cr2 | probably because it's bulky |
| 21:07.28 | cr2 | git = kernel git |
| 21:07.39 | NetRipper | NexVision, hm |
| 21:08.23 | cr2 | NetRipper: i have some comments after looking in the clk api implementation |
| 21:08.27 | NetRipper | NexVision, do "addlist mmutrace 0xb2300000" |
| 21:08.53 | NetRipper | cr2, shoot |
| 21:08.56 | cr2 | NetRipper: the _enable and _disable bits are probably wrong |
| 21:09.12 | cr2 | you need to manipulate these bits, sure |
| 21:09.23 | cr2 | but they are not enable/disable bits |
| 21:09.27 | NexVision | done |
| 21:09.40 | cr2 | because the mddi and i2c clocks do not have these bits set |
| 21:09.49 | orux | pichurri, i am playing now with the spl. disassembling and debugging it (learning how all hardware are initialized) |
| 21:09.55 | NetRipper | NexVision, do a wirq 5 again, and press a key |
| 21:10.19 | NetRipper | (a key on the phone) |
| 21:10.28 | cr2 | NetRipper: and it's a very bad idea to hardcode the plain gpio numbers |
| 21:10.37 | NetRipper | can you put the output on pastebin again NexVision ? |
| 21:10.50 | NetRipper | cr2, you mean the ones in the boardfile? |
| 21:10.56 | cr2 | NetRipper: like g1 ;) let's create some raphael.h, and #define the gpios |
| 21:11.06 | pichurri | how do you debug? |
| 21:11.07 | cr2 | not only in the board file |
| 21:11.13 | NexVision | http://netripper.pastebin.com/m716434a7 |
| 21:11.13 | pichurri | orux, how do you debug? |
| 21:11.17 | maejrep[w] | that's a good idea ;o |
| 21:11.22 | cr2 | the famous gpio 94 for vsync comes to mind |
| 21:11.23 | NexVision | brb got customers ill let u know when im back |
| 21:11.25 | Untouchab1e | If the WiFi Driver is closed source, that means we have to make our own then, ro? |
| 21:11.26 | Untouchab1e | pr* |
| 21:11.28 | Untouchab1e | right* |
| 21:11.35 | maejrep[w] | especially since the gpio's vary so much between device versions |
| 21:11.41 | cr2 | Untouchab1e: it's _not_ closed source |
| 21:11.55 | *** join/#htc-linux LanceHaig (n=lanceh@foresight/member/lhaig) |
| 21:11.59 | orux | pichurri, with axd |
| 21:12.03 | pichurri | orux, do you go just looking at the assembly? |
| 21:12.15 | cr2 | maejrep[w]: keep in mind that you need to rewrite a good chunk of the mddi stuff anyway :D |
| 21:12.16 | orux | pichurri, and ida |
| 21:12.48 | cr2 | the wifi driver is GPL |
| 21:13.09 | *** part/#htc-linux LanceHaig (n=lanceh@foresight/member/lhaig) |
| 21:13.11 | cr2 | but don't ask me how it's compiled and interfaced to the kernel |
| 21:13.19 | NetRipper | NexVision, wow, i realiase the telnet way sucks ;) |
| 21:13.28 | cr2 | it was not obvious for me after looking at the source |
| 21:13.36 | AstainHellbring | NetRipper whats a better way than the telnet way? |
| 21:13.50 | maejrep[w] | haretconsole.py |
| 21:13.59 | NetRipper | AstainHellbring, using haret console |
| 21:14.17 | lupine_85 | allo |
| 21:14.29 | AstainHellbring | ahh right |
| 21:14.51 | cr2 | maejrep[w]: what driver sre you going to write next ? :-) |
| 21:15.01 | maejrep[w] | haha |
| 21:15.05 | maejrep[w] | navi was on my mind ;x |
| 21:15.12 | maejrep[w] | but I still can't quite figure out what the registers mean |
| 21:15.16 | maejrep[w] | *bytes? |
| 21:15.24 | cr2 | led / backlight ? |
| 21:15.31 | maejrep[w] | no, cap sense |
| 21:15.33 | maejrep[w] | http://wiki.xda-developers.com/index.php?pagename=Raphael_Navi |
| 21:15.43 | NetRipper | oi, let him first finish up keyboard |
| 21:15.44 | NetRipper | please |
| 21:15.44 | NetRipper | :P |
| 21:15.47 | maejrep[w] | haha |
| 21:15.50 | *** join/#htc-linux mrincred (n=wmirc_us@174-144-92-3.pools.spcsdns.net) |
| 21:16.05 | cr2 | maejrep[w]: the reg0 and reg1 are used for the id |
| 21:16.21 | cr2 | these are tables sized 0x12 and 0x20 |
| 21:16.52 | cr2 | so prepare to deal with multibyte ops |
| 21:16.57 | cr2 | read and write |
| 21:17.44 | cr2 | NetRipper: btw, do you have a platform_device for the msm_touchscreeen ? |
| 21:18.16 | cr2 | NetRipper: and the A81* area may need some name in the header |
| 21:18.35 | cr2 | maejrep[w]: do you have TVout ? |
| 21:18.39 | NetRipper | NexVision, it's going to be annoying this way.. but you can recognize the scancode this way... start from the top of the output, find two subsequent (ldr) lines, the first line of that group must have a value (second-last column), the second line of that group must have 0 again |
| 21:18.45 | maejrep[w] | cr2: no |
| 21:18.53 | NetRipper | NexVision, in your last paste, line 22 has the scancode (0x8) |
| 21:19.01 | cr2 | NetRipper: do you have TVout ? |
| 21:19.11 | maejrep[w] | cr2: reg0 and reg1 for what? |
| 21:19.18 | maejrep[w] | the navi? |
| 21:19.23 | cr2 | maejrep[w]: for navi aka psoc |
| 21:19.31 | NetRipper | cr2, i dont have the tvout cable |
| 21:19.33 | maejrep[w] | oh |
| 21:19.45 | maejrep[w] | the cap touch sensor ? |
| 21:20.01 | cr2 | maejrep[w]: hmm, the luminosity sensor must be somewhere around too |
| 21:20.08 | cr2 | yes |
| 21:20.28 | *** join/#htc-linux pichurri_ (n=pichurri@194.230.146.33) |
| 21:20.37 | maejrep[w] | I've seen the luminosity sensor i think |
| 21:20.42 | maejrep[w] | i think its on the 0x30 chip, no? |
| 21:20.44 | pichurri_ | orux, I don't think it is the init code... |
| 21:20.50 | maejrep[w] | along with accelerometer? |
| 21:20.59 | cr2 | maejrep[w]: 0x30 ? |
| 21:21.03 | cr2 | no |
| 21:21.07 | maejrep[w] | err |
| 21:21.11 | maejrep[w] | 30>>1 whatever that is |
| 21:21.12 | lupine_85 | maejrep[w]: I can set up a trac if you want one |
| 21:21.12 | maejrep[w] | heh |
| 21:21.14 | cr2 | accelerometer is 0x30 ? |
| 21:21.16 | pichurri_ | orux, have you seen htc_fb_console? without initialization it tries to write to the fb mem and send commands to the panel... |
| 21:21.27 | maejrep[w] | yes, for me |
| 21:21.33 | NetRipper | NexVision, a better way would be if you install python 2.x, then get haretconsole and use that ;) unless you dont mind having to look carefully |
| 21:21.34 | cr2 | seems like 0x18 to me |
| 21:21.50 | NetRipper | i gtg for a little while, bbl |
| 21:21.50 | cr2 | ok, never mind |
| 21:21.57 | pichurri_ | orux, I think we have 2 problems, fb address and perhaps a missing command to send to the panel |
| 21:22.32 | NetRipper | cr2, please list any hints regarding the touchscreen irq.. or update wiki, or list something in my pm.. :) and no i dont have it as platform_device... may look into that later |
| 21:22.34 | orux | i think fb adress is not problem, |
| 21:22.40 | NetRipper | gtg |
| 21:22.53 | cr2 | maejrep[w]: do we know the cam ids ? |
| 21:23.00 | maejrep[w] | lupine_85: I use trac all the time, and I think its a good way to keep people on task, but it sometimes feels like an obligation, which obviously no one here wants to feel "obligated" to do any of this |
| 21:23.11 | maejrep[w] | I'd probably use it if you set it up, but I can't speak for everyone else |
| 21:23.14 | pichurri_ | orux, "<NetRipper> htc_fb_console says base 0x16800000 + offset 0x0006a000 (=0x1686a000), haret tells me 0x1666a000" |
| 21:23.15 | orux | pichurri, perhaps mddi code |
| 21:23.25 | maejrep[w] | cr2: I think so, I took a haret trace while initializing the cam |
| 21:23.38 | maejrep[w] | odd thing though, is that virtually all of the i2c chatter was *write*, not read |
| 21:23.42 | cr2 | maejrep[w]: raph100 has 2 |
| 21:23.43 | pichurri_ | orux, NetRipper has a raph100 and it outputs correctly with htc_fb_console... |
| 21:23.44 | maejrep[w] | I don't understand why that would be the case |
| 21:23.47 | maejrep[w] | oh right |
| 21:23.52 | maejrep[w] | cr2: raph800 only has the main cam |
| 21:24.19 | cr2 | maejrep[w]: the data comes in to the CAM alt gpios |
| 21:24.23 | maejrep[w] | cr2: should it be gettin the image data from i2c as well, or somewhere else? |
| 21:24.24 | orux | pichurri, i think this is not from blackstone, haret say: 0x16044800 |
| 21:24.26 | maejrep[w] | oh really? |
| 21:24.36 | cr2 | maejrep[w]: what you see is the control channel |
| 21:24.40 | maejrep[w] | i see |
| 21:24.44 | cr2 | which is mainly writes to the chip |
| 21:24.53 | maejrep[w] | it also turns on the accelerometer when turning on the camera :) probably to stabilize |
| 21:25.11 | cr2 | hmm, interesting |
| 21:25.18 | maejrep[w] | do we need to decode that control api also? :p |
| 21:25.18 | orux | pichrri, if you write from this adress (in wince) it is dump to screen |
| 21:25.38 | cr2 | maejrep[w]: it depends on your cam |
| 21:25.41 | lupine_85 | finishes the backscroll |
| 21:25.43 | maejrep[w] | oh great! |
| 21:25.44 | maejrep[w] | :P |
| 21:25.56 | cr2 | maejrep[w]: tha cam in raph100 is the same as in g1 |
| 21:26.10 | cr2 | do we have a driver source ? |
| 21:26.16 | lupine_85 | maejrep[w]: if people are wont to use it, I'd be happy to stick it up. if it'd just be you... perhaps less point :p |
| 21:26.21 | maejrep[w] | yeah, its in our branch already |
| 21:26.27 | pichurri_ | NetRipper, could you test if dumping the memory from 0x1686a000 dumps the screen...? :P, plz |
| 21:26.40 | maejrep[w] | lupine_85: sure |
| 21:27.07 | maejrep[w] | check with NetRipper and other contributors i guess |
| 21:27.23 | maejrep[w] | cr2 probably doesn't have time to deal with trac ;p |
| 21:27.35 | lupine_85 | hehe |
| 21:27.45 | Untouchab1e | I just tried out the package i put together on a DIAM100 just now. For some reason, the display is in landscape mode when booting Android (so is the virtual keyboard) |
| 21:27.46 | AstainHellbring | wow so camera support for raph100 sounds like htc made it easy there? |
| 21:28.08 | maejrep[w] | cr2: i think the main cam in raph800 is the same as well, but on a different i2c chip id |
| 21:28.25 | cr2 | maejrep[w]: ??? |
| 21:28.29 | Balsat | Untouchable : try with mtype=1805 |
| 21:28.34 | lupine_85 | mm, would be nice to have the camera aussi :) |
| 21:28.34 | cr2 | diffrent chips |
| 21:28.39 | maejrep[w] | er |
| 21:28.46 | maejrep[w] | by chip ID I mean i2c_client->addr |
| 21:28.49 | Untouchab1e | ah, ok.. have mtype 1910 atm |
| 21:28.53 | maejrep[w] | (0x62, 0x66, 067) |
| 21:28.59 | cr2 | maejrep[w]: unlikely |
| 21:29.06 | maejrep[w] | I saw it with my own eyes ;) |
| 21:29.11 | maejrep[w] | look in board-trout.c |
| 21:29.24 | cr2 | which one ? |
| 21:29.26 | maejrep[w] | they use 0xce>>1 I think, which is our keyboard |
| 21:29.33 | NetRipper | Untouchab1e, for diamond you haev to keep mtype 1805 |
| 21:29.34 | maejrep[w] | the driver is mt...something |
| 21:29.41 | cr2 | hehe |
| 21:29.43 | j0b0 | Untouchab1e if you have mtype 1910 the kernels thinks youre a raph and listens to the keyboard slider gpi |
| 21:29.52 | j0b0 | which is always high on a diam |
| 21:30.03 | orux | pichurri, if you change 0x16800000 in htc_console, and uses 0x1600000 (plus offset 44800), the result, on screen, is the same! |
| 21:30.14 | cr2 | maejrep[w]: ok, many chips let you pick an i2c id |
| 21:30.16 | lupine_85 | reclones the kernel |
| 21:30.17 | maejrep[w] | anyway, the chip ID they use for it matches up with one of our chip IDs, but in our phone that chip id is for a different purpose, not the camera |
| 21:30.20 | maejrep[w] | right |
| 21:30.41 | cr2 | maejrep[w]: which id did you trace for the cam ? |
| 21:30.58 | maejrep[w] | I can't trace just an id, can only trace i2c reads and writes |
| 21:31.02 | maejrep[w] | so it captures everything |
| 21:31.18 | Untouchab1e | thanks for the tip |
| 21:31.18 | maejrep[w] | but I'd have to check my logs to know which chip id it was |
| 21:31.31 | cr2 | yes, but i2c id is the most used byte |
| 21:31.32 | maejrep[w] | I *think* it was 0x116 (16>>1) |
| 21:32.01 | cr2 | ok, something to check in the cif.dll |
| 21:32.13 | cr2 | maybe i knew it, but forgot now :) |
| 21:32.27 | lupine_85 | maejrep[w]: did you get all the raph100 scancodes you need? |
| 21:32.37 | maejrep[w] | I think so, NetRipper updated the wiki |
| 21:32.46 | cr2 | i've also checked the qtv.dll, but didn't find the tv encoder area... |
| 21:33.07 | lupine_85 | commit! commit! commit! :) |
| 21:33.10 | maejrep[w] | and I guess NexVision was working on getting raph500 |
| 21:33.29 | lupine_85 | (/givez0r test images :D) |
| 21:33.32 | maejrep[w] | lupine_85: heh, it's at home ;p plus i want to try to clean it up some.. |
| 21:33.57 | maejrep[w] | there's also the issue of the clamshell |
| 21:34.08 | maejrep[w] | in wince, they only enable the keyboard when clamshell is open |
| 21:34.15 | maejrep[w] | so we need to find the best way to implement that |
| 21:34.22 | Untouchab1e | with set mtype 1805, It just goes to "Booting Linux", and stops when the loading bar is full |
| 21:34.30 | maejrep[w] | I think it definitely needs to come out of board-htcraphael-keypad, because its *not* related to the keypad/navi keys |
| 21:34.48 | maejrep[w] | Untouchab1e: that means the mtype is wrong, or the kernel doesn't support that mtype |
| 21:34.59 | Balsat | Try with the zImage i postet on xda |
| 21:35.12 | Untouchab1e | Balsat said that it should be mtype 1805 |
| 21:35.49 | Untouchab1e | I think the zImage should work just fine, but its probably just the default.txt there is something wrong with |
| 21:35.51 | maejrep[w] | so I'll probably implement the clamshell the same way as it is now in keypad, but put it in the keyboard driver, which should only be used by raphael devices |
| 21:35.58 | j0b0 | maejrep the whole keypad thing need to come out of board keypad, or some i2c stuff need to move in, because it still cant tell home from send and back from end |
| 21:36.00 | Balsat | Depends on the kernel build |
| 21:36.01 | maejrep[w] | and also make it enable/disable the keyboard |
| 21:36.16 | cr2 | maejrep[w]: what about the keyboard leds ? do you trace them ? |
| 21:36.42 | maejrep[w] | cr2: kind of.. on the raph keyboard wiki page you can see my best guess of what happens with each |
| 21:36.50 | maejrep[w] | though I've been ignoring 0xcc for the time being |
| 21:36.57 | Balsat | I'dont think jobo use the mtype=1805 on he's build |
| 21:37.16 | maejrep[w] | I don't know what they are acutally doing, and it seems the 0xcc values change pretty much all the time, so I don't know what they are supposed to be |
| 21:37.21 | cr2 | maejrep[w]: don't forget to #ifdef ANDROID all the weird code :) |
| 21:37.28 | maejrep[w] | which weird code? |
| 21:37.35 | orux | pichurri_, i ve to go. I will try to learn more about mddi. I think is the key |
| 21:37.36 | Untouchab1e | aah |
| 21:37.42 | Untouchab1e | il, try your zimage then |
| 21:37.48 | pichurri_ | orux, ok, me too |
| 21:37.48 | pichurri_ | ! |
| 21:37.52 | pichurri_ | orux, night! |
| 21:37.57 | cr2 | like calibrtion data in the kernel |
| 21:38.02 | j0b0 | Balsat my recent kernels recognize mtype 1805 |
| 21:38.10 | j0b0 | ever since i last updated my git |
| 21:38.11 | maejrep[w] | what kind of calibration data? :X |
| 21:38.21 | maejrep[w] | like disabling the kyeboard on clamshell close, etc? |
| 21:38.42 | orux | pichurri_, where are you from? |
| 21:38.59 | cr2 | the keyboard reampping and modifiers are treated by 'loadkeys' for me :) |
| 21:38.59 | pichurri_ | orux, :) Colombia! you? |
| 21:39.11 | pichurri_ | orux, but I'm living in switzerland |
| 21:39.14 | lupine_85 | mm, raph100 sucks power running illume just now :D |
| 21:39.16 | orux | spain |
| 21:39.26 | cr2 | and enabling/ disabling the keyboard when some other events happen is a userspace issue too |
| 21:39.43 | maejrep[w] | cr2: remapping as in I shouldn't have separate keymaps? |
| 21:39.49 | lupine_85 | I left it running E17 to show it off at work and it died in, like, 3 hours |
| 21:40.01 | Balsat | Jobo : ok that god to know, but strange it wont run on the diam100 then |
| 21:40.11 | cr2 | maejrep[w]: as long as it is not a separate keycode, yes |
| 21:40.12 | maejrep[w] | lupine_85: there's no power management code active yet |
| 21:40.24 | maejrep[w] | cr2: each key is different |
| 21:40.27 | lupine_85 | Is there any way to pull *just* the htc-msm-2.6.25 branch from linuxtogo ? |
| 21:40.34 | maejrep[w] | so R on raph800 might be E on raph100 |
| 21:40.39 | maejrep[w] | (same scancode) |
| 21:41.03 | maejrep[w] | that shouldn't be configured in pdata? |
| 21:41.05 | cr2 | maejrep[w]: does fn-X send two scancodes ? |
| 21:41.14 | maejrep[w] | fn is its own keycode (like ALT key) |
| 21:41.16 | cr2 | probably |
| 21:41.16 | pichurri_ | orux, I think that xmoo is in spain or is from spain... |
| 21:41.16 | Untouchab1e | Balsat, your zImage seems promising.. booting up in a minute |
| 21:41.24 | orux | pichurri_, my english is bad, so we can meet in an spanish room :) |
| 21:41.25 | cr2 | ok |
| 21:41.33 | maejrep[w] | so +Fn, then press other keys, -Fn |
| 21:41.36 | pichurri_ | orux, ok! |
| 21:41.38 | maejrep[w] | it would be handled by OS I think |
| 21:41.42 | maejrep[w] | er, but userland |
| 21:41.47 | maejrep[w] | by* >:| |
| 21:41.58 | cr2 | +fn is like caps ? |
| 21:41.59 | Balsat | UT : let me know if it work |
| 21:42.03 | maejrep[w] | no |
| 21:42.09 | pichurri_ | orux, but I think is good for everybody to chat on english, like for the logs and stuff that others can find useful... |
| 21:42.14 | maejrep[w] | its a press/release |
| 21:42.20 | cr2 | ok |
| 21:42.22 | maejrep[w] | unless i build in sticky bits for it |
| 21:42.30 | maejrep[w] | like halibut has done |
| 21:42.32 | orux | pichurri_, yes, of course, for me too |
| 21:42.34 | cr2 | hehe |
| 21:42.35 | maejrep[w] | er, maybe that was kaiser |
| 21:42.42 | cr2 | keep the kernel simple |
| 21:42.50 | maejrep[w] | one of them holds sticky bits for caps, fn, shift, etc |
| 21:42.54 | pichurri_ | orux, I might go to barcelona on a month...jajaja |
| 21:43.07 | cr2 | android != unix |
| 21:43.15 | maejrep[w] | but I don't think android has something built in for that does it? |
| 21:43.33 | orux | pichurri_, i ve my home near |
| 21:43.33 | maejrep[w] | with X11 and a WM you could use accessibility Sticky Keys to emulate it |
| 21:43.36 | cr2 | don't know |
| 21:43.44 | maejrep[w] | but I don't know if android will let us do that easily |
| 21:43.50 | orux | pichurri_, well, bye |
| 21:44.06 | pichurri_ | orux, cya |
| 21:44.07 | cr2 | wehn the kernelissues are solved, i'd like to check qtopia |
| 21:44.44 | cr2 | maejrep[w]: btw, you have added the weird offsets for SMD channels ? |
| 21:44.51 | cr2 | into wiki |
| 21:45.00 | maejrep[w] | cr2: at some point you're gonna have to explain how you think the keyboard (and eventually navi/keypad) should work :) I'm not a kernel hacker, though i've been a linux user for almost 10 years |
| 21:45.11 | maejrep[w] | cr2: yes, with "**" notes by them |
| 21:45.14 | j0b0 | maejrep does it take care of the fn and caps leds itself or does the driver have to set and clear those |
| 21:45.20 | maejrep[w] | and an added column to indicate its for MSM7500 |
| 21:45.31 | pichurri_ | night everybody! |
| 21:45.32 | maejrep[w] | j0b0: separate driver does that |
| 21:45.35 | maejrep[w] | not keyboard driver |
| 21:45.53 | cr2 | maejrep[w]: are they correct for raph ? |
| 21:45.59 | maejrep[w] | yep |
| 21:46.07 | maejrep[w] | well, raph800 |
| 21:46.12 | maejrep[w] | and they match vogue-smd.c |
| 21:46.18 | cr2 | maejrep[w]: there must be a better way to calculate the offsets |
| 21:46.21 | maejrep[w] | which is also MSM7500 right? |
| 21:46.31 | cr2 | no |
| 21:46.38 | cr2 | you have 7500A |
| 21:46.39 | AstainHellbring | yes vogue is msm7500 but raph800 is MSM7501a |
| 21:46.41 | maejrep[w] | right |
| 21:46.44 | maejrep[w] | yes |
| 21:46.47 | maejrep[w] | I understand that :) |
| 21:46.55 | maejrep[w] | I meant 750x(x) |
| 21:47.03 | maejrep[w] | the 75 vs 72 was all I was pointing out |
| 21:47.05 | j0b0 | so this separate driver tracks or accesses some kind of sticky bits |
| 21:47.07 | AstainHellbring | ahh ok |
| 21:47.10 | cr2 | kaiser has different offsets |
| 21:47.18 | maejrep[w] | :| |
| 21:47.19 | cr2 | from tita/vogue |
| 21:47.42 | cr2 | well, i'm thinking what to do nexrt |
| 21:47.46 | lupine_85 | votes for no sticky bits |
| 21:47.56 | lupine_85 | it's an actual keyboard. you can press two keys at a time |
| 21:48.02 | maejrep[w] | yep |
| 21:48.05 | maejrep[w] | and it works too :P |
| 21:48.08 | maejrep[w] | Ctrl+C |
| 21:48.18 | lupine_85 | sticky bits are a dirty hack for onscreen keyboards |
| 21:48.23 | maejrep[w] | that pissed me off about pocketpotty on my mogul :P |
| 21:48.33 | lupine_85 | pocketpotty? ;) |
| 21:48.38 | maejrep[w] | lol |
| 21:48.40 | lupine_85 | enjoys ctrl+c |
| 21:48.46 | maejrep[w] | putty ;p |
| 21:49.39 | maejrep[w] | cr2: how far off is kaiser's offset? |
| 21:50.00 | maejrep[w] | we could try scanning the 0xfc000 area until we find something that looks right :x |
| 21:50.38 | cr2 | maejrep[w]: they are completely different |
| 21:50.58 | cr2 | maejrep[w]: there must be some sane way how wince keeps track of these |
| 21:51.02 | maejrep[w] | and different from raph100 too? |
| 21:51.11 | cr2 | i guess they are done by ioremap() or so |
| 21:51.12 | maejrep[w] | well, its probably just built into the driver :x |
| 21:51.31 | cr2 | unfortunately it's different from the g1 too. it seems |
| 21:51.42 | cr2 | no, they are not built-in |
| 21:51.59 | cr2 | maejrep[w]: btw, have you ever dumped the wince dmes area in haret ? |
| 21:52.18 | cr2 | s/dmes/dmesg/ |
| 21:52.18 | maejrep[w] | i tried, there was nothing there |
| 21:52.21 | maejrep[w] | mostly all 0 |
| 21:52.26 | cr2 | nothing ?? |
| 21:52.26 | maejrep[w] | or all ff |
| 21:52.28 | maejrep[w] | nope |
| 21:52.39 | maejrep[w] | could be at a different offset |
| 21:52.45 | cr2 | it'd be a nice ascii log |
| 21:52.52 | cr2 | hmm. maybe |
| 21:53.09 | maejrep[w] | but i don't think I can dump the entire memory space :) |
| 21:53.14 | maejrep[w] | to look for it |
| 21:53.19 | cr2 | run 'dump mmu' |
| 21:53.39 | maejrep[w] | would it be a 1M area? |
| 21:53.41 | cr2 | it'd be at the top of the 0x10000000 bank somewhere |
| 21:53.45 | Untouchab1e | Balsat, your image worked perfectly.. Posting it now |
| 21:53.53 | maejrep[w] | ok i'll check that when I get home |
| 21:54.01 | cr2 | maejrep[w]: you have 256MB ? |
| 21:54.04 | cr2 | ok |
| 21:54.05 | maejrep[w] | is it possible they would disable or shadow that? |
| 21:54.14 | cr2 | unlikely |
| 21:54.16 | maejrep[w] | 256 or 512? |
| 21:54.19 | XD | so any development on andriod on raph400 |
| 21:54.20 | maejrep[w] | i forget |
| 21:54.25 | maejrep[w] | wtf is raph400? |
| 21:54.26 | maejrep[w] | omfg |
| 21:54.38 | maejrep[w] | they need to stop making new raphs!! |
| 21:54.39 | cr2 | XD: same question |
| 21:54.40 | maejrep[w] | :P |
| 21:54.48 | XD | lol |
| 21:54.59 | XD | it's vzw raph |
| 21:55.01 | lupine_85 | raph500 with a slipped finger? |
| 21:55.07 | XD | err |
| 21:55.19 | cr2 | XD: dump the spl |
| 21:55.21 | maejrep[w] | ohh |
| 21:55.23 | maejrep[w] | lol ok :p |
| 21:55.43 | maejrep[w] | cr2: 512MB ROM, 288MB RAM |
| 21:55.44 | Balsat | UT : that's nice |
| 21:56.09 | cr2 | maejrep[w]: 288=256+32 ? |
| 21:56.17 | AstainHellbring | yes cr2 |
| 21:56.48 | cr2 | i think raph100 was 256+64 ? but 32 is eaten by arm9 |
| 21:57.11 | maejrep[w] | could be? |
| 21:57.16 | AstainHellbring | as far as I recall both have same mem setup |
| 21:57.21 | maejrep[w] | i think so too |
| 21:57.30 | cr2 | ok |
| 21:57.34 | Untouchab1e | There is another thing we should do... Considering the Raph and Diamond are VGA devices, the notification area is nearly impossible to pull down with the finger, as the resolution is much higher than on the G1, meaning the area in where we can actually get a hold of the curtain is smaller |
| 21:57.51 | Untouchab1e | so if we could somehow increase the size of the grabbable area |
| 21:57.56 | Untouchab1e | if you get my meaning |
| 21:58.19 | cr2 | androod kernel still can't support discontg mem ? |
| 21:58.32 | maejrep[w] | via iomap? |
| 21:58.38 | maejrep[w] | what would you want to be discontiguous? |
| 21:58.58 | cr2 | 256=128@10000000 + 128@20000000 |
| 21:59.30 | cr2 | the rest is stacked mem |
| 21:59.38 | cr2 | not used by the kernel itself |
| 21:59.53 | cr2 | afair, we run with 64 or 96 now |
| 22:00.00 | maejrep[w] | i use 96 |
| 22:00.07 | cr2 | ok |
| 22:00.27 | AstainHellbring | so whats the max amount we can in theory run with based on that cr2? |
| 22:00.42 | maejrep[w] | that 96 is only for the kernel, right? |
| 22:00.48 | maejrep[w] | apps can still use the remaining memory? |
| 22:00.48 | cr2 | 288 if you are crazy :) |
| 22:00.53 | cr2 | no |
| 22:01.03 | maejrep[w] | we can only use 96 mb in total? |
| 22:01.09 | maejrep[w] | so the rest is just wasted? D: |
| 22:01.16 | cr2 | you can ioremap, but it's not for the apps |
| 22:01.21 | cr2 | yeah |
| 22:01.30 | maejrep[w] | that's lame :P |
| 22:01.48 | cr2 | tell that to g1 people |
| 22:01.54 | maejrep[w] | :| |
| 22:02.08 | maejrep[w] | whats the point of having ram that can't be used? :P |
| 22:02.23 | cr2 | i still don't get it why g1 is not raph100 |
| 22:02.23 | mrincred | 96 on diam500 too? |
| 22:02.34 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
| 22:03.14 | cr2 | maejrep[w]: that'll put g1 in bad light 8) |
| 22:03.16 | maejrep[w] | no probably 64 on raph/diam500 |
| 22:03.23 | j0b0 | ould it be possible to mount the other memory bank as a block device |
| 22:03.37 | NetRipper | use it as swap |
| 22:03.37 | NetRipper | :) |
| 22:03.43 | j0b0 | exactly |
| 22:03.43 | maejrep[w] | haha |
| 22:03.51 | maejrep[w] | that sounds so odd :P |
| 22:03.51 | Untouchab1e | NetRipper, did you see my observation? |
| 22:03.53 | tmzt | cr2: what? |
| 22:03.53 | Untouchab1e | read* |
| 22:03.54 | cr2 | j0b0: yes, but it's still silly |
| 22:03.56 | NetRipper | Untouchab1e, no |
| 22:04.05 | Untouchab1e | [22:57] <Untouchab1e> There is another thing we should do... Considering the Raph and Diamond are VGA devices, the notification area is nearly impossible to pull down with the finger, as the resolution is much higher than on the G1, meaning the area in where we can actually get a hold of the curtain is smaller |
| 22:04.05 | Untouchab1e | [22:57] <Untouchab1e> so if we could somehow increase the size of the grabbable area |
| 22:04.06 | Untouchab1e | [22:57] <Untouchab1e> if you get my meaning |
| 22:04.07 | j0b0 | it is silly |
| 22:04.16 | j0b0 | it was just a thought on how to actually use the ram |
| 22:04.17 | j0b0 | as ram |
| 22:04.22 | maejrep[w] | mount a memory bank as a block device in order to use as swap memory which is normally bad but in this case would be normal |
| 22:04.23 | cr2 | i had discontig mem on jornada820 working 8 years ago |
| 22:04.42 | StarLite | what reso does the G1 have btw? |
| 22:04.47 | tmzt | yeah some ezx uses it |
| 22:04.48 | StarLite | I thought it had vga as well? |
| 22:04.51 | Untouchab1e | It doesnt |
| 22:04.53 | NetRipper | Untouchab1e, i guess it should be relatively easy.. for someone that has the android build environment setup |
| 22:04.54 | cr2 | don't ask me why it's fucked on msm |
| 22:05.12 | tmzt | cr2: why do you say it should be raph100? |
| 22:05.13 | j0b0 | 320x480 |
| 22:05.13 | cr2 | StarLite: half vga |
| 22:05.18 | StarLite | hmzz |
| 22:05.21 | StarLite | :( |
| 22:05.22 | Untouchab1e | 320x480, yeah |
| 22:05.28 | StarLite | I thought it had a better screen :( |
| 22:05.36 | Untouchab1e | Heh, the G1 isnt really good hardware wise.. |
| 22:05.39 | tmzt | but capac psudo-multitouch |
| 22:05.53 | Untouchab1e | I have one right here (the ADP1), and the build quality is nowhere near the Touch Pro |
| 22:05.54 | maejrep[w] | yeah the capacitive touch screen is nice ;/ |
| 22:05.57 | tmzt | s/psudo/pseudo/ |
| 22:05.58 | lupine_85 | <3s raph hardware |
| 22:06.05 | Untouchab1e | yeah, thats the best thing about it (besides running Android) |
| 22:06.06 | lupine_85 | the X1 didnt' speak to me either |
| 22:06.06 | *** join/#htc-linux yoyey1 (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:06.23 | cr2 | maejrep[w]: raph has capacitive touchscreen too :) |
| 22:06.39 | tmzt | it does? not just the navi? |
| 22:06.50 | Untouchab1e | hehe, the Raph has a resistive touch screen im afraid |
| 22:06.56 | Untouchab1e | but the navi, as you said, is capactive |
| 22:06.59 | j0b0 | just the navi |
| 22:07.04 | cr2 | tmzt: which all the money to burn@google they could have done android for raph, instead of g1 |
| 22:07.12 | Untouchab1e | has been thinking about how to replace it with a capactive screen :) |
| 22:07.17 | tmzt | we can get palm pre commands from it |
| 22:07.19 | tmzt | maybe |
| 22:07.40 | tmzt | top half of ipod touch |
| 22:08.52 | Untouchab1e | A Touch Pro with a capactive touch screen and Android would probably be the perfect phone for me ^^ |
| 22:08.54 | cr2 | has anybody tried to compile the wifi driver ? |
| 22:09.28 | cr2 | Untouchab1e: that's why i'm surprised. even the normal touchscreen will suffice |
| 22:09.39 | Untouchab1e | what do you mean surprised? |
| 22:10.13 | cr2 | Untouchab1e: that android was developed for g1 |
| 22:11.30 | cr2 | if they really wanted to beat wince to death, raph and blackstone would have been a better choice |
| 22:11.45 | lupine_85 | cr2: where is it? |
| 22:11.58 | Untouchab1e | I know.. |
| 22:11.59 | cr2 | hehe, and the lame apple phone too ;) |
| 22:12.28 | tmzt | cr2: someone is building acx100 for ba, could that work on msm? |
| 22:12.28 | Untouchab1e | ive been talking to my brother, who works in Google and discussed why they launched Google's newborn pride, Android, on such a poorly-made handset |
| 22:12.30 | cr2 | is there linux for 3G ? |
| 22:12.40 | StarLite | Touch HD with Tp keyboard , capa screen (800x640) and Android would be perfect for me |
| 22:12.52 | StarLite | I'd pay 500 for it next to my plan |
| 22:13.04 | tmzt | cr2: for what? |
| 22:13.07 | StarLite | I would REALLY want such a phone :P |
| 22:13.12 | cr2 | StarLite: well, the main problem is the epson mddi config |
| 22:13.21 | StarLite | ? |
| 22:13.35 | cr2 | otherwise the HD is very similar to raph hardware-wise |
| 22:13.39 | lupine_85 | StarLite: I wouldn't. I'd pay £100 for it, and then only if I could scrape android off ;) |
| 22:13.41 | Untouchab1e | Hehe, StarLite, according to rumours of leaked HTC-info, a Touch HD "Pro" of sorts is going to be released soon. Possibly featuring ANdroid ^^ |
| 22:14.15 | cr2 | Untouchab1e: i find HD too big |
| 22:14.29 | StarLite | hehe Untouchab1e :P |
| 22:14.40 | StarLite | those rumours better start to be official stuff then :P |
| 22:14.50 | StarLite | or i'll be buying me an X1 or a TP :P |
| 22:14.53 | cr2 | Untouchab1e: i also have athena, which is really big :) |
| 22:15.03 | cr2 | but i don't use it as a phone |
| 22:15.04 | maejrep[w] | cr2: yeah but the navi cap sensor a) is all controlled onboard, so the data you get back is specific to the various areas of the navi, and b) isn't the full screen :D |
| 22:15.21 | Untouchab1e | I agree with the HD being slightly too big, but the Touch Pro suits me better |
| 22:15.37 | cr2 | maejrep[w]: i'm more concerned why the the raph TS so lame |
| 22:15.40 | AstainHellbring | StarLite you may wanna wait to buy a phone |
| 22:15.43 | maejrep[w] | lol |
| 22:15.51 | cr2 | is it really a wince fault, or the hw problem |
| 22:16.03 | Untouchab1e | speaking of the Touch Pro.. Is it possible that we would be able to make the navi work the same way i Android as in WinMo? |
| 22:16.04 | *** join/#htc-linux gladiac (n=gladiac@milliways.cynapses.org) |
| 22:16.07 | AstainHellbring | StarLite new phones from htc will be tegra |
| 22:16.16 | maejrep[w] | Untouchab1e: in what sense? |
| 22:16.20 | gladiac | Hi |
| 22:16.29 | gladiac | ping QLandkarteGT :) |
| 22:16.31 | cr2 | Untouchab1e: why not ? it's the same hw |
| 22:16.51 | maejrep[w] | we would probably make it an event input with axes, like a joystick |
| 22:16.54 | cr2 | gladiac: availabe for arm ? |
| 22:17.10 | StarLite | when will they be released tho AstainHellbring? |
| 22:17.12 | maejrep[w] | and then the input driver can do whatever we want with that |
| 22:17.16 | gladiac | I'm looking for Oliver |
| 22:17.18 | StarLite | my Hermes won;t last another 2 months im afraid |
| 22:17.24 | *** join/#htc-linux MethoS (n=lem@host-091-096-212-148.ewe-ip-backbone.de) |
| 22:17.31 | maejrep[w] | ie, when left_area's y coordinate is in the to half, make a left button press act as Home :p |
| 22:17.33 | gladiac | cr2: QLandkarteM, yep |
| 22:17.35 | cr2 | gladiac: too late |
| 22:17.40 | maejrep[w] | s/to half/top half/ |
| 22:17.48 | *** join/#htc-linux addman3333 (n=azachars@nat/sun/x-49e19c8a591cdd3c) |
| 22:17.57 | StarLite | those phones from the leaked pics on that forum prolly wont be released for like 6 months im afraid |
| 22:18.05 | Untouchab1e | Would we also be able to make it light up on notifcations, etc? |
| 22:18.24 | cr2 | light up ? |
| 22:18.27 | maejrep[w] | yes |
| 22:18.32 | maejrep[w] | but that's the LED control |
| 22:18.34 | Untouchab1e | I have no idea how that is handled in WinMo, so thats why I am asking if it would be possible in an Android port |
| 22:18.34 | maejrep[w] | not the navi |
| 22:18.59 | cr2 | Untouchab1e: everything that the hw can, can be added to the software |
| 22:19.01 | maejrep[w] | the navi has 4 LEDs around the center "ring" which can be various luminosity |
| 22:19.14 | XD | so whats a good backup prog |
| 22:19.16 | XD | for apps |
| 22:19.20 | Untouchab1e | So it shoulndt be that big a problem getting te LED working then |
| 22:19.33 | XD | and contacts |
| 22:19.44 | cr2 | Untouchab1e: once we have a working driver |
| 22:19.45 | maejrep[w] | no it shouldn't be |
| 22:19.48 | Untouchab1e | Cool |
| 22:19.49 | maejrep[w] | ^ what he said |
| 22:20.09 | *** join/#htc-linux RZK333 (n=rzk@daemonet.ru) |
| 22:20.35 | Untouchab1e | Btw, I have uploaded a new package consisting of Balsats zImage for the Diamond. Could anyone just quickly test it and confirm it works? Have made a mess on the forums already :) |
| 22:20.35 | Untouchab1e | http://connect-utb.com/index.php?option=com_jdownloads&Itemid=58&task=viewcategory&catid=5 |
| 22:20.36 | maejrep[w] | the way WM does the ring LED is it varies the brightness of each of the 4 LEDs to make it "breathe" from bottom to top, go in a ring like an Xbox, etc |
| 22:20.38 | Untouchab1e | (brb) |
| 22:20.42 | maejrep[w] | so we can control it to do the same thing |
| 22:20.52 | Untouchab1e | maejrep, would have been awesome |
| 22:21.02 | maejrep[w] | would have been? |
| 22:21.07 | maejrep[w] | if what? |
| 22:21.13 | Untouchab1e | the G1's old fashioned green led just cant compete |
| 22:21.27 | Untouchab1e | Would be awesome if we got the LED working in Android as it does in WinMo |
| 22:21.28 | maejrep[w] | ah you mean if they made raph the g1? ;p |
| 22:21.30 | cr2 | hehe |
| 22:21.47 | maejrep[w] | I don't see why we can't .. in fact we can make it do all sorts of things that the windows driver doesn't do |
| 22:21.48 | cr2 | i have 7 color leds on nc10 |
| 22:22.04 | StarLite | I think most people would rather have working calling functionality first tho Untouchab1e ;) |
| 22:22.08 | StarLite | but I agree |
| 22:22.08 | Untouchab1e | haha, off course |
| 22:22.13 | maejrep[w] | that's funny |
| 22:22.16 | StarLite | the led thing is nice on the TP |
| 22:22.29 | cr2 | has somebody tried the rpc/sound ? |
| 22:22.30 | maejrep[w] | I'm thinking first getting actual hardware to work :p then will work on smd (calling) :p |
| 22:22.34 | Untouchab1e | Got to make a phonecall, brb.. If somone with a DIAM100 could just test the package i linked to and confirm it works, I would be greatfull (so that I know it works when people on teh forums are having problems) |
| 22:22.36 | maejrep[w] | not i |
| 22:23.19 | cr2 | maejrep[w]: it's too high-level for me |
| 22:23.27 | maejrep[w] | what is? |
| 22:23.35 | maejrep[w] | smd? |
| 22:23.35 | cr2 | rpc |
| 22:23.37 | maejrep[w] | oh |
| 22:23.48 | cr2 | smd layout should be fixed properly |
| 22:23.58 | cr2 | and proc_comm_dex |
| 22:24.00 | cr2 | and clk api |
| 22:24.12 | maejrep[w] | yes, but it needs to basically mix the vogue code with our code so that it works on both raph100 and raph800 :/ |
| 22:24.17 | cr2 | everything that g1 has broken ;) |
| 22:24.18 | maejrep[w] | not as easy as it sounds (for me) |
| 22:24.40 | cr2 | maejrep[w]: hardcoded offsets are bad |
| 22:24.53 | maejrep[w] | agreed, but what do you propose? :P |
| 22:24.59 | maejrep[w] | I don't think it can be detected |
| 22:25.14 | maejrep[w] | unless we probe different areas to see if it might be correct |
| 22:25.21 | cr2 | it can be disassembled |
| 22:25.32 | maejrep[w] | what can? |
| 22:25.42 | cr2 | it's very easy to probe, actually |
| 22:25.48 | maejrep[w] | if the arm9 is looking at that address, that's what we have to use, no? |
| 22:26.00 | cr2 | because each area start with a typical header |
| 22:26.02 | maejrep[w] | what, search for "CSQ" in smem? :D |
| 22:26.05 | maejrep[w] | not on raph800 :| |
| 22:26.14 | *** part/#htc-linux yoyey1 (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:26.17 | maejrep[w] | raph800 does not have a header for smd0 |
| 22:26.33 | maejrep[w] | raph800's smd is just like vogue's |
| 22:26.44 | AstainHellbring | bbiab time to go home |
| 22:26.56 | cr2 | header!= text |
| 22:27.05 | maejrep[w] | I know |
| 22:27.25 | maejrep[w] | but the header only contains head and tail offsets from within the AT RX/TX buffers |
| 22:27.30 | maejrep[w] | not the actual location of that buffer |
| 22:27.32 | cr2 | it's the flags+2pointers |
| 22:27.44 | maejrep[w] | not on raph800 :X afaik |
| 22:27.48 | cr2 | flags are easy to detect |
| 22:27.56 | cr2 | it is |
| 22:27.56 | maejrep[w] | I only saw head and tail offsets |
| 22:28.08 | cr2 | that's how we looked for them oin kaiser |
| 22:28.23 | maejrep[w] | hmm, what does the flag look like? |
| 22:28.47 | cr2 | 0x20000000 after the empty space |
| 22:28.51 | cr2 | usually. |
| 22:29.06 | maejrep[w] | basically I'm wanting to make smd.c do its probing like usual, and only look for the weird buffers if smd0 isn't auto detected by header |
| 22:29.17 | cr2 | dump the 0x1f area |
| 22:29.33 | maejrep[w] | i have |
| 22:29.40 | *** join/#htc-linux yoyey1 (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:30.01 | cr2 | there must be some array at a fixed place, where these offsets are stored |
| 22:30.20 | cr2 | like it's on g1 |
| 22:30.38 | maejrep[w] | k i'll dig deeper on that |
| 22:30.41 | cr2 | but with a different layout probably |
| 22:31.14 | maejrep[w] | it's kind of weird cause vogue doesn't probe and allocate it, it only allocates the struct on _open |
| 22:31.14 | cr2 | it'd all be in the 0x1f area |
| 22:31.30 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 22:31.31 | *** part/#htc-linux yoyey1 (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 22:31.37 | maejrep[w] | will definitely try to find an elegant way to probe it if we can |
| 22:31.47 | cr2 | vogue is a very clever hack |
| 22:31.54 | maejrep[w] | i was just under the impression that it couldn't be probed because its just not easy to identify programmatically |
| 22:31.54 | cr2 | but still a hack |
| 22:32.04 | maejrep[w] | its definitely easy to spot visually |
| 22:32.09 | maejrep[w] | but that's not what counts :) |
| 22:32.16 | cr2 | yeah |
| 22:32.30 | maejrep[w] | but yeah I agree probing it would be the best way |
| 22:32.51 | maejrep[w] | and only if smd0 is not found during the current probe, since that works currently on raph100 :p |
| 22:33.17 | cr2 | since they are ioremaped, there must be the offset array... |
| 22:33.40 | cr2 | and the SMD channel names are stored at the 0x1f beginning |
| 22:33.45 | maejrep[w] | you don't think the WM kernel or smem driver just has them hard coded? |
| 22:33.49 | maejrep[w] | it hard codes everything else :P |
| 22:33.52 | cr2 | with some bnary data behind |
| 22:34.01 | *** part/#htc-linux gladiac (n=gladiac@milliways.cynapses.org) |
| 22:34.02 | maejrep[w] | yes, I saw that, but again that doesn't exist for raph800 or vogue :x |
| 22:34.13 | cr2 | no, because i've looked at smd.dll |
| 22:34.14 | maejrep[w] | it finds other channels, but not SMD0 (which raph100 calls "DS") |
| 22:35.02 | cr2 | strange |
| 22:38.02 | cr2 | where is the tiacx source ? |
| 22:40.00 | lupine_85 | 29896 lupine 20 0 437m 277m 156m R 97 13.9 0:46.18 git-rev-list |
| 22:40.14 | lupine_85 | git is insane |
| 22:42.30 | *** join/#htc-linux Rogro82 (n=rogro82@s5591104d.adsl.wanadoo.nl) |
| 22:44.12 | Untouchab1e | back |
| 22:47.17 | lupine_85 | wonders if dcores, tmzt, netripper, j0b0, cr2, etc would like a trac |
| 22:51.15 | *** part/#htc-linux famast (n=amast@host-208-68-238-61.biznesshosting.net) |
| 22:57.00 | lupine_85 | I guess I should take that as a no? :p |
| 23:04.32 | maejrep[w] | lupine_85: i don't think any of them are active :p |
| 23:05.33 | lupine_85 | they've been highlighted now, so no excuse :D |
| 23:05.44 | lupine_85 | (when they get back) |
| 23:06.57 | cr2 | maejrep[w]: http://wiki.xda-developers.com/index.php?pagename=MSM_VREG |
| 23:07.20 | cr2 | G1 VREGs |
| 23:08.09 | cr2 | now you can see the masks |
| 23:10.06 | cr2 | the only thing i'd like to know is the voltage units |
| 23:11.37 | *** join/#htc-linux zycho (n=zycho@a89-182-29-133.net-htp.de) |
| 23:11.48 | maejrep[w] | cr2: does that mask have to be OR'ed with the existing value? I'd assume not since proc comm doesn't really give us access to current values |
| 23:11.50 | cr2 | because raph800 uses different voltages and sources for the lcd |
| 23:12.18 | cr2 | the mask is a parameter |
| 23:12.37 | cr2 | aT LEAST FOr the vreg_switch |
| 23:12.57 | cr2 | need to check more for the vreg_level |
| 23:13.12 | maejrep[w] | right, so we only need to pass the single parameter, not ORed with anything |
| 23:13.23 | maejrep[w] | can we combine two calls into one by ORing the values? |
| 23:14.57 | cr2 | don't think so |
| 23:15.26 | cr2 | you can also check your traced values |
| 23:15.27 | maejrep[w] | k, I don't think the camera or SD do that |
| 23:15.31 | maejrep[w] | right |
| 23:15.41 | maejrep[w] | camera sends two separate commands |
| 23:15.50 | cr2 | we need some more crossreferences between the pages |
| 23:16.12 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 23:16.19 | maejrep[w] | like a [TOC] :p |
| 23:16.48 | cr2 | there are some really strange things there |
| 23:16.52 | maejrep[w] | so cr2 you think these are ready to be used? or are there any bugs or unexpected results we might see? |
| 23:17.06 | cr2 | the gp6 aka BT is used to power the SD :) |
| 23:17.18 | maejrep[w] | o.0 |
| 23:17.31 | maejrep[w] | and mmc powers wifi iirc |
| 23:17.33 | cr2 | and mmc for wifi |
| 23:17.36 | cr2 | on g1 |
| 23:17.36 | maejrep[w] | :p |
| 23:17.53 | cr2 | but on titan the mmc is used for SD |
| 23:17.55 | cr2 | no wifi |
| 23:18.48 | cr2 | it probably depends on the controller port |
| 23:19.10 | cr2 | that's why i need such SD controller usage table |
| 23:19.33 | maejrep[w] | what do you want me to try first? :p ie, do we need to setup the sd card to use it? it works currently, but is that only because its already setup from windows? |
| 23:19.36 | cr2 | maejrep[w]: i've done my best, and it looks good for me. but ymmv |
| 23:20.05 | cr2 | sd works on raph ? |
| 23:20.11 | maejrep[w] | yes |
| 23:20.15 | maejrep[w] | sd card that is |
| 23:20.18 | cr2 | strange :) |
| 23:20.25 | maejrep[w] | why strange? |
| 23:20.36 | cr2 | the sd clock setup is so convoluted |
| 23:20.56 | maejrep[w] | it works with lavender's patch to sdcc |
| 23:21.29 | cr2 | that should be done properly some time |
| 23:21.49 | maejrep[w] | i can give it a shot but last time I touched the sdcc code, it blew up :) |
| 23:21.51 | cr2 | it should be the sane clock api, not the hardcoded table |
| 23:22.08 | cr2 | what else can we check ? |
| 23:24.56 | cr2 | you can't check lcd, because you have different values |
| 23:25.32 | maejrep[w] | wifi? :P |
| 23:25.43 | cr2 | why not :) |
| 23:25.46 | AstainHellbring | phone? |
| 23:25.53 | cr2 | remove the power |
| 23:26.19 | cr2 | you can't check powerup, because we don't have the driver |
| 23:26.44 | cr2 | for wifi |
| 23:27.05 | cr2 | and there is no port matrix |
| 23:27.28 | maejrep[w] | so what would I see if I remove power? |
| 23:27.31 | maejrep[w] | you mean in linux right? |
| 23:27.48 | maejrep[w] | wouldn't want to send random proc comm commands in windows ;) |
| 23:27.52 | cr2 | hmm |
| 23:28.15 | cr2 | lcd will be the best |
| 23:28.25 | maejrep[w] | to power it off? |
| 23:28.32 | cr2 | but i don't have your values on the list |
| 23:28.33 | maejrep[w] | but won't work on 800, right? |
| 23:28.49 | maejrep[w] | can I just trace turning lcd on and off? |
| 23:28.56 | maejrep[w] | didn't I already add that to the pcom page? |
| 23:28.59 | cr2 | try to disable the 'a' |
| 23:29.07 | cr2 | hmm |
| 23:29.25 | maejrep[w] | <PROTECTED> |
| 23:29.26 | maejrep[w] | <PROTECTED> |
| 23:29.34 | maejrep[w] | I added one of those I think |
| 23:29.36 | maejrep[w] | not sure which |
| 23:29.51 | cr2 | which wince ids are that ? |
| 23:30.04 | maejrep[w] | 0x15, 0x16 ? |
| 23:30.07 | maejrep[w] | pcom |
| 23:30.30 | cr2 | 0x4000 is SYNT |
| 23:30.58 | cr2 | 0x400000 is AUX2 aka gp5 |
| 23:31.15 | maejrep[w] | i think thats what i get when turning off the lcd |
| 23:32.20 | cr2 | 'a' and 8 |
| 23:32.47 | cr2 | raph100 has 'a' 'b' and 4 |
| 23:33.37 | cr2 | so send the kill to a and 8 (your masks) |
| 23:34.52 | lupine_85 | win 2 |
| 23:41.51 | maejrep[w] | cr2: so you mean in linux, send 'a' and 8 to the vreg_off command, and see if it turns off the display? |
| 23:50.48 | cr2 | yes |
| 23:51.05 | maejrep[w] | k i'll add that to my todo list :P |
| 23:51.33 | lupine_85 | fails generically at creating a git:// repo |
| 23:52.05 | maejrep[w] | i've never touched git except to checkout ;x |
| 23:52.29 | lupine_85 | linuxtogo git is so slow |
| 23:52.34 | lupine_85 | I can't cope :D |
| 23:52.42 | lupine_85 | so I shall has my own |
| 23:52.57 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 23:53.12 | lupine_85 | (need it for the autobuilding anyway, might as well export it via git://) |
| 23:54.19 | cr2 | lupine_85: where is the tiacx source ? |
| 23:54.33 | lupine_85 | I don't know |
| 23:55.01 | maejrep[w] | http://acx100.sourceforge.net/ |
| 23:55.02 | maejrep[w] | :D |
| 23:55.22 | maejrep[w] | going home |
| 23:56.08 | lupine_85 | woo :) |
| 23:56.45 | lupine_85 | humm, still with the broken |
| 23:57.23 | cr2 | not this one ? |
| 23:58.08 | lupine_85 | (git://) |
