**** BEGIN LOGGING AT Tue Sep 02 02:59:56 2008 Sep 02 06:43:37 morning Sep 02 08:52:23 freesmartphone.org: 03mickey 07framework * r76700a094eec 10/ (2 files in 2 dirs): oeventsd: add 'blink' action to LedAction, adjust rules file Sep 02 09:16:24 hi Sep 02 09:19:05 hello aleix Sep 02 10:01:30 when fiddling with tangoGPS under Debian, I note that incoming calls don't cause the answer prompt to appear above tangogps (making it pretty much imposible to answer the call) -- is that something that should be expected at present? any hints where would need to look to fix that? Sep 02 10:04:22 fil: doing alt-tab on the keyboard should allow you to switch windows Sep 02 10:14:01 pabs3: on external usb keyboard? Sep 02 10:14:42 or the matchbox one Sep 02 10:15:47 pabs3: it doesn't work from matchbox-keyboard for me. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497438 Sep 02 10:26:40 pabs3: yeah, I'm aware of that -- that's far from good enough if you're out for a walk, and the phone starts ringing in your pocket (i.e. get it out, hit the AUX key to get a keyboard, fail to hit Alt-TAB a couple of times with you finger, flip screens via an xterm or two, finally miss call :-( ) Sep 02 10:30:10 fil: sure, zhone is just a demo ui though IIRC Sep 02 10:32:14 pabs3: can you try to reproduce my bug? Sep 02 10:32:37 will once I get the SD booted :/ Sep 02 10:33:38 pabs3: sure -- so I take it that matchbox is what needs to be prodded to get zhone back on top at this point -- it seriously diminishes the usefulness of the device if running any other program on it sabotages one's ability to answer incoming calls Sep 02 10:34:10 Hi. Has someone cooked up a patch for http://trac.freesmartphone.org/ticket/122 already? (AT%N0187 for frameworkd?) Sep 02 10:34:39 fil, pabs3: Is this the Debian channel takeover? :-) Sep 02 10:34:50 * pabs3 muahahahhaha Sep 02 10:35:29 fil: qtopia is probably the better image/ui for actual use at this stage (IMO) Sep 02 10:35:58 pabs3: yeah, but I want Debian on my phone :-) Sep 02 10:36:16 :) Sep 02 10:36:36 nomeata: i can cook something up but it won't be official :) Sep 02 10:37:29 nomeata: oh and thanks for writing a new patch for #110 Sep 02 10:37:38 lindi-: well, if you have a patch that looks good and works, submit it upstream (via bug and/or mailing list), and we can probably put it in the Debian packge early Sep 02 10:37:54 fil: just package qtopia for debian :-) Sep 02 10:38:47 lindi-: gah, somehow I corrupted my sd card partition table, reinstall time Sep 02 10:38:55 pabs3: just fdisk? Sep 02 10:40:08 pabs3: you can use http://iki.fi/lindi/find-superblock.c to find out where your ext2 partition starts Sep 02 10:40:25 thanks Sep 02 10:40:59 and the official installer probably puts it always to a predicatable place? Sep 02 10:41:54 pabs3: you can run the installer with only partition stage, this will leave your file systems in tact Sep 02 10:42:00 nomeata: can you reproduce http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497438 ? i keep wondering how you switch between applications (i had to enable mb title bar for that) Sep 02 10:42:28 pabs3: there is a known problem with suspend and SD cards in some case, I heared on the openmoko mailing lists Sep 02 10:42:35 nomeata: I've not played with qtopia, but my assumption was that it was aimed at producing a fairly normal smartphone, which I'm pretty sure isn't what I want -- I want a Debian computer in my pocket that will pretend to be a phone just enough to let me reliably answer, occasionally make, phone calls Sep 02 10:43:00 nomeata: kernel issue or? Sep 02 10:43:06 nomeata: how about putting the partition information inside uboot on nand? Sep 02 10:43:15 lindi-: haven’t tried, but Alt-Tab has never failed me Sep 02 10:43:21 nomeata: weird Sep 02 10:43:29 fil: Add to that support for receiving and occasionally sending SMS, and you get my "list of demands". Sep 02 10:43:32 nomeata: it doesn't work under x86 either for me Sep 02 10:44:13 pabs3: it’s the Clock-Signal-Disabling for GPS, that sometimes does not grant enough clock cycles to the card Sep 02 10:44:54 pabs3: so what people do is to have a apm wrapper that disables this feature (thus enabling the clock line) before suspend, and re-enable it afterwards Sep 02 10:45:03 pabs3: but it ought to be fixed properly in the kernel Sep 02 10:45:29 lindi-: so alt-tab doesn’t work for you eitherß Sep 02 10:46:36 lindi-: s/ß/?/ Sep 02 10:46:46 nice, stealing the fdisk command from install.sh got me back the partitions Sep 02 10:47:03 nomeata: correct Sep 02 10:49:45 Viiru: yeah, SMS might be nice too -- especially once I've got it to silently discard all the "welcome to France..." crap one gets when roaming Sep 02 10:52:33 is SMS send/receive supposed to work under FSO ? Sep 02 10:52:40 fil: Oh yes. Should be quite easy to do. Sep 02 10:52:56 freesmartphone.org: 03mickey 07zhone * r4e301b6bef62 10/ (ChangeLog src/zhone): Sep 02 10:52:56 freesmartphone.org: fix number comparison, patch courtesy Joachim Breitner. Sep 02 10:52:56 freesmartphone.org: closes FSO #110 Sep 02 10:53:07 lindi-: I could confirm the bug, appended to the bug report Sep 02 10:53:11 mickey|bbl: thx for applying Sep 02 10:53:26 polz: yes, SMS ought to work Sep 02 10:55:37 * nomeata → lunch. cu later. Sep 02 10:55:59 that's interesting. Sep 02 10:56:10 mickey|bbl: thanks for applying too :-) Sep 02 11:13:54 lindi-: alt+n switches windows on my debian+om Sep 02 11:14:10 lindi-: are you sure matchbox-window-manager is running?? Sep 02 11:16:35 pabs3: yes Sep 02 11:16:40 pabs3: are you using xorg? Sep 02 11:17:02 I believe the debian install.sh installs that, yeah Sep 02 11:17:08 odd Sep 02 11:18:23 yep, uses xor Sep 02 11:18:24 g Sep 02 11:18:44 very odd then, as i can reproduce the bug even with vncserver on my x86 system Sep 02 11:41:44 Hmm, just ran twinkle (SIP client) in the freerunner -- it works, except for the fact that the Mic isn't doing anything more than providing a local echo -- any clues why? Sep 02 11:47:59 seems like it's an ALSA issue, as arecord is recording silence Sep 02 12:22:10 fil: already solved it? Sep 02 12:22:20 * lindi- just installed invisible shield Sep 02 12:24:20 lindi-: nope -- been fidling with alsamixer to no effect :-/ Sep 02 12:24:45 fil: i can try in 12 hours when i can start my freerunner again Sep 02 14:08:27 hello, which program in 2008.8 is responsible for turning on the backlight when the screen is tapped? Sep 02 14:08:43 what is the easiest way to prevent the backlight from turning on when the screen is locked? Sep 02 14:12:10 x Sep 02 14:12:36 same thing that turns your desktop screen on when u move the mouse, press it or press a key Sep 02 14:12:36 :) Sep 02 14:12:57 :) Sep 02 14:13:21 i just figured out it doesn't turn it on when backlight in sysfs is 0 Sep 02 14:13:32 it just dims the actual_brightness Sep 02 14:13:51 and what is the "lock" thing? is that some illume stuff? Sep 02 14:14:27 yes Sep 02 17:06:39 i'm new to python (and openmoko), but this doesn't really look like a mistake in my script: Sep 02 17:06:41 import gtk Sep 02 17:06:41 #create a (nonvisible) window Sep 02 17:06:41 w = gtk.Window() Sep 02 17:06:41 #create a button (not yet on any window) Sep 02 17:06:41 b = gtk.Button('Hello') Sep 02 17:06:42 #put the button on the window Sep 02 17:06:44 w.add(b) Sep 02 17:06:46 #create a silly callback function Sep 02 17:06:50 def hello(target): Sep 02 17:06:52 print 'Hello world' Sep 02 17:06:54 exit() Sep 02 17:06:56 #make the button call the callback when pressed Sep 02 17:06:58 b.connect('clicked', hello) Sep 02 17:07:00 #make the window display Sep 02 17:07:02 w.show_all() Sep 02 17:07:04 #start processing screen events Sep 02 17:07:06 gtk.main() Sep 02 17:07:08 eh ok that looks bad sry Sep 02 17:07:12 it basically is "NameError: name 'init' is not defined" Sep 02 17:07:17 might I suggest using a paste bin Sep 02 17:07:24 y sry Sep 02 17:08:55 johnsu01: looks like this channel is the bin.. Sep 02 17:10:54 y sry really :/ Sep 02 17:11:15 so could someone tell me what this: http://howflow.com/pastes/558 Sep 02 17:11:16 is Sep 02 17:15:35 okay nevermind, googled it up Sep 02 17:15:53 having to change init() to _init() in that bloody script Sep 02 17:36:39 hello Sep 02 17:42:14 aleix: hi Sep 02 18:08:58 wurp2|working: hey. with the latest updates to the shr repo (dialer3 linking fixes) i have built and shr image...can not tried though :-) Sep 02 18:09:24 wurp2|working: AndreasD fixed it Sep 02 18:26:53 aleix: OK, I will run the build tonight Sep 02 18:30:49 wurp2|working: I am now adding the cp-over-fso (it was a directory) automatically to the shr-image.bb Sep 02 18:31:30 wurp2|working: not sure if needed though... Sep 02 19:06:17 Ainulindale: How do I get patches into lfg in git.freesmartphone.org? Sep 02 20:06:05 Hey Sep 02 20:08:21 Does anyone know which dialer is used in ASU / 2008.8 ? A qtopia dialer? Sep 02 20:10:23 wurp2|working, Ainulindale, any knowledge about that? :) Sep 02 20:12:24 quickdev: I thought it was the OM version of the X11 fork of Qtopia Sep 02 20:13:00 wurp2|working, but not an enlightenment or gtk dialer? Sep 02 20:13:12 Not afaik Sep 02 20:13:29 You could install the gtk dialer on it, but it wouldn't get along with the Qtopia dialer Sep 02 20:13:34 Both expect access to the hardware Sep 02 20:14:54 wurp2|working, I'm thinking about programming a enlightenment dialer Sep 02 20:15:40 make it a rotary dialer Sep 02 20:18:35 +1 (rotary dialer) Sep 02 20:18:42 ;) Sep 02 20:21:08 quickdev: Isn't zhone an enlightenment dialer? Sep 02 20:21:53 yes, but I doubt if it's ever used in production. which alternatives are there at the moment? Sep 02 20:22:07 Well, why not fork off zhone? Sep 02 20:22:42 I used zhone from MS1 as my primary phone for about 2 weeks Sep 02 20:22:58 It was great, except for the lack of anything else, including an address book Sep 02 20:23:39 And if you fork from zhone, you get a bunch of features already done for you, and Mickey might accept many of your changes back into zhone Sep 02 20:25:15 will think about it Sep 02 20:26:36 And your dialer will work on shr when it gets released :-) Sep 02 21:07:14 rotary dialer :) that would be awesome Sep 02 22:01:44 hi * Sep 02 22:02:01 Hi :-) Sep 02 22:02:07 Have you looked at the SHR wiki page? Sep 02 22:02:26 If you can sign up for the shr project in the next 20 min or so I can get you approved right away Sep 02 22:02:28 wurp2|working: Good job, now we have another victim lured into our sacred halls! Sep 02 22:02:33 Otherwise it may be a few hours Sep 02 22:02:42 abraxa_: >;-) Sep 02 22:03:02 lol Sep 02 22:03:02 admiral0: I prefer python too Sep 02 22:03:09 but dialer3 is in C Sep 02 22:03:31 np Sep 02 22:03:55 i'll just be a little slower... Sep 02 22:04:50 No problem Sep 02 22:05:00 A little slower will be much faster than things are moving right now :-) Sep 02 22:05:07 :D Sep 02 22:06:21 anyone of bearstech here? Sep 02 22:06:36 I don't think so Sep 02 22:06:41 We have email addys for them Sep 02 22:06:54 i bought my FR from them Sep 02 22:06:54 If you look in the shr-devel archives you can see 'em Sep 02 22:07:00 Oh, cool! Sep 02 22:07:33 btw, FSO builds from shr.bearstech don't work Sep 02 22:08:06 I actually didn't know shr.bearstech hosted fso... Sep 02 22:09:13 I see some talk about it now on the ML Sep 02 22:09:25 Some people have had success in the past Sep 02 22:12:37 The way we're supposed to be building now (for SHR) is with mokomakefile Sep 02 22:12:48 I'm not sure what repository it uses for basic FSO stuff Sep 02 22:15:25 ok Sep 02 22:15:32 submitted request Sep 02 22:15:34 admiral0: approved Sep 02 22:16:10 :D Sep 02 22:19:34 i could start building tommorrow. and then i'll try to port contacts Sep 02 22:20:24 admiral0: Excellent!! Sep 02 22:20:32 Create contacts3 as a copy of 2007.2's contacts2 and get it compiling (comment out phonekit calls) Not started Nobody yet Nobody yet 2008-08-07 Sep 02 22:20:32 I think there is already something started for contacts Sep 02 22:20:42 Check for contacts3 Sep 02 22:20:48 ok Sep 02 22:21:08 Also, please announce your intentions on shr-devel so you can work with people if someone has already started it Sep 02 22:21:22 k Sep 02 22:21:47 now i'll go to sleep... i'm working tommorrow Sep 02 22:22:13 good night Sep 02 22:22:37 g'night Sep 02 22:32:42 Is there a method by which an OM application can control the backlight brightness other than by writing directly to the /sys/.../brightness file? Is there a higher-level interface, preferably one that is phone-model independent? Sep 02 22:35:08 Ken_Young: FSO's odeviced Sep 02 22:36:18 abraxa_, Is that part of dbus? Sep 02 22:37:04 Ken_Young: odeviced provides a D-Bus interface, if that's what you meant to ask Sep 02 22:38:56 abraxa_, Yes, that's what I was asking. Thanks. So I take it that interface is not available for aps running atop OM 2008.8? Sep 02 22:40:03 Ken_Young: Unfortunately, that's correct Sep 02 22:40:25 abraxa_, OK, thanks again for the info! Sep 02 22:40:43 np Sep 02 23:11:49 abraxa_, Is there an "official" way for an application to know if it is running atop FSO? I want to write an application which will run on 2007.2, 2008.8 and FSO. If I need to use a different interface on FSO, what's the best way for the code to know that's the active stack? Sep 02 23:12:38 Ken_Young: python or C/C++? Sep 02 23:13:01 plain ol' C. Sep 02 23:14:05 I suppose the most straightforward way would be to use D-Bus and try to communicate with frameworkd.. Sep 02 23:14:51 D-Bus is working at some level on all three of those distributions, isn't it? Sep 02 23:15:42 Oh, but I guess frameworkd only exists on FSO, right? Sep 02 23:48:02 Finally my GTA02 arrived last weekend :-) Did a lot of experimentation already, however didn't bother to connect the debug board yet. Sep 02 23:48:30 not that useful unless u want to debug below the kernel Sep 02 23:50:44 raster, is it possible for application code to make a call to the X11 server that will make it change the "visual" globally? Sep 02 23:50:46 Well, I want to hack on the Glamo, eventually implementing OpenGL ES with it, i.e. doing 3D below the X-level. So there's some need for a dev board. I also intend to implement my own framework. Based on Gentoo. To save flashing I want to boot from RAM and rootfs on NFS via USB networking. Sep 02 23:51:35 @Ken_Young: Changing the visual of the root window should do the trick Sep 02 23:52:20 hexarith, Thanks - is there an xlib call that does that? Sep 02 23:52:24 However only newly created windows parented by the rootwindow upon creation will get the change. Sep 02 23:52:55 hexarith, Oh, I'm afraid that won't work for me then. Sep 02 23:53:19 There's not much protection between X resources, regarding different processes. You just set the visual for the root window ID like you would for any other windet. Sep 02 23:53:25 s/windet/window/ Sep 02 23:54:55 You can do a lot of crazy stuff with the X protocoll, like ripping a subwindow out of an applications main window and embedding into your own. That's kinda like the mediaplayer plugins for webbrowsers work in Linux. The player runs as own process, but the window gets embedded into the browser. Sep 02 23:56:27 hexarith, Yeah, I know it's possible to make a real mess of things, and that clients are not well protected from each other. Sep 02 23:57:23 Silly question: Is there are snapshot of all the changes/patches, but only those, that openmoko made to the kernel. I just cloned the git-tree and I'm a bit lost here, doing a "git-diff -p origin/andy master" spits out a lot more than what I want... Sep 03 00:02:11 And another question: With the kernel "Linux om-gta02 2.6.24 #1 PREEMPT Thu Aug 7 15:57:11 CST 2008 armv4tl unknown", when doing a scan for WLANs, but none are in range the scan errors with "resource temporarily anavaliable". Is that a known bug? Fixed in the git-tree? Sep 03 00:18:40 mickey|bbl: ping - did you contact Ken_Young regarding orrery autoconf for fso? Sep 03 00:56:11 Ken_Young: no - apps are in charge of asking for whatever visual they want - and normally use the default, which is fixed. Sep 03 00:57:36 nex and good luck with doing a gles lib - as without an nda.. you have no specs. even the specs are pretty bad. Sep 03 00:57:40 if u have them Sep 03 00:58:02 and even then - the glamo has lots of limitations Sep 03 00:58:14 and it's an EOL chip (end of liofe) no future glamo2 will be made Sep 03 00:58:27 i see it thsi way Sep 03 00:58:38 "i have better things to spend my time on" :) Sep 03 00:58:45 but thats me Sep 03 00:58:49 i am short on time as-is Sep 03 00:58:57 raster, Thanks. I'm working on an application that is sometimes used in low light situations, I would like to be able to throw the display into a mode where all apps are displayed "grey-scale", but with levels of red rather than levels of grey, to preserve night-vision. Do you know if there's anyway to do that? Sep 03 00:59:14 no chance Sep 03 00:59:19 well ok Sep 03 00:59:21 yes - chance Sep 03 00:59:28 u will need to use compositing Sep 03 00:59:37 u cant modify existing app visuals - always been that way in x Sep 03 00:59:51 but u could have the composite manager process the pixels and convert to greyscale Sep 03 00:59:55 adjust gamma and other things Sep 03 00:59:56 BUT Sep 03 01:00:00 it will get SLOOOW Sep 03 01:00:02 very slow Sep 03 01:00:10 as u will need to do all this processing by reading pixesl from x Sep 03 01:00:12 doign it in the cpu Sep 03 01:00:14 writing back Sep 03 01:00:20 raster, slow to set up, or slow forever after the change? Sep 03 01:00:34 on FR that ermans reading from video ram (slow) Sep 03 01:00:38 and writing back (slow) Sep 03 01:00:42 as well as the cycles for converting Sep 03 01:00:44 AND Sep 03 01:00:56 for every pixel that changes on the display u have to do this Sep 03 01:00:59 so it will be slow to run Sep 03 01:01:04 continually Sep 03 01:01:07 not init Sep 03 01:01:12 every single update has to do that Sep 03 01:01:21 raster, OK, it sounds like it's a pipe-dream then. Thanks for letting me know. Sep 03 01:01:28 yeah Sep 03 01:01:32 it sucks - but its true Sep 03 01:01:40 if u had amazing amounts of processing power - u could Sep 03 01:01:44 like a desktop - it can Sep 03 01:01:51 at deskto pscreen res's (1600x1200 or so) Sep 03 01:01:53 I'll have to wait for the 16 core Freerunner. Sep 03 01:01:54 even there it will be sluggish Sep 03 01:02:02 but possible Sep 03 01:02:07 on the FR - i'd not even start Sep 03 01:02:27 i really feel for u guys Sep 03 01:02:35 all these ideas and well - reality of hardware gets in the way Sep 03 01:03:20 raster, But programming for a limited machine is more fun. Sep 03 01:03:30 that depends Sep 03 01:03:43 its only fun if that limited machine will be produced for a long time Sep 03 01:03:51 eg vic-20, c64, amiga, etc. Sep 03 01:03:57 ps2/ps3/psp ps1 Sep 03 01:04:02 but something like the Fr Sep 03 01:04:06 will be produced then replaced Sep 03 01:04:06 fast Sep 03 01:04:15 so then all your hacks dont port to a newer platform Sep 03 01:04:19 :( Sep 03 01:33:23 My application receives button_press_event events when I place my finger on the touch-screen, but not button_release_event events when I withdraw my finger. Is that normal? Is some other event produced at the end of a touch-screen tap? Sep 03 01:33:58 eh? Sep 03 01:34:02 thats strange Sep 03 01:34:03 it shoul;d Sep 03 01:34:13 all my code entirely relies on that Sep 03 01:34:15 and it works Sep 03 01:34:39 raster, I must be botching the call that connects my service routine then, somehow. Sep 03 01:35:12 @raster: Well, what would be neccesary to get hold of the specs. The Glamo might be limited, alright. But that doesn't mean you can't do cool things with it. Back in 1999 I implemented really nice reflective and refractive water rendering on a TNT2. Sep 03 01:36:37 hexarith: smedia has been asked repeatedly to open the specs Sep 03 01:36:39 and they wont Sep 03 01:36:46 thyey only opened them up under nda to om Sep 03 01:36:48 thats it Sep 03 01:36:55 they offered them to trolltech under nda Sep 03 01:37:01 but tt would need to pay $15,000 Sep 03 01:37:05 so tt declined Sep 03 01:40:00 Give them that link and point out, that AMD's stuff surely can do much more than their glamo... http://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu I will never get it: What do companies fear, that they don't open specs. Don't they realize, that they could sell a lot more of their shit, if developers knew what they get in advance? Sep 03 01:40:37 And I got fresh GTA02 now, I'm probably not going to get a new OpenMoko so soon. Sep 03 01:40:45 hexarith, Not if what they're selling really is shit. Sep 03 01:41:16 ZX80 did sell, too.... Sep 03 01:42:13 hexarith: amd's stuff is irrelevant as its not withint the same power envelope at all. Sep 03 01:42:33 I know, but the DO publish openly. Sep 03 01:42:53 you talk to smedia Sep 03 01:42:57 i thyink its a waste of time Sep 03 01:43:04 there are incredibly few FR's Sep 03 01:43:12 only a few thousand Sep 03 01:43:16 remember in the world of devices Sep 03 01:43:26 u are talking 100,000's or millions as a normal product run Sep 03 01:43:30 and there is no glamo 2 Sep 03 01:43:31 FR? don't know that acronym, sorry. Sep 03 01:43:37 there is no successor Sep 03 01:43:41 u live with glamo and its limits Sep 03 01:43:47 and there is no plan to use glamo in the future Sep 03 01:43:53 so its a dead chip as such Sep 03 01:44:01 so u can jump up and down on a principle Sep 03 01:44:05 but u'll get nowhere Sep 03 01:44:08 :( Sep 03 01:44:15 FR - freerunner Sep 03 01:44:19 (gta02) Sep 03 01:44:24 ah, silly me... Sep 03 01:44:29 i know what you mean Sep 03 01:44:35 i am just being practical Sep 03 01:45:20 I normally, too. But. I'm kinda the realtime 3D graphics guy. Probably one of the most active and constant posters in c.g.a.opengl Sep 03 01:45:41 do u know some of the gotchas on the glamo? Sep 03 01:45:45 like max text size 256x256 Sep 03 01:45:49 no render-to-texture Sep 03 01:45:53 So I really would like to do that on my GTA02. And I don't know if the CPU hat the guts to do it purely in software. Sep 03 01:46:06 max 3d buffer 511x511 (u cant manage fullscreen vga) Sep 03 01:46:19 and that is not including whatever the performance may or may not be Sep 03 01:46:52 compared to any other mobile gfx solution - glamo is far behind Sep 03 01:46:57 glamo is a 4+ year old chip Sep 03 01:47:00 4 years ago it was good Sep 03 01:47:10 today - it is not so good Sep 03 01:47:27 i have an inside line on something much mroe interestign than a glamo... something open Sep 03 01:47:29 prgrammable Sep 03 01:47:30 Yeah I know, but those are not really limits, if you know how to work around them. 256x256 is fine BTW. As a rule of thumb the maximum usefull texture resolution is 0.5 screen resolution (think Nyquist theorem). Sep 03 01:47:34 and not a gfx chip Sep 03 01:47:36 a co-processor Sep 03 01:47:41 it doesnt have a fb Sep 03 01:47:48 doesnt do vga/dvi or lcd controlling Sep 03 01:47:57 it is a raw lump of processing goodness Sep 03 01:48:05 Yeah, a Co-P would be great. Sep 03 01:48:09 with fully open compiler, instructionset and hw specs Sep 03 01:48:20 imagine (this is what iu can say right now) Sep 03 01:48:23 64mb of dram Sep 03 01:48:30 400mhz, 4 cores Sep 03 01:48:36 32mw power usage Sep 03 01:48:37 What would really kick ass were some kind of streaming SIMD parallel core. Sep 03 01:48:47 and that is pretty much it Sep 03 01:48:57 Does it exist? Sep 03 01:48:57 raster, Floating point? Sep 03 01:48:57 the rest is up to software compield for it and run on it Sep 03 01:49:01 Ken_Young: none. Sep 03 01:49:08 its incredibly simple Sep 03 01:49:08 raster, Zut! Sep 03 01:49:15 u can do fp Sep 03 01:49:18 it's be emulated Sep 03 01:49:21 it'd Sep 03 01:49:25 sorry to budge in here, but why did om go for glamo if they knew the limitations? cost-benefit...or what? Sep 03 01:49:28 its REALLY LOW POWER Sep 03 01:49:29 Doesn't matter, you will implement a rasterizer in fixed point anyway. Sep 03 01:49:30 32mw Sep 03 01:49:40 the samsung arm - when idle is 200mw+ Sep 03 01:49:59 do your fp and higeher level math on the soc Sep 03 01:50:01 on the cpu Sep 03 01:50:16 then just punt off all the footwork (blending, scaling, rasterising, tile processing) onto the co-proc Sep 03 01:50:30 u have 4 cores to play with and 64mb of onboard ram Sep 03 01:50:34 and.. unlike many designs Sep 03 01:50:42 Ok, when will be that thing avaliable. Give me some specs, so that I can implement a 3D rasterizer for that and an OpenGL layer. Sep 03 01:50:47 the dram and wired directly to the procs Sep 03 01:50:55 so incredibly low power and low low latency Sep 03 01:51:00 massive mem bandwidth Sep 03 01:51:12 available - going into silicon soon Sep 03 01:51:18 right now you do need an nda Sep 03 01:51:22 cool. Sep 03 01:51:32 but they have asked me to look at doing a kdrive driver for it - open Sep 03 01:51:34 and doing rotuines Sep 03 01:51:36 all open Sep 03 01:51:44 and the sdk is not open right now - but build on sdcc Sep 03 01:51:49 (small device c compiler) Sep 03 01:51:52 and will be open Sep 03 01:51:56 the intent is to play the open game Sep 03 01:52:04 and not just gfx Sep 03 01:52:11 its a generic co-proc Sep 03 01:52:26 anythign thats memory-intensive would get a huge boost from grunt-work being done there Sep 03 01:52:36 Could I help? google groups comp.graphics.api.opengl for "Wolfgang Draxinger" - that's me - for hint on my experience. Sep 03 01:53:03 .so you'd like to implement a gl rasteriser for it? Sep 03 01:53:11 readily Sep 03 01:53:14 ok Sep 03 01:53:21 let me see when slicon is coming Sep 03 01:53:59 rememebr the cpu is very simple Sep 03 01:54:00 32bit Sep 03 01:54:10 but it only has 32 instructions Sep 03 01:54:25 so it will take more insts than your average arm to do the same thing Sep 03 01:54:34 but all instructions are 1 cycle i thnik Sep 03 01:54:55 and this is the first gen Sep 03 01:55:06 next gen should have more ram (looking at 1gb) and 64 cores Sep 03 01:55:10 and up to 1ghz Sep 03 01:55:14 and still low power Sep 03 01:55:41 it doesnt even have a div instr Sep 03 01:55:47 only a 16x16 mul Sep 03 01:56:33 You don't use DIV in graphics anyway. Too slow. Sep 03 01:56:53 i know Sep 03 01:56:59 its just an example of how simple it is Sep 03 01:57:04 its basically a dram chip Sep 03 01:57:09 ARM doesn' t have div, does it? Sep 03 01:57:09 WITH processors on it Sep 03 01:57:14 If you really must, you calculate the reciproc once, and then always multiply with that (prescalers and so). Sep 03 01:57:15 rather than a cpu with some ram on it Sep 03 01:57:39 its also really cheap Sep 03 01:57:45 much cheaper than the glamo Sep 03 01:57:51 with a LOT mroe ram Sep 03 01:57:59 and what looks to me incredibly more processing power Sep 03 01:58:03 less power usage Sep 03 01:58:09 Well, RAM with some ALUs, that is just the thing. As long as each ALU can access large parts of the RAM Sep 03 01:58:18 and you can just use your regular dumb-fb that your soc has Sep 03 01:58:39 and all alu's can access all of its local 64mb ram Sep 03 01:58:47 its 32bit so they can in theory go up to 4g Sep 03 01:58:53 but for now - just 64m Sep 03 01:58:57 So, the memory contents get MemMapped into the Addresses that the kernel allocates for FB? Sep 03 01:59:05 they cant access ram outside its local mem Sep 03 01:59:14 Well, no problem. Sep 03 01:59:15 so the host cpu needs to copy all data to/from the mem Sep 03 01:59:22 but its a regular ram chip in that regard Sep 03 01:59:28 so its like a memcpy() anywhere else Sep 03 01:59:30 That's not different to any other GPU Sep 03 01:59:47 wel different in that it is actually a dram chip Sep 03 02:00:00 as opposed to a cpu Sep 03 02:00:07 different manfuacturing tech. Sep 03 02:00:09 and design Sep 03 02:00:17 Sounds great. OpenGL has this API VertexBufferObjects PixelBufferObjects which you use to allocate special portions of memory. Sep 03 02:00:30 :) Sep 03 02:00:31 This memory could be allocated from that Brainy-RAM. Sep 03 02:00:36 the problem it has - no interrupts right now Sep 03 02:00:46 so u have no idea when some operation is finished Sep 03 02:00:59 u have to poll a mem location for status from the host cpu Sep 03 02:01:11 it also doesnt have generic bitshift Sep 03 02:01:29 glFinish blocks, so you can give process control to the kernel and the scheduler can test if some sync bit has been set. Sep 03 02:02:01 it has a simple >> 1 and << 8 instr Sep 03 02:02:03 thats it Sep 03 02:02:13 no barrel shifter? Sep 03 02:02:18 not generic Sep 03 02:02:24 i am tryign to get them to change this Sep 03 02:02:32 but it can do multiplies? Sep 03 02:02:35 drop the 2 specifc shifts for a generic barrel shifter Sep 03 02:02:40 it can do 16x16 muls Sep 03 02:03:34 ok, << i can be implemented by mul 2^i. Funny, I usually tend to program 2^i as < sure Sep 03 02:03:48 i do too Sep 03 02:03:52 i love arms Sep 03 02:04:02 the shift while load/save etc. is great Sep 03 02:04:16 i actually would like a generic bit-remap Sep 03 02:04:37 ie "take bits 21-26 and remap to bits 10-15" Sep 03 02:04:39 BTW, I asked before already: Is there some snapshot of all GTA02 related patches to the kernel, but only the patches? Sep 03 02:05:08 git-diff origin/andy master spits out a lot more stuff... Sep 03 02:05:44 so basically a dst = dst & (~mask) | ((src >> shift) & mask) Sep 03 02:06:37 but really in silicon wired just as a bit-redirector take a run of n buts from a srec and replace another run of them in dst Sep 03 02:07:33 that'd cover generic shifting/rotating (if the remapper allows for wrap-around) and be damn handy for colorspace conversions, simd fixt-point math etc. **** ENDING LOGGING AT Wed Sep 03 02:59:57 2008