IRC log for #htc-linux on 20091017

00:12.38*** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey)
00:14.21*** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring)
00:30.42*** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl)
01:01.05*** join/#htc-linux x29a_ (n=x29a@unaffiliated/x29a)
01:12.28*** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring)
01:19.41*** join/#htc-linux mdrobnak_ (n=mdrobnak@ool-457e706e.dyn.optonline.net)
01:20.01mdrobnak_tmzt: You here?
01:27.11mdrobnak_ok, gotta run. I am going to try the latest dzo rootfs.img...Word of warning to those using mine - dont hit a key to backup. it hosed my data.img :-(
01:27.18mdrobnak_Gotta remove that code.
01:27.24mdrobnak_Off to the movies :-)
01:58.56tmztmdrobnak: yeah
02:03.15*** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey)
02:10.52*** join/#htc-linux ppman (n=mkern@pool-71-250-13-156.nwrknj.east.verizon.net)
02:10.59ppmanjust got my raphael today
02:11.10ppmanthat is one hell of a phone!
02:19.48*** join/#htc-linux Abracadabra (n=Abracada@unaffiliated/abracadabra)
02:26.37*** join/#htc-linux Perkka (n=perkka@ua-83-227-207-92.cust.bredbandsbolaget.se)
02:38.34*** join/#htc-linux dzo_ (n=dzo@mail.marginz.co.nz)
02:43.24*** join/#htc-linux ppman_ (n=mkern@pool-70-111-244-91.nwrk.east.verizon.net)
02:45.20*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
02:49.24*** join/#htc-linux g55 (n=g55@93.135.219.215)
02:53.42*** join/#htc-linux alexandernst (n=alexande@212.183.198.145)
03:01.01tmztppman_: hey, which one?
03:01.42*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
03:12.00tmztAstainHellbring: ping
03:12.11tmzt<PROTECTED>
03:12.11tmzt<PROTECTED>
03:12.11tmzt-       max_irq = (machine_is_htcraphael_cdma() || machine_is_htcdiamond_cdma())
03:12.15tmzt+       max_irq = (machine_is_htcraphael_cdma() || machine_is_htcraphael_cdma500
03:12.18tmztplease add that to smd.c
03:13.50ppman_tmzt: raph110... htc FUZE
03:13.55tmztcool
03:14.00tmztwhat did you pay?
03:14.04ppman_$200
03:14.09tmztok
03:14.17tmztnot from at&t?
03:14.21ppman_used
03:14.26tmztright
03:14.31tmztstill good for vga though
03:14.37ppman_the last guy scratched up the screen a little,
03:14.43AstainHellbringahh tmzt I dont have a build env anymore
03:14.47ppman_but at least he left it with a ton of cool software
03:15.16ppman_oh yeah, and gps won't even work in winmo
03:15.25ppman_but apparently that's common
03:15.27tmztno, it won't
03:15.36tmztI think I found the instructions to fix it though, on the pre site
03:15.43tmztit should be the same
03:15.51tmztI'm working on some that don't require QPST
03:16.01tmztnot quite the same
03:16.14tmztand you would have to have diag access which might be missing on fuze
03:16.58ppman_QPST?
03:17.55tmztqualcomm tool
03:20.07ppmanI really want to get started with linux on this thing..
03:20.32ppmanI'm thinking of using the sd card I had on my kaiser for now and buying a replacement for kaiser.
03:20.44tmztppman: are you in #ofono?
03:20.51tmztsure
03:21.04ppmanno... anything good happening there?
03:21.07tmztandroid or something else? I though you mentioned you wanted to work on a driver for raph100
03:21.19tmztjoin, denkinz is there now
03:21.24ppmanI want to get mer up to coolness
03:21.44tmztwell, we need a gsm stack and it looks like that's the one maemo will be using at some point
03:21.55tmztthere's still the option of using fso an fsogsmd
03:22.37ppmanwell, we want to follow the mer guys... make it easy for ourselves.
03:26.31*** join/#htc-linux dilinger (n=dilinger@wireless.queued.net)
03:33.50ppmanum... am I supposed to get 17.3MB/s from a class 2 microsd card?
03:38.09*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
04:00.10*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
04:03.27*** join/#htc-linux NexVision (n=a@c-76-109-33-88.hsd1.fl.comcast.net)
04:09.51*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
04:28.51*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
04:37.55*** join/#htc-linux dzo (n=dzo@121.98.128.127)
05:00.11*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
05:01.09*** join/#htc-linux droid001 (n=g1@p4FDCF3ED.dip.t-dialin.net)
05:22.08*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
05:25.37*** join/#htc-linux evildarknight (n=charles@41.211.74.250)
05:43.38*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
06:23.55*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
06:37.05*** join/#htc-linux CZero (n=CZero@87-194-204-58.bethere.co.uk)
06:49.39*** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz)
07:06.02tmztwelcome, goodnight
07:06.37CZero:)
07:19.17*** join/#htc-linux x29a (n=x29a@unaffiliated/x29a)
07:35.05*** join/#htc-linux alexandernst (n=alexande@212.183.198.145.dyn.user.ono.com)
07:36.39*** join/#htc-linux luc (n=luc@89-115-128-35.cl.ipv4ilink.net)
07:45.22*** join/#htc-linux DasFx (n=John@535482D5.cable.casema.nl)
08:23.38kri5Hi there
08:23.45tmzthello
08:53.33*** join/#htc-linux Gnutoo (n=gnutoo@host93-155-dynamic.51-79-r.retail.telecomitalia.it)
09:18.30*** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes)
09:27.40*** join/#htc-linux Zinbolic (n=zinbolic@84.238.80.215)
09:33.13tmztmdrobnak: do you have raph110 keymap somewhere?
09:35.24swc|666tmzt, thx btw from last night
09:35.32tmzt?
09:35.43swc|666meant to say thx to u last night
09:35.49swc|666then ctrl+d
09:36.08swc|666i asked a question about something and saw u answered 1 min b4
09:36.11swc|666lol
09:36.38swc|666tmzt,
09:36.38tmztah
09:36.38tmztjust forget what it was
09:36.49tmztmdrobnak: please forward to Jason8 or |Jason8|
09:36.49swc|666does the new wlxx driver work for ti acx100 ?
09:36.56tmztit should
09:37.03tmztbut we don't know how yet
09:37.08tmztand it might need some work
09:37.08swc|666on what stack is that btw... mac80211?
09:37.11tmztyes
09:37.14swc|666nice
09:37.22swc|666tmzt, hmm
09:37.26swc|666how about for the uni
09:37.34tmztthe pcmcia one?
09:37.41tmztyou would have to write a new if_ at least
09:37.45swc|666uni has tiacx, 16 bit slave mem tho
09:37.50swc|666not sdiio
09:37.53swc|666-i
09:38.05*** join/#htc-linux FR^2 (i=frr@frquadrat.de)
09:38.08swc|666yea
09:38.12swc|666hmm
09:39.39swc|666i have some patches from a while ago, from sameo @ ohand iirc
09:40.23swc|666its been a while since i've done real c, but i might try and adapt the wl driver for the uni and the ba
09:41.05swc|666tmzt, does par still have all of those ba's btw?
09:41.32tmztI think
10:08.03*** join/#htc-linux kvaster (n=kvaster@live.bn.by)
10:16.36*** join/#htc-linux thedicemaster (n=thedicem@j89051.upc-j.chello.nl)
10:17.10*** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl)
10:17.42*** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo)
10:19.28*** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl)
10:27.35*** join/#htc-linux pleemans (n=toi@d54C2A96D.access.telenet.be)
10:30.38DJWillisswc|666: WL12xx will need some work for acx100 but it is VERY possible, that said, acx100 got some love recently I notice. For the mac80211 vairent anyway. There was a post to the Angstrom mailing list about fixing up the acx100 driver for the hp hx4700 (so not far off the BA).
10:32.32DJWillisswc|666: wl12xx has layers for SPI and SDIO so that should not give you any issues (the n900 uses SPI for it's WL1251 so nokia wrote the driver to support that ;-))
10:34.32*** join/#htc-linux NexVision (n=a@c-76-109-33-88.hsd1.fl.comcast.net)
10:39.23DJWillisswc|666: http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2009-October/003494.html for info on the acx100 love.
10:40.26*** join/#htc-linux sd00 (n=smac@82-39-194-231.cable.ubr02.jarr.blueyonder.co.uk)
10:42.52*** join/#htc-linux luc_ (n=luc@89.115.128.35)
10:48.01*** join/#htc-linux GlemSom (n=glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk)
11:07.54*** join/#htc-linux leaigor (n=laigor@188.134.16.241)
11:26.55*** join/#htc-linux DarkMasterHalo (n=DarkMast@modemcable070.63-56-74.mc.videotron.ca)
11:39.28*** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net)
11:42.40*** join/#htc-linux droid001 (n=g1@p4FDCC737.dip.t-dialin.net)
11:44.39*** join/#htc-linux MethoS- (n=clemens@134.102.106.250)
12:43.03*** join/#htc-linux dream_kill (n=nospam@92.56.53.50)
12:48.51*** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz)
12:58.02*** part/#htc-linux sd00 (n=smac@82-39-194-231.cable.ubr02.jarr.blueyonder.co.uk)
13:03.23*** join/#htc-linux Xyis (i=5772181c@gateway/web/freenode/x-tiqcjgqwtiujjdrm)
13:03.48Xyiswow, lots more people here than i expected. How its everyone?
13:04.39*** join/#htc-linux Xyis (i=5772181c@gateway/web/freenode/x-xxpknmhjodtigxyz)
13:05.40XyisOut of interest, anyone on Google Wave here?
13:06.47phhnot really related to the chan ?
13:07.25XyisWell i ask as i was wondering if someone wanted to help me make a htc-linux wave.
13:10.58XyisOh well, Just a quick question, i am going to attempt to put android on my Raph, will i need a linux machine to compile anything?
13:12.48phhonly if you want to debug
13:16.18Xyisokay, thanks, i'll look into it. I read the wiki briefly it looks complicated, if i go over it enough is everyhing i need to know to get running on there?
13:16.41phhthere is nothing complicated
13:17.07phhjust grab an android build, check the xda's forum to find one, extract it on a sdcard
13:17.10phhand that's it
13:17.58XyisDont i have to get haret installed?
13:19.44phhmost of the time it's in the build
13:20.24XyisBrilliant, sounds easier than flashing a rom :) Thanks for the infor, i know n00bs like me can be annoying. So much appreciated.
13:22.13phhit's easier to debug :p
13:39.36alexandernstWhat are the bad things about the HTC Touch Pro 2 Vario V (if there are bad things)? I red that this is a T-Mobile phone version.
13:42.57*** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl)
14:04.46*** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it)
14:15.25*** join/#htc-linux [1]Captnoord (n=Captnoor@81.71.164.123)
14:44.50*** join/#htc-linux tuxhero (n=tuxhero@122.169.157.97)
14:59.25*** join/#htc-linux jack_baumer (n=jack_bau@dslb-088-065-048-172.pools.arcor-ip.net)
15:00.10*** part/#htc-linux jack_baumer (n=jack_bau@dslb-088-065-048-172.pools.arcor-ip.net)
15:11.07*** join/#htc-linux jack_baumer (n=jack_bau@dslb-088-065-048-172.pools.arcor-ip.net)
15:13.37*** join/#htc-linux tuxhero_ (n=tuxhero@122.169.169.172)
15:30.47*** join/#htc-linux dcordes (n=dcordes_@unaffiliated/dcordes)
15:32.12*** join/#htc-linux balsat (n=kll@87.72.13.87)
15:41.51*** join/#htc-linux Hellgringo (n=holger@p3EE01AD9.dip0.t-ipconnect.de)
15:43.03Hellgringohello, i tried a android build on my HTC Diamond
15:43.54Hellgringothe device booted up the linux kernel .... and so on
15:44.29Hellgringobut now i can't execute the haret.exe
15:44.57Hellgringowindows says that it is broken or the certificate isn't correct
15:45.08Hellgringoreinstalling harte.exe doesn't change anything
15:45.25Hellgringohas somone an idea, what the problem might be?
15:50.45*** join/#htc-linux Bry8Star_ (n=Bry8Star@adsl-99-32-0-250.dsl.lsan03.sbcglobal.net)
15:58.28Hellgringono idea?
16:03.34*** join/#htc-linux Marajin (n=marajin@87-194-102-189.bethere.co.uk)
16:12.18*** join/#htc-linux DarkMasterHalo (n=DarkMast@modemcable070.63-56-74.mc.videotron.ca)
16:24.08*** join/#htc-linux Gnutoo (n=gnutoo@host93-155-dynamic.51-79-r.retail.telecomitalia.it)
16:46.57*** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey)
16:48.52*** join/#htc-linux balans (n=balans@212-123-149-239.ip.telfort.nl)
17:24.31*** join/#htc-linux pleemans (n=toi@d54C2A96D.access.telenet.be)
17:34.29*** join/#htc-linux pH5 (n=user@g229228210.adsl.alicedsl.de)
17:36.19*** join/#htc-linux Epsylon3 (i=kvirc@85-170-22-251.rev.numericable.fr)
17:36.30Epsylon3hi
17:37.23Epsylon3i have a battery problem with my kaiser, even fully charged (and tested with new one) Windows tell me Battery is low, then shutdown...
17:37.54Jason8...this is #htc-linux
17:38.03Epsylon3i had this problem since a few months, and worked again last week..... i installed android on
17:38.10Epsylon3i come...
17:38.25Epsylon3so i was able to boot android with haret
17:38.35Jason8yep.
17:38.50Epsylon3the problem... i dont have time to launch it
17:39.02Epsylon3and dont have time to change registry too...
17:39.10Epsylon3to place it at startup
17:39.10Jason8Try a hard-reset?
17:39.34Epsylon3it doesnt work... tried the 2 "menus" buttons method
17:39.54Epsylon3and i fear to flash with the battery problem
17:40.00Epsylon3a big image
17:40.20dcordesEpsylon3, #xda-devs might be better help for hard resetting kaiser questions
17:40.25Jason8hold those two softkeys, hit the soft-reset button with the stylus, and keep holding them until it asks you to push a button to continue
17:40.26Epsylon3so... is there a way to load kernel via sdcard at bootloader ?
17:40.48Epsylon3the zImage....
17:40.58Epsylon3i've seen something with IMAGE.BIN
17:41.12Epsylon3and INITRD.BIN
17:41.22dcordesEpsylon3, not yet
17:42.26Epsylon3ya ok, so the only way i have is to flash again the WM rom
17:42.40Epsylon3i tried the hard reset...
17:42.51Epsylon3maybe my spl is not compatible
17:43.00Epsylon3i've the 3.14
17:43.37dcordesplease discuss rom flashing in #xda-devs .
17:43.51Epsylon3yup... ok
17:43.53dcordesor even better use xda wiki
17:43.58Epsylon3i know how to do that
17:44.25Epsylon3kaisimg.nbh on sdcard and lets go
17:45.08Epsylon3is there a linux nbh ?
17:45.19Epsylon3os.nb
17:45.31dcordesEpsylon3, again: not yet.
17:48.32*** join/#htc-linux dream_kill (n=nospam@92.56.53.50)
17:48.53Epsylon3ok ok... will try understand haret source
17:49.58dcordesEpsylon3, tmzt was looking into this
17:50.19Epsylon3and ?
17:51.08Epsylon3yea, will ask him thanks
17:51.10dcordesEpsylon3, you might talk to him if you want to help developing an msm bootloader
17:51.35Epsylon3ok, yep
17:53.07Epsylon3do you know if android htc devices also uses nbh system for updates ?
17:55.31dcordeshttps://www.codeaurora.org/patches/quic/le/
18:03.24phhdcordes: do you know anything about htc_battery ?
18:04.33Epsylon3ok i found the problem : "It's not just a question of the bootloader. There's some hardware initialization being done by WM that is still needed."
18:05.24Epsylon3ergh, i really need to set haret as default shell (like gps devices)
18:14.55Epsylon3erfg, even when i connect a stabilised 4.3VDC source in parallel to the battery, i've same problem... booting then shutdown on PIN code
18:18.01dcordesphh, no
18:19.55Epsylon3ahhh i'll maybe do it... i have some more seconds at 4,8VDC and usb powered
18:22.57*** join/#htc-linux audrysu (n=audrius@rrcs-71-43-112-220.se.biz.rr.com)
18:25.44*** join/#htc-linux pleemans (n=toi@d54C2A96D.access.telenet.be)
18:47.59*** join/#htc-linux thedicemaster (n=thedicem@24.132.89.51)
18:49.07*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
18:49.30Epsylon3made the hard reset, no luck.... same battery problem
18:50.36phhanyway to cycle the battery ?
18:50.46phh(meaning discharge it and charge it totally)
18:51.06Epsylon3i tested it yes, with a 0.5A 3.6V pocket lamp
18:51.37Epsylon3that works... 45mn later i disconnected it
18:52.10Gnutoodcordes, I default the kernel to 2.6.29 in oe for htcdream right? other branch are less advanced for GNU/Linux(not android)?
18:52.18Epsylon3my device had a water problem some month ago
18:52.48Epsylon3i think there is something bad with the battery sensor...
18:52.53dcordesGnutoo, htc-msm-2.6.29 branch yes
18:52.53Epsylon3or something like that
18:52.57phhmaybe try a new battery
18:53.14dcordesGnutoo, see how it's done for the other machines with the branch selection etc?
18:53.17Epsylon3i have a big one too, same problem
18:53.30phhEpsylon3: isn't your windows rom the problem ?
18:53.33Gnutoook because someone told me that everything worked in an older branch but I don't know who it was and if he was talking about android or GNU/Linux
18:53.44Epsylon3hmm maybe something like that yes
18:53.53Epsylon3i dont had this problem with Android
18:53.53Gnutoodcordes, I know how to do that
18:54.03dcordesok
18:54.09phhEpsylon3: then flash the stock one
18:54.21Epsylon3yeah, device is 2 years old :p
18:54.31phh... and ?
18:54.56Epsylon3dont know if i can find the old one... will try to flash another one yes
18:55.15Epsylon3or maybe the htc one
18:56.08Epsylon3i think its a problem with the battery driver (or sensor)
18:56.23phhthat's why you should try another ROM ...
18:56.27Epsylon3worked again a full week
18:56.34Epsylon3last week
18:57.55Epsylon3now all is erased i can do that sure....
18:58.33tmztcdma?
18:59.05tmzttry cleaning the contacts
18:59.32dcordestmzt, I think there's only gsm kaiser
18:59.41tmztyeah, they use nbh
18:59.43tmztwhy?
19:00.05Epsylon3to get the os.nb ;)
19:00.32tmztit was recommended we start with kaisdiag.nbh
19:00.40tmztI'm still looking in to that
19:01.00tmztif you know arm asm and what the "periphrial port remap register" is you could really help
19:01.02Epsylon3yea, like the diagnostic SD card
19:01.29Epsylon3i worked on mips router WRT54G some years ago
19:01.54Epsylon3and i'm coding Ollydbg Script plugin ;p
19:02.18Epsylon3and also made PIC assembler
19:02.22tmztEpsylon3: you could also use the early registry stuff (rgu) and #xda-devs should be able to help with that
19:02.31tmztif you do that use startup.txt instead of default.txt
19:02.46Epsylon3will autostart right ?
19:03.40Epsylon3rgu is a shell commands to write registry via usb ?
19:04.06tmztnot via usb, you put it in xip
19:04.37tmztcool, can you look at this, people.openezx.org/tmzt/green7.S
19:04.41tmztit's a very early start
19:04.59tmztother wise we can adapt Qi or uboot from qualcomm
19:05.23Epsylon3=)
19:05.55Epsylon3happy to know you, it's hard to find infos on xda forum
19:06.08Epsylon3for that
19:06.30tmztI don't know much about ce though, the people in #xda-devs, no2chem, cmonex, Olipro, TFGDB do
19:06.46tmztTFGBD
19:06.47Epsylon3the asm code directly access to GPIOs ?
19:06.55tmztsure, no reason why not
19:06.58Epsylon3write to vibra register
19:07.01tmztbut I'm using proc comm
19:07.08tmztthat's in the shared memory area
19:07.15tmztthe problem is none of it works booted from haret
19:07.31tmztand I don't understand how the haret trampoline works
19:07.51tmztsince mmu has to be off to boot linux
19:07.51Epsylon3was reading that in sources :p
19:07.51Epsylon3some minuts ago
19:08.35Epsylon3in linboot.cpp
19:08.43tmztyes
19:10.40Epsylon3i think its possible to force to free some app memory blocks...
19:10.56*** join/#htc-linux cr2 (n=cr2@ip-109-84-56-184.web.vodafone.de)
19:11.06Epsylon3but for a bootloader, i think we have almost all memory
19:11.41tmztwe do have all memory? what do you mean?
19:12.45tmztthat's just to ensure there's enough memory with physically contiguous mappings to boot
19:12.46Epsylon3under windows, there is many things loaded yea
19:13.13Epsylon3but on startup (before windows) all is free
19:13.13tmztright, but after linboot
19:13.25cr2hi
19:13.29tmztnot sure what you mean
19:13.42tmztit's just to prevent it writing over windows before Go Go Go
19:13.48tmztat which point ce is goine
19:13.49tmztgone
19:13.51*** join/#htc-linux Alex[sp3dev] (n=alex_dfr@ip-95-221-54-65.bb.netbynet.ru)
19:13.58cr2tmzt: it's not so easy to disable pmem. the adsp code needs to be fixed, and i fear that we may loose the sound ;)
19:14.18tmztdisable pmem?
19:14.20tmztah
19:14.24tmztwhy?
19:14.33cr2!android
19:14.55tmztI just mean we don't need the driver for userspace
19:14.55cr2btw, where is the framebuffer patch of Gnutoo ?
19:15.04tmztwe should be able to replace it with sg
19:15.06Gnutoocr2, in the git
19:15.07tmztGnutoo: ping
19:15.11tmzthey
19:15.13Gnutootmzt, hi
19:15.27Epsylon3i think firmwares are directly sent to other chips
19:15.38cr2Gnutoo: ok, then we need to update the defconfig, and do it the default
19:15.41tmztI don't see it
19:15.44Gnutoook
19:15.53tmztwhat patch?
19:15.58GnutooI don't know what you do with defconfigs...if you do android or GNU/Linux
19:16.05Gnutooso I didn't touched it
19:16.13cr2if somebody wants android, they should use android_defconfig
19:16.13Gnutooanyway I'm doing a defconfig for oe
19:16.17Gnutooah ok
19:16.47cr2tmzt: kernel doublebuffering
19:16.48tmztcr2: looks like android images will be built by somebody now
19:16.58tmztif we can get at least raph800 included
19:17.06tmztto disable it? we actually need it in X
19:17.13cr2tmzt: ?
19:17.20tmztI'm trying to adapt the s3c ddx to use it properly
19:17.23cr2why do you need pmem ?
19:17.32tmztwe don't need pmem
19:17.35tmztwe can mmap fb
19:17.59cr2yes. if we drop android from defconfig, we can purge a lot of crappy code
19:18.28tmztI mean there's someone who is here occassionally who is building zImage's for android
19:18.47tmztif Untouchable was using them, since people seem to like his userlands
19:18.53tmztwe could still support them
19:18.58Epsylon3(ok, understund the rgu way... something like the OEM stuff in tuned XP distros)
19:18.59*** join/#htc-linux Dayd (n=ddaydd@AToulouse-159-1-118-121.w92-129.abo.wanadoo.fr)
19:19.05tmztEpsylon3: yes
19:19.22Epsylon3yea, very nice way
19:19.34Epsylon3thanks for help, will try that
19:19.37cr2i don't really understand why there are multiple android images for each device.
19:19.37tmztcr2: what do you think about splitting out gpio defines from the board headers
19:19.46tmztand making RAPH100 the basic set of them
19:19.50Gnutoobtw I apoligize for the orthography
19:19.57tmztand then having BLAK100, etc. only were they differ
19:20.08tmztGnutoo: can I see this patch?
19:20.13Gnutootmzt, cr2 if you need explanations on the options just ask
19:20.21Gnutootmzt, which one?
19:20.37Alex[sp3dev]tmzt: a great idea.. so as not to duplicate code, right?
19:20.46tmztyes
19:20.47Gnutoorefresh(that is not from me),double-buffering,tslib ?
19:20.54tmztGnutoo: right
19:20.59Gnutoowhich one of the 3?
19:21.09tmztprobably double-buffering
19:21.17tmztif you have a clean msmts_raw though I would like that
19:21.39cr2tmzt: we can create some more generic names for gpios
19:21.43tmztby the way, I'm not using tslib anymore but evdev
19:22.03tmztcr2: I'm fine with RAPH100 like it is now, I just want the additional devics in the same header
19:22.15tmztso I can split the smi parts into smi32 and sim64
19:22.19tmztlike on sapp kernel
19:22.21cr2tmzt: as long as you don't peddle calibration into the kernel ;) it's all ok
19:22.22tmztand fix my board
19:22.27Alex[sp3dev]sorry, i haven't followed the discussion for about two weeks.. has anyone looked into fixind the ram on kovsky and others yet?
19:22.34Gnutootmzt, ok I'll send you the patch's url
19:22.42tmztcr2: X wants the min/max in kernel, but we can work around it using xinput
19:22.50cr2tmzt: i'd like to get rid of fixed allocations there.
19:22.57cr2as much as it is possible
19:22.57tmztI want the calibration routine out of the kernel
19:23.03cr2and move fbram into SMI
19:23.08Gnutootmzt, you don't want/need it for xorg/kdrive: http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=commit;h=d61ae9e6fd1616391f696cb662c388433891c426
19:23.19tmztit might make sense to have a separate tree for android with shared commits
19:23.26tmztsomething git or at least topgit can do
19:23.27Gnutoothe help says:
19:23.38GnutooAndroid relies on a double buffer to smoothly render page flips.Select this options if you use Android
19:23.45tmztcr2: I also want to use samsung version of mdp driver
19:23.49tmztbecause it makes more sense
19:23.57tmztthat means fixing the panel/client drivers as well
19:24.11cr2tmzt: codeaurora ? i want tvout
19:24.18cr2as fb1
19:24.18tmzteither way
19:24.28tmztdo we have a 2.6.27 version of it?
19:24.37cr2no
19:24.41tmztwell, I need to disable tv completely
19:24.53tmztmake it an option and adjust smi accordingly
19:25.02tmztbecause I only have 192mb total
19:25.08tmztminus 40+ for amss
19:25.22cr2option ?
19:25.31tmztwe can use the samsung version then
19:25.34cr2can't we found its location in nand ?
19:25.37tmztit has tvout and is based on ca
19:25.41tmztnand?
19:26.06cr2the "engineering" data is on nand
19:26.15tmztsure
19:26.21tmztcmonex knows where that is
19:26.27*** join/#htc-linux Abracadabr4 (n=Abracada@92.24.47.47)
19:27.13Gnutoobtw there is that in oe in ./conf/machine/include/htc-msm7.inc :
19:27.17GnutooPREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive"
19:27.17GnutooXSERVER = "xserver-kdrive-fbdev"
19:27.21Gnutoowhat about xorg
19:27.34GnutooI had to comment them for shr
19:27.39Gnutoobecause they use xorg
19:27.45tmzttalk to Weiss and Jama in #openmoko-cdevel
19:27.53tmztyes
19:28.04Gnutoome?
19:28.07tmztif ANDROID is going into the kernel as one option, which I would prefer not
19:28.16tmztplease keep it as a config ANDROID select ...
19:28.20tmztnot depends
19:28.24Gnutootmzt, talk to Weiss and Jama in #openmoko-cdevel was for me?
19:28.26cr2tmzt: ANDROID_PMEM is enough
19:28.35tmztalso, double-buffer should be a seperate issue from android
19:28.46tmztI need to be able to enable disable it completely seperately
19:28.48tmztGnutoo: yes
19:28.51Gnutootmzt, it's and android specific bit according to:
19:28.59Gnutoohttp://www.kandroid.org/android_pdk/display_drivers.html
19:29.01tmztit historical
19:29.09tmztfrom the emulator
19:29.16tmztit's wasted a year of our time :)
19:29.17GnutooI heard that double buffering can be done differently for kdrive/xorg
19:29.36Gnutootmzt, ok thanks
19:29.36tmztGnutoo: I would suggest looking at the new s3c6410 ddx
19:29.55Gnutootmzt, ok what's that?
19:30.01tmztg1 doesn't even use that method, it uses a gles driver for swap buffers
19:30.06Gnutooapart that s3c is a soc
19:30.08tmztdriver for Xorg
19:30.10cr2tmzt: i have seen a recent rpc bugfix in codeaurora
19:30.19Gnutoook so userspace xorg driver
19:30.25tmztright
19:30.35tmztusing vyres like the "android" one
19:30.37Gnutoook
19:30.39tmztit can be adapted
19:30.49Gnutoowhat should I do with this ddx driver?
19:30.50Gnutoook
19:31.11GnutooI'll go in #openmoko-cdevel to ask for the ./conf/machine/include/htc-msm7.inc
19:35.42tmztGnutoo: sorry, I mean I thought we had to disable the double buffering for X to work, but we should really fix instead. the method google used is pretty much standard for embedded framebuffers
19:36.07*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
19:36.16Gnutootmzt, ah ok sorry then...btw Xorg can work with it...just that it's not great because it breaks autodetection
19:36.27tmztwith?
19:36.38Gnutoowith the double buffering patch
19:36.41tmztthe solution is to put the driver in udev
19:36.46tmztuntil there's a better way
19:36.51tmztthat's why we need a custom ddx
19:37.09tmztI like the Mer way, keep everything generic but have per-device packages or sets of packages
19:37.15tmztthat customize certain things
19:37.20cr2hehe. ppp over adb. insane :)
19:37.25tmztI'm sure oe/shr is similar
19:37.44tmztcr2: can we use gadget instead of function in our new kernel?
19:38.02tmztcr2: I've tried it but I don't have phy setup right so detect no longer works
19:38.23Gnutootmzt, I use gadget
19:38.28Gnutoobut on GNU/Linux
19:38.29tmztyou do?
19:38.31tmzton 2.6.27?
19:38.35Gnutoo2.6.29
19:38.42tmzthow is that working for you?
19:38.53tmztshould we switch to it for X and leave 2.6.27 for android?
19:39.06tmztdo you have any of that wifi stuff patching core left in there?
19:39.10Gnutoofine
19:39.15tmztor is this a clean 2.6.29 from ca again?
19:39.32tmztokay, you can support raw msmts?
19:39.39tmztno calibration/vkeyb?
19:39.40Gnutooif you're talking to me for wifi I've not added wii
19:39.55tmztok, openmoko-msm is not you?
19:40.01Gnutoono
19:40.03tmztok
19:40.03Gnutooit's leviathan
19:40.04Gnutoo's
19:40.06tmztright
19:40.20tmztwl12xx does work with compat though?
19:40.21Gnutoobut replicant's kernel patches which just get merged was me
19:40.24Gnutooit works
19:40.36Gnutoojust that I was hacking on alsa...so I didn't have the time to try
19:40.37tmztnice, so I port raph500 to it it should work
19:40.45tmztwhen I get calibration
19:41.00tmztwhere is your tree ltg?
19:41.31GnutooI used tslib
19:41.31tmztwhose patches?
19:41.38Gnutooso calibration is in userspace
19:41.41tmztwifi calibration
19:41.42tmztI mean
19:41.44tmztright
19:41.58Gnutooah ok I thought you were talking about tslib
19:42.05GnutooI didn't try wifi at all so I don't know
19:42.13GnutooI didn't have time to try it
19:42.15tmztaer you on Xfbdev?
19:42.19tmztif not, try evdev
19:42.42tmztwait, this is on g1?
19:42.46tmztwe don't have rmi driver
19:43.02Gnutoolet's restart the conversation from scratch...I'm lost
19:43.09Gnutooso I've an htcdream
19:43.41tmztokay, I'm using a msm-single directory in drivers/video
19:43.41GnutooI've made 2 patch and 1 is not mine but was commited as beeing made by me(error from the commiter)
19:44.15Gnutooone patch is for having tslib for the synaptics_rmi driver
19:44.20Gnutoowhich the htcdream uses
19:44.34Gnutoothe second patch is for better xorg auto-detection
19:44.37tmztthe correct approach on double buffer seems to be to divide the fbram value by size of the screen in bytes
19:44.44tmztand determine the number of screens from there
19:44.53tmztlook at s3c6410 fb driver
19:44.58Gnutoook
19:45.17Gnutoothanks
19:45.24tmztit's not "auto detection" fbdev ddx will fail if the fbset fails to succeed by X's terms
19:45.39tmztokay, any reason we can't support wm device with this kernel?
19:46.01tmztwe should probably document are changes and create a patchset
19:46.07tmztbut that requires amss_ops
19:46.15Epsylon3android 2.0 : http://www.boygeniusreport.com/2009/10/16/android-2-0-screenshot-walkthrough/
19:46.16tmztcr2: have you though about what that might look like?
19:46.23tmztEpsylon3: it's not 2.0
19:46.32Epsylon3oh ?
19:46.32*** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net)
19:46.49tmztctate in #android says there is no offical release number for eclair
19:47.17tmztcr2: amss_ops I mean
19:47.39tmztwe should drop all ifdef's on machine where possible
19:47.40Epsylon3ok, could be a 1.8 or something
19:47.51tmztEpsylon3: could be, but as I said, there's no official number
19:48.19balsat000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
19:48.20cr2tmzt: what about rpc numbers and versions and parameters ?
19:48.42tmztkeep the separate .o's for amss
19:49.03tmztbut have a per board declration of which is used
19:49.17cr2it's per-amss
19:49.18tmztborrow the infrastructure from pxa that google refused to use
19:49.21cr2not per-board
19:49.28tmztset_whatever_pdata
19:49.37tmztyes
19:49.42tmztsorry
19:49.55tmztI mean you need amss_xxxx.o in qdsp5/
19:50.02tmztas well as board-amss-xxxx.o in msm/
19:50.13cr2not really
19:50.24cr2amss version is shared by many boards
19:50.26tmztit will setup amss_ops for things like gpios and proc_comm
19:50.40tmztyes, the file name is board-amss-$(VERSION)
19:50.42cr2gpios are per-board
19:50.48tmztnot htcraphael-amss-$(VERSION)
19:51.02tmztbut the method of using gpios is per amss, isn't it?
19:51.07cr2no
19:51.16tmztamss->set_gpio_value(nr, value)
19:51.25cr2why amss ?
19:51.27tmztamss->msm_set_gpio_function(nr, func)
19:51.36tmztbecause that's where ce and g1 differ
19:51.44cr2blac100 and raph100 has the same amss, but the gpios are differemnt
19:51.52tmztso you have
19:52.05tmztconfig CONFIG_MACH_HTCDIAMOND
19:52.16tmzt' select CONFIG_AMSS_6250 or whatever
19:52.21*** join/#htc-linux rayman18 (i=opera@36.pool85-49-144.dynamic.orange.es)
19:52.26tmztthe way google did it is wrong
19:52.30tmztthat should have been a select
19:52.34tmztnot a depends
19:52.35cr2diamond does not support multiple amss
19:52.47cr2unless you 'd like to merge cdma
19:52.51tmztselect keyword selects one of them
19:53.10tmztwe can only merge cdma when smi infrastructure is in place
19:53.29tmztI mean the Kconfig select keyword selects a particular config option
19:53.30cr2smi has nothing to do with cdma
19:53.38mdrobnakHey everyone.
19:53.39cr2in principle
19:53.41tmztit does for raph500, I need smi64
19:53.58cr2it's just board-raph500 specific setting
19:54.01tmztI mean we can't merge the boards until the defines are renamed SMI32_whatever
19:54.02*** join/#htc-linux Abracadabr4 (n=Abracada@92.24.47.47)
19:54.12tmztnot if there is a conflict in the pre processor
19:54.16cr2they could have created a device with 256+smi64
19:54.27tmztsure
19:54.41tmztanyway
19:54.42mdrobnaktmzt: You wanted Raph110 keyboard map for console?
19:54.47tmztthis fixes the proc_comm_wince
19:54.56tmztwe do use the correct structure now right?
19:55.02tmztmdrobnak: yes, can we please collect those
19:55.14mdrobnaktmzt: http://www.drobnak.com/raph110.kmap.gz
19:55.16tmztgive it dcordes so he can put on ~lgorris ?
19:55.23tmztok
19:55.50tmztdcordes: can you put a copy on ~lgorris
19:56.00tmztdcordes: I will help collect the linux and android versions
19:56.01cr2tmzt: how much ram does ADSP and MDP need ?
19:56.13tmztminimum? I think mdp can use two screens
19:56.25tmztthere's no way adsp needs 8mb
19:56.40cr2tmzt: they use 10MB now ;)
19:56.45tmztI can't tell you what amss wants though
19:56.51cr2for jpeg encoding or so
19:56.55tmztyeah
19:57.08cr2#define MSM_FB_SIZE             0x200000 /* 2mb */
19:57.08tmztcr2: I don't think I'm explaining myself well
19:57.15cr2this is just plain stupid.
19:57.20cr2ok
19:57.20tmztfine, but then they add gpu to that
19:57.45tmztcr2: by amss_ops I mean the things that we need to be able to define for g1 and ce seperately
19:57.54tmztfor most things the ops will be shared between amss versions
19:58.13tmztthe only thing the CONFIG_AMSS_xxxx should do is determine whether a particular versio is built
19:58.17tmztnot which is used
19:58.24tmztDEFAULT should go away
19:58.26tmztit's just broken
19:58.36cr2ok
19:58.45tmztthere's no reason a mach-msm zImage should not work on g1, sapp, raph100, raph800, raph500, etc.
19:58.54tmztincluding blak, kovs and whatever else
19:58.58cr2tmzt: can you explain me what is GPU0 and GPU1 ?
19:59.08tmztoffscreen stuff I don't understand
19:59.17tmztbut gpu also uses the fb define
19:59.19mdrobnakThat's android related stuff, no?
19:59.22tmztfor the front and back buffer
19:59.25cr2can they go away for non-android ?
19:59.28tmztfor now
19:59.30mdrobnakI haven't dug into the Android stuff enough.
19:59.46tmztuntil we can use HW3D or a better replacement
20:00.07cr2yes. we are happily using pxafb
20:00.17cr2without any HW3D
20:00.20tmztcr2: anyway, amss_ops then would have proc_comm and set_gpio and set_gpio_function and some clocks stuff
20:00.32tmztso we can do them manually, g1 can use amss, etc.
20:00.48tmztthis will also determine the method used to access the battery smem data
20:00.53tmztor rpc, etc.
20:01.08tmztthis will not include qdsp functions, those will be changed to something similar later
20:01.17tmztfor now we build per machine for that
20:01.39tmzteach arch/arm/mach-msm/amss_xxxx.o defines a global symbol
20:01.50tmztwhich is the struct amss_ops amss_xxxx_ops
20:01.55tmztstatic struct
20:02.03tmztincluding the function pointers for that version of amss
20:02.26tmztokay, I did mess up early
20:02.38tmztthe board's machine_init function will call a global function
20:02.47tmztmsm_set_board_amss_ops
20:02.54tmztto set the pointer to that struct
20:03.10tmztthen all of proc_comm_wince, etc. will be a stub using the ops functions
20:03.18cr2you can pick the amss version in board_init
20:03.26tmztyes, or per board setup or whatever
20:03.27cr2it's in smem already
20:03.39tmztfine, if that can be trusted
20:03.55cr2yes
20:04.02tmztbut this should fix rpc and let us use a reference of g1
20:04.10cr2we rely on the SMD layout and other things done by amss
20:05.12cr2how do we know about the MPU locked ram for amss ?
20:05.30tmztI guess there is one issue, the raph500 smd layout is different but uses the same amss version as raph800?
20:05.34tmztwhat does that mean?
20:05.39cr2without extracting amss from nand, and parsing the elf
20:05.41tmztyeah, I think xda people know the mpu
20:06.33cr2saving us the static allocation mess in board-*.h will be great
20:06.45tmzthow will that work?
20:06.51cr2i thing topa100 does not work because of that
20:07.37cr2you enable all available ram in _fixup()
20:07.42tmztme?
20:07.44cr2look what amss needs, and so on
20:07.46tmztmine is still broken
20:07.56cr2not you, the kernel code.
20:08.04cr2we check for the amss version already
20:08.07tmztI don't understand
20:08.14tmzthow do you read this layout?
20:08.19mdrobnakSo we are going to try and do this re-organization of the current tree?
20:08.20cr2just don't bring it to the end solution
20:08.41tmztmdrobnak: I would say pull a new tree from google or better ca
20:08.50cr2mdrobnak: switching to codeaurora 2.6.29 ?
20:09.16tmztthis is why we need a document outline the changes need for htc ce A devices
20:09.23cr2but it's easier to fix the mess in the current tree first
20:09.25tmztso we can make them as a clean set of abstractions
20:09.33cr2instead of trying to merge it into 2.6.29
20:09.37tmztyeah
20:09.41mdrobnakWell, Here's my thing... The Samsung stuff is based on .27 .. .and that has some of what we are talking about, right?
20:09.41tmztwe know 2.6.27 better
20:09.50tmztyeah
20:10.08tmztthe fact is we should be able to go to any kernel we want, including upstream, once we know what's happening
20:10.16mdrobnakSo maybe we should clean up as much as possible, then move to .29...then latest..
20:10.51cr2mdrobnak: yes. i'd like to separate android as the first step. and cleanup the ram allocation
20:11.18mdrobnakcr2: Well, here's my issue with that. All the 'reference' code we have...is for Android.
20:11.37*** part/#htc-linux rayman18 (i=opera@36.pool85-49-144.dynamic.orange.es)
20:11.48cr2but the root problem now is to determine the MPU'd areas dynamically for $board != raph100
20:11.49mdrobnakthat being said..I see no reason to seperate out Android code.
20:12.04mdrobnakHow can we do that?
20:12.08tmztno2chem: sorry, here is better
20:12.09mdrobnakOr we don't know?
20:12.42cr2mdrobnak: it's easier t do certain things without thinking about android.
20:12.42no2chemoh
20:12.56no2chemmpu is controlled by a9, so
20:13.04no2chemwhy do you need to control it?
20:13.29tmztcr2: what is the goal with dumping elf?
20:13.32cr2no2chem: not to control it, but to look which areas are requested by amss
20:13.42no2chemyou mean locked?
20:13.59cr2tmzt: the elf has all areas listed.
20:14.03cr2no2chem: yes
20:14.19mdrobnakcr2: But can we dump the ELF now?
20:14.23cr2no2chem: so we don't try to use it for linucx
20:14.45tmztI'm lost, you mean the areas of memory it has in use and we can't use?
20:14.46cr2mdrobnak: yes, you can disable the NAND MPU and dump the amss from nand
20:14.55tmztnot the ones it allocates for us, I see
20:15.15tmztno2chem: you were able to gain additional ram with custom nk right?
20:15.16mdrobnakcr2: That sounds like a great idea. I imagine the parsing problem is much harder.
20:15.19cr2tmzt: the areas it allocates for itself.
20:15.23cr2oemsbl and such
20:15.38tmztoemsbl should not be in use when amss is running
20:16.09no2chemeh
20:16.09cr2tmzt: but this ram location is mpu'd
20:16.13cr2so you can't reuse it
20:16.47cr2no2chem: dzo disabled the mpu for spl@0x0
20:16.56no2chemwell, you've read the msm7200 interface manual
20:17.04no2chemits there.. in chapter 2
20:17.05cr2so we can actually overwrite and use this memory for our needs
20:17.10no2chemah
20:17.11no2chemnice
20:17.32tmztno2chem: where you able to get more with with nk changes?
20:17.41no2chemtoo bad i don't know where MPU_DEF_PART_PERM1 is
20:17.53no2chemtmzt: i dunno, most of the work ive been doing is bsp
20:19.09cr2no2chem: btw, do you know the rpc clock id -> clock name mapping ?
20:19.44cr20x33, 0x28 and 0x29 are mdc_clk, vfe_clk and mdc_vfe_clk. but i don't know which one is what.
20:21.08tmztwhat they do?
20:21.08tmztor which number?
20:21.09cr2camera
20:21.47cr2tmzt: i have this amss allocation problem with topaz now
20:22.03cr2wince uses only 0x51=81MB
20:22.07tmztyou have topaz?
20:22.20tmztmdc is mobile display client I think
20:22.25cr2no, but i have written some code to support it. amss6120
20:22.33tmztsince the msm is the client in the case of camera that makes sense
20:22.46tmztvfe is video front end which is hardware as well as dsp
20:22.47cr2tmzt: these clocks are controleed over rpc
20:22.55cr2in wince
20:23.02tmztmdc_vfe_clk most be the dma engine between those two parts
20:23.34cr2#define MSM_EBI_LOCKED_BASE     MSM_FB_BASE + MSM_FB_SIZE
20:23.35cr2#define MSM_EBI_LOCKED_SIZE     0xD00000 /* 13mb */
20:23.47cr2these values are for raph100
20:24.05cr2nobody checked them on other devices.
20:24.20cr2maybe they are ok for amss52xx
20:24.30cr2but who knows about amss612x
20:25.38tmztwell, why do you need to know this at runtime?
20:25.45tmztisn't it in radio.img/nb?
20:28.11mdrobnakcr2:  The problem with that locked base thing -- if you change the layout...that changes. *Can* it change? Ie, did I move something I shouldn't have in mine?
20:28.52tmztcan we probe this with haret if we have to?
20:28.55mdrobnakIe, I changed: #define MSM_PMEM_MDP_BASE0x23D00000
20:28.57tmztjust try writes and see what happens?
20:29.02*** join/#htc-linux dcordes_ (n=dcordes_@unaffiliated/dcordes)
20:29.30mdrobnakWhich moved all the pmem stuff into the 2nd bank..giving me 107MB of RAM (cr2 said up to 115MB)
20:30.21tmzthow much do you normally have?
20:30.34mdrobnak89MB in the first bank..
20:30.37tmztwhen I inscreased bank1 above 109 I got fb corruption
20:30.52tmztbelow that it seems to work
20:30.53cr2mdrobnak: 640*480 18bit LCD. how much ram does it need ?
20:30.59cr2640*480*4 ?
20:31.27tmztyeah, think so
20:31.29cr2mdrobnak: the raph100 memory layout is documented.
20:31.31tmztsince it's not packed
20:31.42tmztcan you use 16bit with your client?
20:31.46mdrobnakcr2: About 1MB? 3bytes / pixel?
20:31.56tmztthere's no point in using 18 because you lose so much ram
20:32.01tmztmdrobnak: very slow on arm
20:32.04cr21228800
20:32.06cr2bytes
20:32.23cr2tmzt: we don't know how to change the panel to 16bit
20:32.45tmztwe have the registers don't we?
20:32.50tmztwhich client?
20:32.52tmztoh, panel
20:33.03tmztcan't the mddi scan out 18 with 16 buffer?
20:33.03cr21536000 for 800*480*4
20:33.26mdrobnakcr2: So I'm not sure if you answered my question - is the FB movable, or must it be at a certain address?
20:33.40cr2mdrobnak: it's movable
20:33.53mdrobnakOk. Thanks.
20:33.56cr2mdrobnak: you may move it to SMI, because this one is faster
20:34.00cr2afair
20:34.18cr2but then you need to get rid of this GPU0 android blob
20:34.19mdrobnakIt seemed Ok to me.
20:34.20mdrobnak:-)
20:34.42mdrobnakMy coworker with a non-S iPhone is jealous of my Fuze in Android hehehe
20:34.51tmztgpu0 is probably not being used, but unless you aren't doing dma from it to gpu it will break things
20:34.54cr2dzo said somehting like that android does want it to be in SMI
20:34.57tmztis my understanding
20:35.10tmztmdrobnak: android works with full phone on raph100/110 now?
20:35.16leviathanGnutoo: did you push now?
20:35.17mdrobnaktmzt: Using it everyday.
20:35.27Gnutooone sec
20:35.32leviathanok
20:35.32Epsylon3there is a project htc-tools/htc-boot to flash a zImage and boot from usb bootloader : http://git.linuxtogo.org/?p=ph5/htc-tools.git;a=summary
20:35.34Gnutooleviathan, push what? alsa or in oe?
20:35.40GnutooI'm about to push in oe
20:35.41cr2mdrobnak: that's why if i had a non-android setup, i would not wait a second to remove the GPU0 :)
20:36.01Gnutooleviathan, btw :
20:36.07Gnutoo*you said oe was broken
20:36.14cr2Epsylon3: it's unfinished. and it's for older devices.
20:36.14Gnutoo*you wanted oe commit access
20:36.23cr2Epsylon3: for newer devices there is htcflasher
20:36.24Gnutooso maybe send a lot of patches in the oe ml
20:36.26mdrobnakcr2: Here's my thought. If you can start ifdefing items...and not break android..go right ahead :-)
20:36.36Epsylon3yea compiled it but support magician hx4700 and another one
20:36.39Gnutoobecause if you said it was broken you may have fixes
20:36.49Epsylon3blue angel
20:36.49leviathanGnutoo: I've now built a running mokotouch image
20:37.04Gnutooleviathan, ok do they use oe?
20:37.15leviathanI've now fixed and merged the fixes into current org.oe.dev
20:37.18Gnutoook
20:37.19cr2mdrobnak: why 107MB ?
20:37.24Gnutoodid you get commit access btw?
20:37.32leviathanGnutoo: hmm, my mokotouch-oe-package does ;)
20:37.35leviathanGnutoo: nope
20:37.38Gnutoook
20:37.40leviathanthey refused
20:37.47Gnutoomaybe send more patches
20:37.47leviathanI stopped trying for now
20:37.48Gnutoothen
20:37.48tmztthey don't want it in core
20:37.53tmzttry shr or whatever
20:37.55tmztor angstrom
20:38.09GnutooI saw only the htcdream support message
20:38.17GnutooI'll read my mail later
20:38.20leviathanyeah, or upload it to gitorious, then they can merge it theire own
20:38.21*** join/#htc-linux cr2 (n=cr2@ip-109-84-56-184.web.vodafone.de)
20:38.23leviathan=D
20:38.29cr2hm
20:39.27cr2mdrobnak: the amss area starts at 0x17300000
20:39.38mdrobnakhmm
20:39.45cr2these are 155MB
20:39.52cr2s/155/115/
20:40.07cr2the 114'th MB has wince dmesg
20:40.15mdrobnakMy Linux area should end at 0x16000000
20:40.19cr2so it's clearly writable from arm11
20:40.30cr2mdrobnak: why ?
20:40.33tmztah
20:40.44mdrobnakThat's just the way I had it set up.
20:40.54mdrobnakThe diamond board had 107 as well
20:40.58mdrobnakI figured it was well tested ;-)
20:41.06cr2wince fb starts here 0x1666a000
20:41.16mdrobnakfwiw, the Samsung kernel uses 109MB.
20:41.32cr2it is all amss -dpeendent
20:41.48cr2i'm talking about raph100 with 52xx amss now.
20:41.51mdrobnak...which is why if we could parse it, we'd have a better idea.
20:41.59mdrobnak*better idea of where we can use or not use.
20:41.59cr2other devices are not that interesting
20:42.16mdrobnakTrue, cause I don't have one :-D
20:42.17leviathanGnutoo: BTW: I ment the alsa driver
20:42.38cr2mdrobnak: well. do 'pwf mywincedmesg 0x17200000 0x100000'
20:42.48mdrobnakBut for now, I wanted something I could use, until we could get back to the RAM issue.
20:42.52Gnutooleviathan, ok I'll push in replicant's repo after pushing into oe
20:43.07Gnutoopusing into oe means not for the alsa driver
20:43.11cr2mdrobnak: i hit this issue for topa100
20:43.14GnutooI don't push alsa to oe
20:43.15leviathanGnutoo: Your pushing it into OE?
20:43.15Gnutooyet
20:43.18leviathanahh, ok
20:43.24Gnutooleviathan, yes kernel and machine.conf
20:43.27Gnutoobasic things only
20:43.33Gnutoodcordes, wanted me to push things
20:43.36cr2because it's different amss, and the memory layout seems to be different. and i don't have amss dump for it
20:43.37mdrobnakcr2: Uptime 23:47:30 on Android :-)
20:43.40mdrobnakI'll reboot.
20:43.40Gnutooso I push
20:43.48cr2mdrobnak: :D
20:43.56leviathanokee, good that you're telling me that, because I was going to do the same ^^"
20:44.24leviathanso, is it now in gitorious?
20:44.36tmztcr2: wince fb is not used after htcfb finishes?
20:44.45tmztcan that me iounmapped?
20:44.57mdrobnaktmzt: Btw, still not sure how I want to do the android keymap.
20:45.02cr2tmzt: only by druidu-fb
20:45.26cr2tmzt: we should ioremap it in the first place
20:45.55cr2tmzt: using SMI :)
20:46.05leviathanGnutoo: in OE, ok
20:46.07leviathan:)
20:46.13mdrobnakcr2: Btw, tmzt told me someone tried to flash a g1 AMSS to a raph or diam...do you know if it worked?
20:46.18cr2tmzt: if you thing GPU0 is unused by android, we can drop it
20:46.34cr2mdrobnak: how can it work ?
20:46.42tmztmdrobnak: dream_kill?
20:46.50cr2mdrobnak: no cpld, and all the gpios are different.
20:46.59mdrobnakI figured as much.
20:47.03tmztI don't know, but I was told yesterday that pretty much everything is recoverable with serial cable, even on g1
20:47.06mdrobnaktmzt: Yeah I tink that's it.
20:47.08cr2so you can't just use the plain g1 kernel
20:47.10mdrobnak*that's who
20:47.33cr2tmzt: unless you blow away the oemsbl
20:47.35mdrobnakgetting wince message now
20:48.06mdrobnakIs it just me, or is HaRET slower in WinMo 6.5?
20:48.32cr2mdrobnak: let's try to squeeze the last byte from the first EBI1 bank :)
20:48.50tmztcr2: true
20:48.57leviathanGnutoo: did you push now?
20:49.02mdrobnakIt's a shame the second one is a pain in the butt with Android.
20:49.03Gnutooin oe yes
20:49.04tmztcr2: but we can do that in ram at runtime without issue I would think
20:49.09mdrobnakcr2: I'll try a build with 114MB.
20:49.15GnutooI'll push in replicant now
20:49.15cr2mdrobnak: android problem.
20:49.16leviathanhmm, did a pull, nothing there
20:49.26leviathanwhich branch? in OE?
20:49.26cr2mdrobnak: 115
20:49.37cr2mdrobnak: but you need to put fbram somewhere else
20:49.41leviathanoh
20:49.42leviathannow
20:49.43leviathandelay
20:49.59mdrobnakcr2: Fbram is already moved..
20:50.05mdrobnakcr2: Wow that's a long dmesg
20:50.09cr2mdrobnak: where ?
20:50.31mdrobnak(The one I just dumped from WinCE)
20:50.35mdrobnakerr
20:50.42cr2mdrobnak: i mean the fbram
20:51.06mdrobnakyeah
20:51.08mdrobnakI realized
20:51.09mdrobnakhehe
20:51.10mdrobnakone sec
20:51.36cr2#define MSM_EBI_SIZE            0x8000000 /* 128mb */
20:51.37mdrobnakOk, so original is:
20:51.45cr2this is a very misleading #define
20:51.56mdrobnak#define MSM_FB_BASE             MSM_PMEM_GPU1_BASE + MSM_PMEM_GPU1_SIZE
20:51.56mdrobnak#define MSM_FB_SIZE             0x200000 /* 2mb */
20:52.22mdrobnakWhich is what is is currently..
20:52.41cr2mdrobnak: where is GPU1 ?
20:52.45mdrobnakI changed #define MSM_PMEM_MDP_BASE       MSM_LINUX_BASE + MSM_LINUX_SIZE to 0x23D00000
20:53.01tmztwhat is LINUX size? it's not the kernel
20:53.24tmztactually, it might be helpful if we used a macro here
20:53.25cr2tmzt: is it used somewhere ?
20:53.27tmztand used ranges
20:53.44tmztI think it's just to set up the offset correctly for drivers
20:53.52tmztso they can find ranges in smem
20:53.52cr2tmzt: it all comes from g1 code ;)
20:53.58mdrobnakADSP = 0x23D00000 + 0x800000, GPU1 = + 0x800000, and FB is  +0x800000
20:54.16cr22d+8= ?
20:54.19cr23d+8= ?
20:55.00tmztsee, I could read that :)
20:55.08mdrobnakADSP = 0x24500000
20:55.22mdrobnakGPU1 = 24D00000
20:55.38cr2awk '{print 0x3d+8+8}'
20:55.39cr277
20:55.50cr2why in the middle ?
20:56.01mdrobnakFB = 0x25500000
20:56.17mdrobnakin the middle of?
20:56.33mdrobnakI had a solid reason for doing it. Can't remember now lol
20:56.43mdrobnakI didn't want to pick the absolute top of the 2nd bank, if I remember.
20:56.44cr20x20000000 - 0x28000000
20:57.07cr2mdrobnak: why not start at 0x20000000 ?
20:57.21mdrobnakI wanted to start from the top and work backward.
20:57.34mdrobnakSo that I could try to add more memory to Linux if we figured out what was not right.
20:57.54cr2the second bank is 100% ok for linux
20:58.07cr2!android though
20:58.15leviathanGnutoo: alsa in linuxtogo-kernel would be nice
20:58.17mdrobnakTrue.
20:58.26Gnutoobut it's buggy
20:58.33cr2mdrobnak: what about GPU0 ?
20:58.42mdrobnakGPU0 is where it was. Didn't move that.
20:58.48cr2ok
20:58.50GnutooI'll do a clean thing for replicant
20:58.58Gnutooit'll take a min
20:58.59leviathanok
20:59.00mdrobnakI only moved anything PMEM related.
20:59.14leviathanjust tell me, when you have finished
20:59.17mdrobnak(and the other stuff as a side effect)
21:00.04mdrobnakcr2: Oh, right, what did you want to see from the WinCE dmesg?
21:00.52leviathanI've created an compat-wireless-msmwifi_2.6.bb
21:00.55cr2mdrobnak: nothing. i only wanted to tell you that the 114th MB is perfectly usable
21:01.20leviathanand added msm_wifi.patch to URI for htcdream
21:01.21cr2so you should be able to boot with 115MB in the first EBI1 bank
21:01.42leviathanI'll send the patch later to the ML
21:01.59mdrobnak[K] MainMemoryEndAddress = 0x85A00000
21:02.00mdrobnak[K] PmemHeapPhyAddr = 0x00200000
21:02.00mdrobnak[K] dwPmemHeapSize  = 0x00700000
21:02.01mdrobnakInteresting.
21:02.34cr25a=90MB
21:02.46cr2but it's only for wince
21:02.47tmztoh
21:02.57cr2on topa100 they use only 81MB for wince.
21:03.38cr2pmem -> 2+7=9MB
21:04.23cr2in SMI
21:04.45cr2512K is locked for appsbl aka spl
21:04.52cr2can be unlocked though
21:05.25cr2but 512K -> 2MB is not used on wince
21:06.00cr2dzo put ramconsole at 0xe0000, but afair he moved it to 8MB now (on diamond)
21:07.24cr2mdrobnak: does linux boot with 115MB in the first EBI1 bank ?
21:08.06dzohi cr2 and mdrobnak
21:08.53cr2hi dzo
21:15.29*** join/#htc-linux tuxhero (n=tuxhero@122.169.169.172)
21:15.47tuxherocr2 hi
21:19.03*** join/#htc-linux SOG (n=SOG@n058152129154.netvigator.com)
21:21.34*** join/#htc-linux ptl_ (n=patola@201-68-170-252.dsl.telesp.net.br)
21:21.58*** join/#htc-linux FR^2 (i=frr@frquadrat.de)
21:25.44mdrobnakcr2: Sorry, was afk
21:26.19mdrobnakHi dzo.
21:27.43dzomdrobnak: hi, does data stay connected for you, it drops sometimes and won't return (on edge).
21:27.58mdrobnakdzo: Correct. It's a DNS thing.
21:28.12mdrobnakI was going to try your rootfs to fix it hehehe
21:28.31mdrobnakYou have ip-up working, right?
21:28.41dzook, i thought so, the arrows should flash with traffic too, probably the same problem.
21:28.51dzoyes, ip-up works.
21:29.40mdrobnakWell, here's the thing
21:29.43mdrobnakIt *gets* a DNS value.
21:29.47mdrobnakof 10.11.12.13
21:29.47mdrobnak:-(
21:30.03mdrobnakThats what happens to me anyway
21:30.06tmztyou could use rewrite
21:30.11mdrobnakExactly.
21:30.11dzoyes, mine too. initially it's correct then gets it wrong.
21:30.14tmztbut fixing it properly is much better
21:30.25mdrobnakNot sure how to.
21:30.42mdrobnakBut we could check to see if it's 10.11.12.23 and replace it with opendns in that case
21:30.53tmztwhere?
21:30.59mdrobnakin /etc/ppp/ip-up
21:31.09mdrobnakcr2: O
21:31.14mdrobnakcr2: I'll try a build in 2 minutes.
21:31.42dzoalso, does your usb reconnect after power collapse?
21:32.41mdrobnakno idea. I don't think I have full power collapse.
21:34.06dzomy remote-ip is 10.64.64.64, i think that's wrong too.
21:34.27mdrobnakThat's fine.
21:34.38mdrobnakIt just stuffs it along the interface
21:34.41mdrobnakit works :-)
21:35.31mdrobnakLots of warnings doing this compile...
21:35.46mdrobnakI'm at Oct 12 GIT
21:35.49dzodo you know what the net.dnschange property does?
21:35.51mdrobnakShould I update to latest?
21:35.59mdrobnakdzo: Makes Android re-read the server list.
21:38.07mdrobnakOk, trying to boot with 115MB
21:38.46mdrobnakLooks good.
21:39.02tmzton raph110?
21:39.13mdrobnakYeah
21:39.17mdrobnakI've got a cool Boot logo too hehe
21:39.43mdrobnakAnd we're at the home screen.
21:40.00mdrobnakcr2: Thanks for 8MBs more ;-)
21:40.40mdrobnak0-17 17:40:17.756 W/pppd    (  372): Could not determine remote IP address: defaulting to I
21:40.41mdrobnak10-17 17:40:17.756 I/pppd    (  372): local  IP address I
21:40.41mdrobnak10-17 17:40:17.766 I/pppd    (  372): remote IP address I
21:40.41mdrobnak10-17 17:40:17.766 I/pppd    (  372): primary   DNS address I
21:40.41mdrobnak10-17 17:40:17.766 I/pppd    (  372): secondary DNS address I
21:40.41mdrobnak10-17 17:40:17.906 D/MobileDataStateTracker(  120): CONNECTED event did not supply interface name.
21:40.43mdrobnak10-17 17:40:17.906 D/MobileDataStateTracker(  120): DNS server addresses are not known.
21:40.47mdrobnakStupid stuff happens on 3G
21:41.07mdrobnakroot@mdrobnak-desktop:~/android-repo/android-sdk-linux_x86-1.5_r3/tools# ./adb shell
21:41.07mdrobnak# ping www.google.com
21:41.07mdrobnakPING google.navigation.opendns.com (208.69.36.230) 56(84) bytes of data.
21:41.08mdrobnak64 bytes from 208.69.36.230: icmp_seq=1 ttl=49 time=145 ms
21:41.10mdrobnakBut it works fine :-)
21:41.29cr2mdrobnak: lol. the nadroid ril code is so primitive ;)
21:41.40cr2mdrobnak: i suggest to create a wiki table:
21:42.20cr2AT, wince RIL, htc android RIL, android RIL
21:42.48Gnutooleviathan, http://gitorious.org/replicant/gnulinuxkernel/commit/92945ccd0921e940fc2675dc394141db0f7c1386
21:43.04mdrobnakI don't understand. How can we know what's in the G1 one without disassembling it?
21:43.08mdrobnakIt does NOT echo AT commands.
21:43.10tmztuse ppp0 for interface
21:43.13tmztthis makes sense
21:43.30tmztmdrobnak: add somethign to kernel to dump read/write on smd0
21:43.39mdrobnakThat'll work.
21:43.49tmztyou need to know it's rpc format though
21:43.54mdrobnakOh, right.
21:44.00tmztsince rild communicates with the rest of android over a custom rpc
21:44.01cr2mdrobnak: it's called "strings" and objdump
21:44.01mdrobnakThat's pretty useless to us then?
21:44.02*** join/#htc-linux stickboy (n=anonymou@128.153.211.150)
21:44.10mdrobnakcr2: -P
21:44.14mdrobnak:-P
21:44.24tmztthe interface it brings up must be encoded in an event some how
21:44.25tmztwell
21:44.31tmztyou could proxy the socket as well
21:44.50tmztyou also have rild source
21:44.55cr2tmzt: lol, gsmd :)
21:44.57mdrobnaktmzt: But if you're spying on smd0, who cares. You can get a timed log from Android. Correlate the events.
21:45.29cr2wtf is 76XXD-6125-DSDCAAPZM
21:46.00tmztcr2: ?
21:46.10mdrobnak6125 = ADSP version?
21:46.12tmztthat looks like a amss version string
21:46.18cr2mdrobnak: amss
21:46.19tmztoh
21:46.20tmztfrom topa?
21:46.25cr2tmzt: yes
21:46.30mdrobnakThat's what I meant
21:46.30tmztso it's not 6150
21:46.36cr2no
21:46.41cr2it's gsm
21:46.43tmztbut it's msm7600
21:46.50tmztno it's not apparently
21:46.56cr27201A
21:47.02tmztJason8: did you say they all use 7600?
21:47.02tmztoh
21:47.06mdrobnakWait, which one is the Topaz?
21:47.11tmztwhat is the 76XXD for then?
21:47.16cr2no idea
21:47.26Jason8It wasn't me, but someone else said it.
21:47.31cr2it's some SMD item
21:47.41mdrobnakBecause I know for Sprint, the Touch Pro 2 is both CDMA and Quad Band GSM
21:48.12Epsylon3hmmm found something.... with boot loader terminal, when i type "Task 38" (that show something like an Windows CE init log)
21:48.17Epsylon3B4WaitARM9DexReady PV_DRIVERGLOBAL->fixAddress.bIsBatteryReplaceB4=0xffffffff
21:48.25tmztJason8: he said for at&t also
21:48.30Jason8yep
21:48.32Epsylon3should be 0
21:48.42Jason8I think it was trip that said the pure was msm7600
21:48.47tmztcr2: that string is also in the device info
21:49.08tmztcr2: how do we know it's msm7201a?
21:49.10tmztactually, it's not
21:49.14tmztit's msm7200a
21:49.22cr2tmzt: it's the same.
21:49.25Jason8GSMArena says 7200a
21:49.39cr27201A is a politically correct name
21:49.55cr2they are identical i think
21:50.26tmztnot usb at least
21:50.34tmztwell, that was 7200 non-A
21:50.52tmztwe can always look at trout/sapp kernel differences
21:50.53cr27200A is 7201A
21:50.55tmztwhich are minimal
21:51.40*** join/#htc-linux Abracadabr4 (n=Abracada@92.24.47.47)
21:54.35phhhas anyone tried running Xegl against android's libgl ?
21:54.52tmztnot that I know of
21:55.03cr2leviathan: can we fix /dev/mem on g1 ? i'd like to see a full smem dump from g1
21:55.21leviathancr2: sure we can
21:55.38leviathanbut first I have to finish hacking around in userspace
21:55.52cr2ok
21:56.03leviathanatm: Im trying to get compat-wireless building as bitbake-package
21:56.18*** join/#htc-linux dcordes__ (n=dcordes_@unaffiliated/dcordes)
21:56.41leviathanAnd I'm adding gnutoos-patch to the depencies for the linux-msm7xxxx-kernel
21:56.42Gnutooleviathan, how hard is /dev/mem fix?
21:56.45leviathanin OE
21:56.50leviathanhmm
21:57.14Gnutoocr2, is it because of /dev/mem problem that gdb bt makes the phone reboot?
21:58.13leviathanhmm
21:58.29leviathan/dev/mem is optimized to be used by the android tools
21:58.47leviathanto inject graphics and initialize sound, etc.
21:59.09Gnutoook
21:59.13tmztpmem is
21:59.18leviathanso a lot of things you should not be allowed to do on an ordinary /dev/mem interface
21:59.40leviathanpmem?
21:59.47leviathanmom
21:59.54cr2leviathan: lol, "optimized"
22:00.17cr2leviathan: embraced and extended
22:00.30mdrobnakcr2: I will agree, they did some stupid stuff.
22:00.31Gnutoolol
22:00.32leviathancr2: yes, that would be the correct term
22:00.34leviathan^^
22:00.56mdrobnakThe key map is ... annoying.
22:00.56leviathanyeahh
22:00.58Gnutoomdrobnak, can the keyboard be remapped?
22:01.25leviathanmdrobnak: would be nice, if you could do this
22:01.31leviathanI tried but gave up
22:01.35mdrobnakYeah, trying.
22:01.36leviathanits tooo ennoying for me
22:01.37mdrobnakit's a pain
22:01.46mdrobnakI got it in console/X
22:01.46leviathanfull agreement
22:01.48mdrobnakbut not And
22:01.51leviathanits pita
22:01.51Gnutoobecause android remaps it
22:01.56leviathanpain in the a*
22:02.05Gnutooin the init.something scripts that are in /
22:02.06leviathanPITA
22:02.08leviathan:)
22:02.12Gnutooif I remember well
22:02.17leviathanyeahh
22:02.31leviathanits binary f* s* tinkering
22:02.45leviathanbut not beautiful hacking tinkering
22:02.51leviathanmore the ugly and dirty kind
22:03.03mdrobnakActually
22:03.05mdrobnakit's quite easy
22:03.07leviathanmake cat and you can type reset in the keymap
22:03.09mdrobnakyou set a property value
22:03.16mdrobnakto the bin file
22:03.17mdrobnakbut
22:03.24mdrobnakgetting that bin file right is a pain
22:03.25mdrobnakbrb
22:03.31leviathanok
22:04.21Gnutoomdrobnak, how did you get it in X?
22:04.23Gnutooxmodmap?
22:05.35cr29*4=36
22:05.39cr28*4=32
22:06.49tmztI will be back, I guess your going to bed soon cr2?
22:07.43cr2tmzt: yes
22:08.48cr28 vs. 9
22:12.39cr2<PROTECTED>
22:12.40cr2<PROTECTED>
22:12.41cr2<PROTECTED>
22:12.43cr2<PROTECTED>
22:12.47cr220+3*4=32
22:13.47tmztwhat's this?
22:15.48cr2struct smd_alloc_elm {
22:16.16cr2seems to have one more unt32_t on amss612x ;)
22:16.46tmztsee why we need ops?
22:16.48cr2between cid and ref_count
22:17.03cr2#ifdef for now :)
22:17.24tmztwhat do you think is there?
22:18.02cr2unused
22:18.10cr2it's not on samsung
22:18.37tmztwhat is ctype?
22:18.48cr2not on sapp
22:19.05cr2should be stream vs. packet ?
22:19.15cr2but not used.
22:19.15tmztwhat values
22:19.27cr20
22:19.38cr2i've seen in in some code.
22:20.12tmztok
22:20.20tmztso just a place holder for now then?
22:20.38cr2tmzt: there was a seriuos (i think) rpc bug fixed two days ago in codeaurora code.
22:20.40cr2tmzt: yes
22:20.52tmztok
22:21.05cr2* 'type' field of smd_alloc_elm structure
22:21.07cr2<PROTECTED>
22:21.08cr2<PROTECTED>
22:21.10cr2<PROTECTED>
22:21.11cr2<PROTECTED>
22:21.27tmztright
22:21.30tmztso we never use packet?
22:22.08cr2no
22:22.15tmztneed to go
22:22.20tmztgoodnight
22:22.37cr2#define SMD_CHANNEL_TYPE(x) ((x) & 0x000000FF)
22:22.50cr2#define SMD_XFER_TYPE(x)    (((x) & 0x00000F00) >> 8)
22:22.50cr2good night
22:24.57mdrobnakGnutoo: Set the default keymap
22:25.36Gnutoomdrobnak, ok but with xmodmap?
22:25.43Gnutoowith which application
22:25.56mdrobnakGeneral X should use the default console stuff, right?
22:26.11mdrobnakOtherwise that's highly annoying
22:26.22mdrobnakI was testing Mer
22:26.28mdrobnakbut I dont remember if I tried it in X
22:26.43Gnutoomdrobnak, ah ok with console...I'll try...what was the command to set the console keymap?
22:26.43mdrobnakOh.
22:26.49mdrobnakloadkey?
22:26.51Gnutoothanks
22:27.04mdrobnak/etc/console-setup/boottime.gz or something
22:28.11Gnutoook
22:29.08Gnutoomdrobnak, but did you get android keys mapping under mer...that is the alt key thing
22:29.13Gnutoolike the -
22:29.23*** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net)
22:29.25Gnutoothe /
22:29.26Gnutooetc...
22:29.41Gnutoobecause I've qwerty under X
22:29.46Gnutoos/X/kdrive
22:29.55Gnutoobut...that's not great without the -
22:31.13mdrobnakI mapped Fn to Alt
22:31.19mdrobnakand so that worked for me
22:31.52mdrobnakthe problem is Android's keys are wrong...
22:31.52leviathangoes sleeping now
22:32.09mdrobnakGood night leviathan
22:32.16mdrobnakI love Android messages: 10-17 18:31:40.396 I/NotificationService(  120): enqueueToast pkg=com.dataviz.stargate callback=android.app.ITransientNotification$Stub$Proxy@43430f58 duration=0
22:32.21leviathanmdrobnak: thanks, same to you =)
22:32.28mdrobnakenqueueToast? lol
22:32.49Gnutoook
22:32.53Gnutooleviathan, good night
22:32.55mdrobnakhmm..
22:33.02mdrobnakCan't get it to load my stupid map
22:33.03mdrobnakargh
22:36.21cr2at@agpsfeature=0
22:36.30mdrobnakyeah I saw that cr2
22:36.33mdrobnakdoes that help you?
22:36.41mdrobnakhow is gps coming?
22:38.08cr2not yet
22:39.57mdrobnaklocation via GSM isn't fun, as I discovered
22:39.58mdrobnakhehe
22:40.15mdrobnakIe, the RIL code needs quite a bit of work there. It wasn't really even done.
22:40.40cr2mdrobnak: do you have fieldtest.exe ?
22:40.56mdrobnakin windows? Not sure.
22:43.23cr2good night
22:43.56mdrobnakgood night
22:45.19mdrobnakneeds to rework system.img to load keymaps from rootfs.img
22:45.26mdrobnakdinner time
22:58.01dcordes__Gnutoo, rats.. I have no luck with OE these days
22:58.20dcordes__Gnutoo, do you have dream rootfs somewhere?
22:58.21dcordes__shr
23:48.39*** join/#htc-linux Abracadabr4 (n=Abracada@92.24.47.47)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.