**** BEGIN LOGGING AT Tue Feb 09 02:59:56 2010 Feb 09 03:04:50 DocScrutinizer: How you've done to install your distribution on the uSD card? Feb 09 03:05:03 using a uSD card reader? Feb 09 03:05:10 exactly Feb 09 03:05:39 wait a jiffy. Will come up with a solution for you in a minute Feb 09 03:07:56 cosmos: ssh to FR Feb 09 03:08:37 (assuming you already copied the *.tgz) Feb 09 03:09:18 tell me when you're there Feb 09 03:09:28 I'm there Feb 09 03:10:18 cd /media/card Feb 09 03:10:47 ls -l *.tgz Feb 09 03:10:54 report what you get Feb 09 03:14:43 By "(assuming you already copied the *.tgz)" you mean on /media/card, isn't it? Feb 09 03:14:46 cosmos: still alive? Feb 09 03:14:57 yes Feb 09 03:15:06 I've just deleted it... Feb 09 03:15:15 copy again Feb 09 03:15:15 hehehe Feb 09 03:17:42 make sure you mounted the uSD ext3 partiton to /media/card, before you copy it. So you don't accidentally copy to a folder media/card on / NAND Feb 09 03:20:49 I get: Feb 09 03:20:51 -rw-r--r-- 1 root root 77544119 Feb 9 2010 full-om-gta02.tar.gz Feb 09 03:21:09 looks good Feb 09 03:21:28 you are cd to /media/card, yes? Feb 09 03:21:34 yes Feb 09 03:21:58 tar -xz -f full-om-gta02.tar.gz Feb 09 03:22:37 maybe even Feb 09 03:22:44 tar -xzv -f full-om-gta02.tar.gz Feb 09 03:23:09 v for verbose, so it's less boring ;-) Feb 09 03:23:09 hm.. where is the setting in shr now to disable auto suspend? Feb 09 03:23:14 i've launch the first one Feb 09 03:23:19 np Feb 09 03:23:28 suspend=0 in [odeviced.idlenotifer] no longer works Feb 09 03:24:02 Psi: usually it's in SHRsettings-power Feb 09 03:24:37 yeah, the slider wont move to autosuspend off, just jumps back to on when you let go Feb 09 03:24:57 ooops Feb 09 03:25:05 ask TAsn or dos1 Feb 09 03:25:25 ok Feb 09 03:26:11 Psi: try from right to left Feb 09 03:27:05 cosmos: na, doesnt work Feb 09 03:28:27 Psi: current shr-u? Feb 09 03:29:47 DocScrutinizer: That's done! Feb 09 03:30:11 do a ls and check if it looks like a system Feb 09 03:30:50 then: Feb 09 03:31:01 mkdir /media/bootpart Feb 09 03:31:29 mount /dev/mmcblk0p1 /media/bootpart Feb 09 03:31:31 its gta01 running image from 1/02/2010 Feb 09 03:32:21 Psi: sorry no idea here Feb 09 03:32:27 Yes it looks like Feb 09 03:34:29 ok Feb 09 03:34:32 cosmos: then 'cp boot/* /card/bootpart' Feb 09 03:35:35 DocScrutinizer: cp: cannot stat `boot/*': No such file or directory Feb 09 03:35:52 err Feb 09 03:36:35 where are you ? ( 'pwd' ) Feb 09 03:38:20 whatever, do a 'ls /media/card/boot' and paste the output Feb 09 03:38:33 err Feb 09 03:38:42 whatever, do a 'ls -l /media/card/boot' and paste the output Feb 09 03:38:58 append-GTA02 uImage uImage-2.6.29-rc3 uImage-GTA02.bin Feb 09 03:39:14 that looks good. Feb 09 03:39:38 so I assume you managed to leave /media/card Feb 09 03:40:04 yes Feb 09 03:40:21 'cp boot/* /media/card/bootpart' Feb 09 03:40:31 sorry, my fault Feb 09 03:41:29 nah Feb 09 03:41:36 'cp boot/* /media/bootpart' Feb 09 03:41:52 late here :-/ Feb 09 03:42:26 same error message Feb 09 03:42:55 'cp /media/card/boot/* /media/bootpart/' Feb 09 03:44:06 cp: writing `/media/bootpart/uImage': No space left on device Feb 09 03:44:06 cp: writing `/media/bootpart/uImage-2.6.29-rc3': No space left on device Feb 09 03:44:06 cp: writing `/media/bootpart/uImage-GTA02.bin': No space left on device Feb 09 03:44:32 hmm Feb 09 03:44:53 rm /media/bootpart/* Feb 09 03:45:35 df -h /media/bootpart Feb 09 03:45:57 paste here Feb 09 03:46:12 Filesystem Size Used Avail Use% Mounted on Feb 09 03:46:12 /dev/mmcblk0p1 486K 14K 472K 3% /media/bootpart Feb 09 03:46:46 but /dev/mmcblk0p1 have 16M Feb 09 03:46:48 darn, you created a 486k partition Feb 09 03:47:08 so I think that's an issue with my actual /etc/fstab Feb 09 03:47:15 nope Feb 09 03:47:17 which is wrong Feb 09 03:47:20 no? Feb 09 03:47:22 don't think so Feb 09 03:48:02 please paste result of Feb 09 03:48:19 mount | grep k0p1 Feb 09 03:48:49 /dev/mmcblk0p1 on /media/bootpart type vfat (rw) Feb 09 03:49:26 check actual parameters of partition1 with cfdisk Feb 09 03:49:35 if you have that Feb 09 03:49:41 otherwise use fdisk Feb 09 03:49:55 fatal error Feb 09 03:50:02 I try with fdisk.. Feb 09 03:50:48 errrr, you rebooted since you repartitioned the uSD? Feb 09 03:51:32 oops I don't remember Feb 09 03:51:44 here is the output: Feb 09 03:51:45 /dev/mmcblk0p1 1 16 504 4 FAT16 <32M Feb 09 03:51:45 /dev/mmcblk0p2 17 474212 15174272 83 Linux Feb 09 03:51:46 /dev/mmcblk0p3 474213 489472 488320 82 Linux swap / Solaris Feb 09 03:51:58 after you change partiton table (with fdisk), you need to reboot or kernel won't notice the changed config Feb 09 03:52:57 Can I reboot now without compromising the install? Feb 09 03:53:25 cyl 1..16, 504k size, type 4 fat16 Feb 09 03:54:11 ok I reboot Feb 09 03:55:41 How big is that card? Feb 09 03:55:47 16gb Feb 09 03:55:49 16G? Feb 09 03:56:02 15174272 83 Linux Feb 09 03:57:11 So with all that space, the first partition is less than a single MB? Feb 09 03:57:26 yup, seems so Feb 09 03:57:35 should be16MB Feb 09 03:57:44 at least Feb 09 03:57:46 or 50 Feb 09 03:58:32 with a 16GB (!!!!) uSD card, there's no reason to make that partition small. Feb 09 03:58:43 But you can't even fit a kernel on 150KB Feb 09 03:58:50 anyway... Feb 09 03:58:58 yeah we know that, mwester_ Feb 09 03:59:07 Ok. Feb 09 03:59:24 btw it's 474k Feb 09 03:59:42 err 504 Feb 09 03:59:46 yes, even after reboot... Feb 09 03:59:52 Not sure what you guys are up to, I just saw some numbers that looked very odd on the screen. Sorry. Feb 09 04:00:22 mwester_: cosmos did a oopsy when partitioning the card Feb 09 04:01:24 cosmos: but now you know all you need to redo it tomorrow, make the first partiton 50MB in size, and FAT32(!) type Feb 09 04:02:02 actually the copy above that failed was the last step. If it succeeded your card should be finished Feb 09 04:02:13 DocScrutinizer: ok, I gonna copy and paste all this topic and retry tomorrow again. Thanks for your help. I have to sleep a little bit. Feb 09 04:02:26 me too Feb 09 04:02:35 good night Feb 09 04:02:50 before the evil daystar rises ;-P Feb 09 05:06:46 if i want a script to be run upon resume, where's the appropriate place to put it? /etc/apm/resume.d/? Feb 09 06:57:52 morning Feb 09 06:57:57 Undrwater: I think so, yes Feb 09 09:06:46 freerunner is not recognizing my SIM card even after 10min uptime - doesn't ask for PIN, contact list is empty and I can't call/receive. Using shr-t. SIM card tray is in the locked position. what causes could there be? Feb 09 09:07:26 sometimes just reboot helps Feb 09 09:08:21 done it three times Feb 09 09:08:58 should the SIM be recognized automatically at boot? Feb 09 09:10:01 yep Feb 09 09:14:56 Hi All. Feb 09 09:16:51 Hi - Im looking for freelance openmoko developers to customise the OS for some specific requirements. Could someone point me in the general direction to speak to someone? Feb 09 09:17:25 Moz_, depend on which OS? Feb 09 09:17:48 but FSO or SHR projects will be really happy get some work Feb 09 09:17:58 you can find all of them on #openmoko-cdevel Feb 09 09:18:29 but I suggest evening time(for Europe) for discussion - just many people online Feb 09 09:19:01 or drop a line at the mailing lists Feb 09 09:19:03 max_posedon - Not sure yet. I havent purchased a Freerunner or dev board. I saw the A7 version on openmoko.com which I think would suit what I need. Feb 09 09:19:27 Moz_: can you spare more details or is it secret? Feb 09 09:19:55 max_posedon - thanks for the other channel Ill try there also. I'm not fully sure what the difference is between SHR and FSO Feb 09 09:20:13 Moz_: FSO is middleware, SHR is a distro. Feb 09 09:20:23 Moz_: and UI is part of the SHR project. Feb 09 09:20:30 Moz_, they aren't different, they about same thing on different levels) Feb 09 09:20:55 PAulFertser - sure. Im looking to have the phone pull SIM details over TCP/IP rather than from a SIM held locally in the phone. I'll have a SIM bank of SIMs then the phone should use the wireless connection to call back to a central server which com,municates with the SIM bank and decides which SIM the handset should use. Lots more on top of that but that's a key part for me Feb 09 09:21:39 Moz_: lowlevel sim access is impossible on freerunner :( Feb 09 09:21:52 Moz_: without reverse engineering the calypso firmware Feb 09 09:21:55 Most probably Feb 09 09:22:14 PaulFerster - Im also looking to use the device as a remote channel on an Asterisk server. The phone should call back to the Asterisk server over TCP/IP, register that it has internet and is ready to go. Asterisk will then add it as an outbound channel and calls can be routed out over that channel. Feb 09 09:23:03 Moz_: your main idea to have a bank of sims read remotely is the most complex part probably. Feb 09 09:23:22 PaulFerter: Ah right ok thanks. I saw the Calypso GSM chip docs had been leaked so I dont know if that would allow someone to provide the remote SIM capability., Feb 09 09:24:14 Moz_: Dieter Spaar has access to firmware building process (only AT command layer is in sources, other stuff is binary) and strong reversing skills. Probably he'll able to do what you want but it'd be a big effort and big money most probably. Feb 09 09:24:16 PaulFertser: There's no way to over-write the details Calypso gets from the SIM? Feb 09 09:25:05 PaulFertser: That's great thanks. Feb 09 09:26:03 PaulFertser: Ahh - I see Dieter Spaar has links to the CCC. They've done some very good research into GSM. Excellent, thanks for the suggestion. Feb 09 09:26:53 Moz_: probably there's an easier route: it might be possible to build hardware that emulates sim signals by communicating with a real sim. Feb 09 09:28:21 Moz_: btw, FR's wifi is not really reliable, it might be incompatible with some APs altogether. Feb 09 09:28:54 PAulFertser: Well I did think of that. Have some sort of handware bolted to the phones which has a "fake" SIM in the SIM holder of the handset. The hardware can then be updated over TCP/IP which subsequently gives different SIM details to the phone as and when needed. I saw there's a remote SIM protocol for Bluetooth called remote SIM Access Profile (rSAP) which allows a car phone to use the SIM details of a bluetooth handset. Feb 09 09:29:33 PaulFertser: Ah, that might be a big downside. I did think about looking into Android developers but Im not sure what I need would be possible on an Android based platform either. Feb 09 09:30:24 Moz_: do you know if any of android phones support rSAP? Feb 09 09:31:24 Moz_: fake sims are hard nowadays, but building an "extender" might work if there's nothing timing-critical in the sim communication protocol. Feb 09 09:31:39 I mean real-time bitbanging over tcp/ip :) Feb 09 09:32:11 Moz_: FR has a usb host so basically you can use any usb wireless card. Feb 09 09:33:58 http://www.pastebin.org/88744 I'm getting this in the logs with the GSM issue, what does it mean? Feb 09 09:35:46 Moz_: so even if you need to build an external hardware to emulate sim FR would probably still be a good platform -- really hackable, schematics available, etc etc. Feb 09 09:36:22 PaulFertser: Thanks for the information on the USB hub. I'll drop an email to Dieter to see if he can help. What sort of things have you been working on with FR? Feb 09 09:36:33 Moz_: you can use some small additional board with an IC to use it as a GPIO extender, connect it to a sim socket, power from the phone itself and connect to the internal SPI or UART bus. Feb 09 09:37:23 Moz_: i did some very humble bootloader/kernel work, just that. Feb 09 11:01:54 http://konkurranse.ps.no/vote/208 Feb 09 17:01:25 hi Feb 09 18:09:18 PaulFertser: did you know I planned to hook up the UMTS-modem's SIM-bus to AP's GPIOs for GTA04, to faciliate hacks like that one? :-) Feb 09 18:09:35 GTA04? Feb 09 18:09:43 When did that happen? :) Feb 09 18:09:58 what happen? Feb 09 18:10:05 GTA04? Feb 09 18:10:08 In an alternate 2010 Feb 09 18:10:15 lol Feb 09 18:10:17 Where OM was competent. Feb 09 18:10:26 Oh, and who's working on the reimplementation of FSO stack in C which was mentioned on FOSDEM? Feb 09 18:10:54 So GTA04 is never going to happen? Feb 09 18:10:58 Bluetooth SIM profile would be so nice. Feb 09 18:10:59 ne ver Feb 09 18:11:01 ebbe: well... Feb 09 18:11:09 ebbe: The market has moved on somewhat. Feb 09 18:11:20 How about a time machine? Or maybe passing into parallel universe? Feb 09 18:11:23 I'm still here :) Feb 09 18:11:26 ebbe: there are a number of phones that exploit much of the same market - though are not quite as open. Feb 09 18:11:30 DocScrutinizer: wow, it'd be a really nice device :) Feb 09 18:11:42 ebbe: for example - the n900 - sets a sharp cap on pricing. Feb 09 18:12:00 ebbe: If you can sell a comparable device for 2/3 of the n900 - you might get away with it. Feb 09 18:12:05 And what would be probability of coding a driver for accelerated 3D on Neo? Feb 09 18:12:20 SpeedEvil, You are probably right. Feb 09 18:12:24 ebbe: But - that is - probably - >$5m to develop and build the first 10000. Feb 09 18:12:54 azaghal: that would be me and the freesmartphone.org team Feb 09 18:12:57 Is the n900 open enough to run SHR? Feb 09 18:13:00 [fso stack in C] Feb 09 18:13:07 I bought the n900 since that was/is the most open phone that works that money can buy (at least to my knowlage) Feb 09 18:13:27 ebbe: With 1m - you would get signifiantly inferior hardware to n900 - with lower price. Feb 09 18:13:30 mickeyl: Do you expect the performance gain would be worth it? Feb 09 18:13:37 n900 in principle can run shr. however. Feb 09 18:13:42 azaghal: yes, the performance gain will be huge Feb 09 18:13:49 There are a number of closed source userspace stuff that needs fixed. Feb 09 18:13:49 azaghal: and also the 'acceptance' gain Feb 09 18:14:09 azaghal: please check my slides for the goals Feb 09 18:14:12 (and benefits) Feb 09 18:14:29 mickeyl: Ok, will do. I attended the dbus talk on FOSDEM. Feb 09 18:14:47 for reference: http://linuxtogo.org/~mickeyl/misc/FOSDEM2010.pdf Feb 09 18:15:15 Are there any progress in the graphics department for gta03? It's the one thing I hate about my Freerunner :/ Feb 09 18:15:24 And some aspects of the n900 that are troubling - the GPS for example - are hidden as they are in seperate hardware. Feb 09 18:15:49 SpeedEvil, :( Feb 09 18:15:59 mickeyl: >> And what would be probability of coding a driver for accelerated 3D<< ?? huh? Feb 09 18:16:49 azaghal: the driver is already there - pretty much. Feb 09 18:16:59 mickeyl: FSO is into glamo mud now? Feb 09 18:17:16 azaghal: the fundamental hardware sort-of-sucks. That's not to say that the software couldn't use the hardware better - but... Feb 09 18:17:35 azaghal: developing hacks only usable on FR are of debatable use. Feb 09 18:18:24 azaghal: evertheless Weiss is about to hack on glamo Feb 09 18:18:47 afaik Feb 09 18:19:03 DocScrutinizer: heh, i was answering Oh, and who's working on the reimplementation of FSO stack in C which was mentioned on FOSDEM? Feb 09 18:19:24 aaah, missed that one Feb 09 18:23:21 apropos Weiss Feb 09 18:23:31 Weiss: ping Feb 09 18:23:51 Weiss: managed to burn your fingertip meawhile? Feb 09 18:36:07 Looks like a better connection now... Feb 09 19:28:35 DocScrutinizer: not quite... I think I'm going to try the cut down kernel before taking cans off Feb 09 19:31:26 Weiss: well, I suspect it's glamo, as it is hardly believable CPU could burn 500mA by spinning in a loop, and still system responsive and no abnormal load values showing up in top Feb 09 19:32:31 Weiss: you could assert a reset to glamo to see if it makes a diff Feb 09 19:34:05 also uSD interface comes to mind Feb 09 19:34:07 good idea.. Feb 09 19:34:09 * Weiss adds to list Feb 09 19:35:15 a short of some of the uSD contacts even more makes a good story how to burn 500mA without system getting sluggish Feb 09 19:35:36 short to GND (holder metal) that is Feb 09 19:36:47 oh.. interesting... because there's no SD card in right now.. and those contacts look awfully close to the metal lid.. Feb 09 19:37:09 yeah I know. That's why I mention it Feb 09 19:37:23 hang on, I'll fashion a plastic "blank" and put it in Feb 09 19:37:38 some paper will suffice Feb 09 19:37:57 or my holder-handle :-) Feb 09 19:39:02 http://people.openmoko.org/joerg/sdcard-handle/ Feb 09 19:39:18 I cut a rectangle of blister-pack plastic from the packaging of a small halogen bulb.. Feb 09 19:39:21 booting.. Feb 09 19:40:17 current is LOW just after booting... I'll need to abuse it a bit to test.. Feb 09 19:40:23 root@om-gta02 ~ $ cat /sys/class/power_supply/battery/current_now Feb 09 19:40:23 109500 Feb 09 19:41:32 109500 Feb 09 19:41:34 root@om-gta02 ~ $ cat /sys/class/power_supply/battery/current_now Feb 09 19:41:34 -404250 Feb 09 19:41:38 (mains charger in) Feb 09 19:42:03 that doesn't mea much Feb 09 19:42:27 mean Feb 09 19:44:18 I'll test it like this for a while and see if I can provoke the drain again.. Feb 09 19:46:19 two of the middle SD pins project a little higher (out of the plane) for me.. is that normal? Feb 09 19:46:27 it looks like enough to contact with the SD lid Feb 09 19:47:54 Weiss: I'd suggest to remove the plastic, provoce the monster drain, then carefully opening the uSD holder nad watch the current drop to normal instanty Feb 09 19:48:42 Who held the dbus presentation at FOSDEM, btw? (from here, I presume) Feb 09 19:49:11 and no, it,s not in the pecs of this mech component to have 2 protruding pins Feb 09 19:49:20 azaghal, you might be speak about mickey Feb 09 19:49:31 Ok, just wanted to check :) Feb 09 19:50:29 specs Feb 09 19:56:03 moo! Feb 09 19:56:18 * Chocky bitches about bluetooth in latest SHR. Known bug, right? ;-) Feb 09 19:56:28 azaghal: probability of 3D *eventually* is high, if the alternatives for (a) open phone, and particularly (b) open embedded graphics continue to suck :)... just a question of whether it'll take six months, a year, two years, five years, ... with just me working on it Feb 09 19:57:43 is anyone else not getting sound from the glamo version of mplayer under shr-u? Feb 09 19:58:58 Weiss: Hm... Is it NDA'ed? Feb 09 19:59:21 azaghal: the driver? http://git.bitwiz.org.uk/. the datasheets: yes Feb 09 20:00:19 Hrm, I hate NDA's. Feb 09 20:00:20 DocScrutinizer51: struggling to provoke the drain after removing the blank.. maybe I need to let it "stew" for a couple of hours Feb 09 20:02:02 try accessing the non existent uSD! Feb 09 20:04:32 * azaghal should really try to get focused a bit more :) Feb 09 20:05:16 Weiss: What was the reading you had to do to get going with it in the first place? (just curious, I can't promise stuff I can't keep anymore: ) Feb 09 20:08:02 I was already familiar with how OpenGL and graphics hardware works in general, but I had to study DRI, Mesa and Linux (kernel) very closely for quite a long time Feb 09 20:08:39 I see, quite a rough thing then. Feb 09 20:09:54 yep, a very steep learning curve Feb 09 20:10:08 but I typically work best under those conditions Feb 09 20:10:48 but low-level graphics stuff isn't *that* hard.. not quite as hard as you'd imagine from outside Feb 09 20:12:04 I kind of got "horny" after listening to the closing "How to submit your first kernel patch" talk at FOSDEM :) Feb 09 20:12:04 DRI2 is also a lot simpler than DRI1 Feb 09 20:12:09 hehe Feb 09 20:12:52 Actually, the whole conference has really cheered me up after some moronic stuff at work. Feb 09 20:13:22 the kernel side of a Glamo 3D driver (DRM) is in place already, although there are some lose ends of KMS to tie up Feb 09 20:15:21 "the kernel side of a Glamo 3D"... you're talking about a new driver? Feb 09 20:15:25 if you're interested, there's a nice project of making the mplayer Glamo driver work using DRI, which wouldn't require any NDAs Feb 09 20:16:41 ThibG: I mean pushing the command queue and VRAM handling down to the kernel level, then rewriting xf86-video-glamo to use that instead of doing those things itself. that means other accelerated programs can use the accelerator without conflicting with X's acceleration (EXA). that's already done - if you flash a DRM-enabled kernel on SHR-t or SHR-u, you'll be using the KMS stack Feb 09 20:17:06 the 3D part of this is writing a Mesa driver which uses that kernel interface to do 3D graphics - a big task Feb 09 20:17:39 you mean, until now, everything was done in userspace? Feb 09 20:17:52 (the KMS kernel is WSoDdy for many people though - hoping to fix that once and for all in 2.6.32) Feb 09 20:17:57 ThibG: yep Feb 09 20:18:12 outch ok Feb 09 20:18:17 good news, then :) Feb 09 20:18:38 definitely Feb 09 20:18:57 It's hard to find people to work on Glamo? Feb 09 20:19:44 that's all been in place for some months.. xf86-video-glamo detects whether KMS is available or not at runtime, and switches between essentially two completely separate driver paths, one using DRM, the other doing it all in userspace Feb 09 20:20:19 Is the 2D acceleration functional already? Feb 09 20:20:28 I've been pondering on why e17 scrolling can be a bit slow. Feb 09 20:20:40 azaghal: yep.. there are many reasons not to (limited life span of hardware, no successor, relatively low performance etc etc), but for me it's still a nice exercise. I also figured: nothing is forever :) Feb 09 20:21:14 Heheh Feb 09 20:21:36 2D acceleration via EXA is there already, the problem is that EXA's model is a lousy match for, say, GTK (GTK actually goes slower with this acceleration than without). E makes hardly any use of EXA at all- in fact, it mostly avoids it on purpose Feb 09 20:22:01 with better hardware, you generally get away with EXA+GTK being a complete disaster. we don't have that luxury Feb 09 20:22:37 scrolling the contacts list gets a whole lot nicer with DRM, by the way (proper "fencing" means that the CPU can be idle while the GPU moves blocks around) Feb 09 20:22:38 I know that at some point the official Openmoko e17 scrolled faster than SHR one. Feb 09 20:22:57 themes have a big influence as well I think Feb 09 20:23:17 Hm... Well, not too fancy effects at that time Feb 09 20:23:24 also there's this E engine thing: software vs software_16 - the former pushing twice as much data as necessary down the small pipe to Glamo Feb 09 20:23:52 I see. So the bus becomes a tight spot? Feb 09 20:23:58 most definitely Feb 09 20:24:29 that's *the* reason for all the Glamo doom Feb 09 20:24:41 ~glamo Feb 09 20:24:41 i heard glamo is http://www.google.com/search?q=site%3Alists.openmoko.org+glamo+raster Feb 09 20:25:14 but this *type* of problem exists for everyone - if you go to listen to (say) Dave Airlie talking about Xorg acceleration, he'll say mostly the same things Feb 09 20:25:27 it's just that our numbers are so much smaller that it shows - *really* badly Feb 09 20:25:51 Hm, that's a pity. Feb 09 20:26:15 Have some proprietary manufacturers managed to work around it in their products? Feb 09 20:27:17 but if we made any meaningful use of the accelerator, things could work out quite nicely for us despite the Hardware of Doom. raster isn't prepared to write (or even discuss..) the platform specific code to do this, but I am. DRI gives us the framework to do it Feb 09 20:27:55 I think there's a combination of two factors: their buses are much faster than ours (maybe a factor of ten or so), and they're more likely to be making meaningful use of their GPUs Feb 09 20:28:48 Hm... What makes the whole thing platform-specific? I thought the X.org driver would provide kind of a unique interface? Feb 09 20:29:27 well.. anything I write is kind of obsolete already except for the people in this channel Feb 09 20:30:09 Ah Feb 09 20:30:30 I/we/anyone writing Glamo-specific code.. since the chip won't be used anywhere else, ever Feb 09 20:30:58 Hmph :/ Feb 09 20:31:18 What are the chances of using all the FSO stuff in other phones then? Mostly considering the GSM chips? Feb 09 20:31:52 personally, I don't see how that makes any difference.. if I enjoy coding it, and even a few people appreciate the result, or even just coming along for the journey if it doesn't end up where we'd hoped Feb 09 20:32:49 you'll need to talk to mickey|tv about FSO.. it looks likely that it'll be around for a long time in other hardware - it already supports more than just FR Feb 09 20:33:18 DocScrutinizer51: power drain is back.. interestingly, it came back after I rebooted via uBoot Feb 09 20:33:37 Yes, but remembering all the trouble on getting the GSM working in Neo... Feb 09 20:34:36 FR's modem is "special" as well Feb 09 20:34:56 Weiss: might be related to the way uSD IF is (not/) powered up on boot Feb 09 20:34:57 DocScrutinizer51: battery out, SD blank in, battery in, drain gone... Feb 09 20:35:17 ouch, the friggin bat Feb 09 20:35:31 could it be due to the battery being removed and replaced? (testing now) Feb 09 20:36:01 yeah hard to open the uSD holder with bat in Feb 09 20:36:35 * Weiss ponders something involving wires and crocodile clips in the name of science Feb 09 20:38:31 battery out, SD blank out, battery in -> drain back Feb 09 20:40:25 battery out, SD blank in, battery in -> drain gone Feb 09 20:40:51 Weiss: power up and down the uSD powersupply Feb 09 20:41:06 it's switchable Feb 09 20:42:05 Weiss: interesting Feb 09 20:42:27 larsc: trivial Feb 09 20:42:33 DocScrutinizer51: hmm.. one of the GPIOs? Feb 09 20:42:39 DocScrutinizer51: it is? Feb 09 20:42:56 Weiss: LDO of PMU? Feb 09 20:43:11 Weiss: regulator.9 Feb 09 20:43:26 nm about mplayer, forgot to 'modprobe snd-pcm-oss' Feb 09 20:43:51 fucing OSS Feb 09 20:45:08 larsc: hmm.. can it be turned off via sysfs? Feb 09 20:45:18 Weiss: no Feb 09 20:46:48 Weiss: did you reboot in between inserting and removing the sd card Feb 09 20:48:23 nope.. (actually it's a plastic blank, not an actual sD) Feb 09 20:48:33 larsc: he used no real uSD. rather an isolator Feb 09 20:48:44 even more interesting Feb 09 20:49:04 if there is no card present the sd regulator should be off Feb 09 20:50:01 DocScrutinizer51: beg your pardon? Feb 09 20:50:46 root@om-gta02 ~ $ cat /sys/class/regulator/regulator.9/state Feb 09 20:50:46 enabled Feb 09 20:50:50 kde4.4 released akonadi with sqlite backend support Feb 09 20:51:09 so, I have smth to play with pim Feb 09 20:51:09 Weiss: hm... Feb 09 20:51:27 Weiss: num_users is 1? Feb 09 20:51:45 DocScrutinizer51: forgive my ignorance (I don't know much about the PMU) - can I turn it off with "pmu"? Feb 09 20:51:49 larsc: yep Feb 09 20:53:54 Weiss: dunno right now. Feb 09 20:54:25 Weiss: I'd guess you can Feb 09 20:56:09 Weiss: are you using the latest 2.6.32? Feb 09 20:56:26 larsc: yep (at least as of a few days ago), SHR's configuration (no KMS/DRM) Feb 09 20:57:08 if that regulator should have been switched off, that might explain why I didn't see it with 2.6.29 Feb 09 20:57:23 (although, maybe I didn't try quite hard enough to replicate) Feb 09 20:57:49 badcloud: huh? Feb 09 21:00:07 Weiss: what happens if you unbind the mmc driver? Feb 09 21:00:40 "21:43 < DocScrutinizer51> fucing OSS" Feb 09 21:01:00 OSS is deprecated Feb 09 21:02:02 granted, but I can't seem to get mplayer glamo to work with alsa for some reason Feb 09 21:02:46 * Weiss is reasonably sure this has nothing to do with the *video* driver.. Feb 09 21:03:00 thanks for the tipoff, Weiss Feb 09 21:03:08 ;) Feb 09 21:03:11 hehe Feb 09 21:03:22 it definitely works with -vo somethingelse? Feb 09 21:03:27 (-vo null?) Feb 09 21:03:47 haven't tried the video yet Feb 09 21:03:49 just audio Feb 09 21:04:18 and it displays "Could not open/initialize audio device -> no sound." Feb 09 21:04:27 whereas oss works fine Feb 09 21:04:44 ideas? Feb 09 21:06:47 alsa not setup properly? Feb 09 21:09:38 larsc: hmm.. what's the magic incantation for that? Feb 09 21:09:54 (if you know.. feel free to answer "figure it out yourself) Feb 09 21:11:13 Weiss: for unbinding? echo glamo-mci.0 > /sys/bus/platfrom/drivers/glamo-mci/unbind Feb 09 21:12:34 DocScrutinizer51: i still can't understand how 400mA can go nowhere Feb 09 21:13:14 well, they turn into heat ;) Feb 09 21:13:19 PaulFertser: uSD VDD short to GND? Feb 09 21:14:21 DocScrutinizer51: oh, that'd explain it. But is metal holder pressing on pins when there's no card? Feb 09 21:14:34 PaulFertser: I think in mine it's very possible.. Feb 09 21:14:50 Weiss: i thought you did your tests with SD in. Feb 09 21:15:18 nope.. actually this FR hasn't seen an SD since flashing 2.6.32 (which may go some way to explaining things) Feb 09 21:17:53 larsc: no change on initial test.. Feb 09 21:17:57 hum. just booted without an sd card and the regulator is on too :/ Feb 09 21:18:15 larsc: any crazy current leaks? Feb 09 21:19:03 yes Feb 09 21:19:13 290 instead of 200 Feb 09 21:19:34 hmm.. a current leak, but not crazy :) Feb 09 21:21:29 azaghal: that's a given Feb 09 21:21:30 well have fun mates. Me more for my beer now, rather than irc Feb 09 21:21:41 mmm beer... Feb 09 21:21:47 thanks for all the help :D Feb 09 21:21:50 but where do I look to fix it? Feb 09 21:22:03