Re: Very fast power drain, hot device
On Fri, 23 Mar 2012 12:19:34 + shamsul hassan shamsulbu...@gmail.com wrote: I had the problem in my N900 and what it turns out to be was that one of the DBUS processes was getting stuck and consuming all the CPU all the time. Use TOP to figure out CPU load for 1/5/15 mins and check out any of the processes which are consuming high cpu percentage. Check for this, as well: http://www.bitwiz.org.uk/s/2010/02/the-mysterious-missing-milliamps.html Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner and Wayland
On Thu, 7 Jul 2011 18:05:02 +0100 Neil Jerram neiljer...@gmail.com wrote: Just wondering... is it at all feasible, in the nearish future, for Wayland to run on the Freerunner? I mean directly on KMS, not as an X client. Would there be any advantage to that, compared to the current X usage? I'm imagining it might perform better, but I don't really know. It's feasible, but not easy. Wayland is essentially a thin wrapper around the low-level DRM and KMS stuff allowing clients to submit hardware command sequences directly rather than going via X's acceleration pathways. A lot of the performance difficulties with the X pathway (not just on our hardware) seem to be because the server can't possibly know enough about what the client wants to accelerate it effectively. Fast and smooth graphics on the Freerunner should be perfectly possible, but would rely on exactly this kind of clairvoyance from the X server. So, getting Wayland to run on its own shouldn't be too difficult (famous last words..), but writing programs which can actually make use of it is significantly more difficult. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: glamo gdrm,
On Mon, 31 May 2010 22:23:15 +0200 mobi phil m...@mobiphil.com wrote: crtc-mode.vrefresh = 8952 ; crtc-mode.hdisplay = 640 ; crtc-mode.hsync_start = 656 ; crtc-mode.hsync_end = 752 ; crtc-mode.htotal = 800 ; crtc-mode.vdisplay = 480 ; crtc-mode.vsync_start = 490 ; crtc-mode.vsync_end = 492 ; crtc-mode.vtotal = 525 ; crtc-mode.clock = 2518; now I have the landscape mode with drm, but it seems that the same problem as was earlier with pixels shifted. The full fb seems to be shifted -100 on x. This is true if I draw to the mapped fb, or if I do accelerated commands. Modesetting on Glamo is a menace. One tiny false move and either the GPU or the LCM will get upset and decide not to talk to you any more. Here are my numbers for rotated operation. Your rotated display probably comes from your timings being out by a bit. mode.vrefresh = 0 mode.hdisplay = 640 mode.hsync_start = 656 mode.hsync_end = 658 mode.htotal = 660 mode.vdisplay = 480 mode.vsync_start = 496 mode.vsync_end = 504 mode.vtotal = 512 mode.clock = 2450 Currently, KMS doesn't have the concept of rotation, so what goes on to make this work is a horrendous hack, and only supports one landscape orientation (rotated clockwise). Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: andy-tracking and gdrm-2.6.32
On Mon, 17 May 2010 14:00:13 +0200 mobi phil m...@mobiphil.com wrote: Was not aware about the repo on Thomas's site. Will try bluetooth with the mentioned reference (gdrm-for-merging). Watch out - there's a huge problem with command queue handling in gdrm-for-merging which I haven't had a chance to sit down and fix yet.. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: andy-tracking and gdrm-2.6.32
On Mon, 17 May 2010 20:24:14 +0200 mobi phil m...@mobiphil.com wrote: maybe then merging gdrm stuff from gdrm branch from git.openmoko.org and rest from gdrm-for-merging? or what would be the best to merge to have both stable 2.6.32 and drm/kms? It's nothing to do with merging, I just made a new branch, cleaned up and more suitable for merging back to the main OM branch, and in the process I introduced a bug which I haven't fixed yet. Not quite sure what you meant by merging bits of the old and new gdrm branches, but that certainly won't magically make the problem go away. The best merge to do if you want everything vaguely stable would be to merge gdrm-2.6.32 into om-2.6.32. The merge may or may not be easy.. (that's why gdrm-for-merging exists in the first place). Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: drm/glamo Re: glamo backlight
On Tue, 13 Apr 2010 02:36:56 +0200 mobi phil m...@mobiphil.com wrote: after successful booting and running the gdrm-waitq example I got on the log: glamo-drm: Fence seq#157 was not signalled (with increasing #ref numbers) and usb network seems to be frozen after second reboot and running intensive directfb test applications problem cannot be reproduced... That would indicate that Glamo's interrupt (or the kernel's handling of it) is misbehaving. It tries pretty hard to recover from that situation, but obviously not hard enough. I've committed a patch which will make it try a little harder still. Hopefully it was just a glitch. directfb and other frambuffer applications run on /dev/fb0, however the old bug with display shift to the right is again present. (everything is shifted ~150 pixels to the left) You're right - the patch which fixed that got lost somewhere. I've re-applied it in the latest version, so if you could test it, that'd be great. Thanks a lot, Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rutgers University writes malware for Freerunner
On Mon, 22 Feb 2010 22:38:36 + Neil Jerram neiljer...@googlemail.com wrote: I was on the verge of writing the same thing. Are they claiming that they can install a rootkit remotely by sending a carefully crafted SMS? (Seems unlikely, given the small number of bytes to play with.) Or that once a rootkit is installed, they can use SMS as a trigger for it? If the latter, how do they get the rootkit on there in the first place? From one of the linked articles: http://news.rutgers.edu/medrel/news-releases/2010/02/rutgers-researchers-20100222 --- The researchers are careful to note that they did not assess how vulnerable specific types of smart phones are. They did their work on a phone used primarily by software developers versus commercial phone users. Working within a legitimate software development environment, they deliberately inserted rootkit malware into the phone to study its potential effects. They did not find a vulnerability that a real malware attacker would have to exploit. --- So, it's nothing we have to worry about - in fact, some free publicity... Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] New significant speedups coming to FreeRunner
On Tue, 16 Feb 2010 16:19:08 +0100 David Garabana Barro da...@garabana.com wrote: Now i just change a few kernel config options and few line patch (thanks to Thomas White) and the graphics speed is very nice. In QVGA it can probably match iPhone or any Android device. No, it can't, at least until we have an OpenGL driver. But it's true that using VGA resolution is a handicap for such a slow graphics chip, and it would be better QVGA for this hardware. A small point, but there are things we can do along the way to a full GL driver which speed things up, and I don't think we've found them all just yet. For instance, adding proper fencing in the DRM driver unclogs things by a fairly noticable amount: fullscreen (VGA) blits at 100fps with 0% CPU usage, anyone? Fact is that glamo is a graphics decelerator. It's known that Neo1973 was faster than FreeRunner on graphics (even on VGA), despite of slower processor. Yes, the bus speed is a fundamental limitation, and it does suck. But there are other reasons (see below) why the current driver and rendering model is a bad match for the hardware. In fact, it's a bad match for almost all hardware, it's just that normally the overall speed is high enough to get away with it. We haven't yet allowed ourselves to make meaningful use of the acceleration features, and I'm absolutely convinced that if we did so then the GTA02's UI could fly along. It's a fact that to get to this state we're going to have to write a lot of hardware-specific code, and each developer who would potentially work on this stuff has to make their own decision about whether they want to do that for a GPU which won't be found elsewhere. Extract from http://lists.shr-project.org/pipermail/shr-devel/2009-December/001702.html - see the thread for context. --- If you're only talking about the X protocol overhead, then that's true - although I haven't yet seen any numbers... However, it's not the driver's fault. By the time (say) GTK's rendering instructions get to our driver (i.e. xf86-video-glamo), they've been turned into a series of tiny rectangle operations which are almost impossible to accelerate in any useful way. In this sense, the way X requires programs to send their rendering commands, and the way GTK/Cairo sends its commands, and the way the X server core communicates with the driver, are hurting us. Essentially, that's why E is so much faster: it prepares larger chunks of data at a higher level where acceleration can be much more meaningful, then sends them to the server in one big block. The price of this is that the acceleration done by the driver is hardly used in most cases, so we still don't get the best out of our hardware. A more fundamental redesign could potentially allow such pitfalls to be side-stepped, but this also comes at a price: Hardware-dependent code would end up existing at a higher level in the software [1], reducing the reusability of code. [1] In the extreme case, hardware-dependent code can be moved all the way up the the individual client program, abstracted by a library. This is what DRI does, in which case that abstraction library is usually Mesa, providing an OpenGL API. --- My decision about this was simple: Since I enjoy the development work, it doesn't make any difference to me that the hardware will go away in time. Nothing is forever, and this is a perfect opportunity to learn about driver development on a relatively tame piece of hardware. I don't have any immediate plans for world domination [2].. Tom [2] ... or is that just what I want you to believe? Mwahahahaha... -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA02] VGA-QVGA switching - #2263 revisited
On Tue, 16 Feb 2010 16:45:04 +0100 Vladimir Koutny vl...@moko.ksp.sk wrote: Thus, I'd like to ask if anyone know: - a solution that works? - a git revision which is supposed to fix #2263? - some background on #2263 so I can try to fix it in SHR kernel? I'm also fine with DRM kerels if they can somehow switch the modes/orientations; I didn't find a word how that should work, though. XRandR hasn't really been worked on yet for the DRM/KMS stack, so if it works then it's more luck than judgement. I'm working on stabilising this kind of thing in the 2.6.32+DRM kernel right now. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [glamo] FYI from Tom's blog
On Thu, 19 Nov 2009 12:19:34 +0100 Davide Scaini dsca...@gmail.com wrote: hope Tom will talk about this with us. (in his blog there's no possibility to comment) In case you haven't spotted them already, see other threads for discussion: Xorg Glamo on OM-Community, and Glamo Speed Improvements on OM-Devel. I'll also see what I can do about enabling comments on my blog. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xorg Glamo
On Fri, 20 Nov 2009 00:52:02 +0100 Amygos amy...@paranoici.org wrote: And what about hardware JPEG encoder/decoder? Was it implemented yet? Is there some code or doc were i can learn more about it? Not apart from the NDA'd datasheets. You could see if the OM people are still able to give you the NDA to sign to get access to these, or maybe one of the people who are already 'NDA'd' could write an explanation of their own. I'm afraid I don't have a lot of time myself alongside everything else at the moment. It'd be interesting to see if using hardware JPEG decoding can enhance performance. Could be a sneaky way round the bandwidth limitation for certain types of data, as long as it's faster to upload the JPEG and decode than to upload something already decoded. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xorg Glamo
On Thu, 19 Nov 2009 14:26:27 +0100 Bart. uz...@o2.pl wrote: Nice work Thomas - just add to rss Your blog :) Could You add comments there? Comments and trackbacks now accepted (due to popular demand). Please don't all spam me at once... :) Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xorg Glamo
On Thu, 19 Nov 2009 10:32:25 +0100 David Garabana Barro da...@garabana.com wrote: I think those are GREAT news: http://www.bitwiz.org.uk/s/2009/11/look-ma-no-busywaits.html http://www.bitwiz.org.uk/s/2009/11/internal-memory-bottlenecks- [...] I aim to please :) Just bear in mind that neither of these things impact significantly on the Glamo bandwidth limitation, which is the thing that most seriously limits our graphics performance (by a HUGE margin). And since we barely make use of Glamo's acceleration features, it doesn't add up to much of a change. Still a step in the right direction, though. I think my FR runs a bit more smoothly with these patches, but maybe I'm just being optimistic. It occurred to me that the Glamo-accelerated mplayer should work a whole lot better with the FIFO patch, and even better still if someone made it use DRI/DRM. Anyone up for an interesting project? :) Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xorg Glamo
On Thu, 19 Nov 2009 12:09:32 +0100 David Garabana Barro da...@garabana.com wrote: I know the bandwith handicap, and I know it's not possible to improve that, but having free CPU time while Glamo is drawing should allow to calculate things (as next frames) instead of waiting glamo to finish. Shouldn't it? That's right. All I was saying is that the improvement only applies for accelerated operations, and that (at the moment) we don't ask it to do very many of those. At least, not operations that are large enough to be worth accelerating. Should FIFO patch have some impact on normal (Xorg) use? A limited impact (because of the above), but so far (for me) it certainly doesn't seem to hurt. The situation is slightly odd: the FIFO patch makes the waitqueue patch have less impact (because it's less useful to be able to wait when the accelerated operations are much faster), and the waitqueue patch also makes the FIFO patch have less impact (because we don't mind waiting as long if we can do it without blocking). But on the other hand, there's only one Xorg process doing all the requests. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WikiReader - github problems?
On Tue, 10 Nov 2009 21:45:30 +0100 Torfinn Ingolfsen tin...@gmail.com wrote: When I go to http://github.com/wikireader/wikireader (now, Tueday 10.11.2009, at 21:43 CET, I get: 404 Not Found Why is that? Nothing to worry about. See: http://twitter.com/github Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian?] xserver-xorg-video-glamo very slow with navit
On Tue, 22 Sep 2009 14:30:06 +0200 arne anka openm...@ginguppin.de wrote: navit came up alright, but it was slw. at a point very early it stopped rerendering altogether, the cpu monitor constantly hit 100% and never came down again. looking with top showed X at 50-60%, often even more and never falling below 50%. thus, it was completely unusable. I'd noticed X.org being very slow with GTK programs as well - e.g. tab switching in TangoGPS takes several seconds, and scrolling is much less repsonsive than in Kdrive. At first I attributed it to GEM overheads in the DRI driver, but then I noticed that it happens with the mainline (non-KMS) driver as well. So far, I have no idea at all what's causing it... Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting Linux development for lower resources machines from Con Kolivas
On Sun, 6 Sep 2009 15:27:13 +0100 Joseph Reeves iknowjos...@gmail.com wrote: Now for someone to find the time to try this ;-) I applied the latest BFS patch to the andy-tracking branch of the kernel but it wouldn't build - probably an indication of my noob kernel skills rather than the applicability of the patch, however. Would also be very interested if someone else got this to work ;-) Here's my first stab at getting the patch to apply to our kernel, done against drm-tracking but applicable to andy-tracking as well. Your milage may vary - I don't really know my way around these parts of the kernel, and I may have just done it wrong, but it compiles (with a couple of warnings) and boots for me: http://www.bitwiz.org.uk/openmoko/BFS-andy-tracking-and-drm-tracking-BARELY-TESTED.patch Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting Linux development for lower resources machines from Con Kolivas
On Wed, 9 Sep 2009 17:43:49 +0100 Joseph Reeves iknowjos...@gmail.com wrote: Great, thanks Tom, I'll have a look at that later. Does it seem to make any difference for you? It's difficult to say, really. I haven't done any scientific tests, but it feels a little faster in some areas (suspend/resume, Illume sliders and toggles), and pretty much the same in most other places. I think it'll vary a lot depending on what userspace you're using, though. I suspect that things other than scheduling are limiting the interactivity in my setup (Xorg KMS, SHR). Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting Linux development for lower resources machines from Con Kolivas
On Wed, 9 Sep 2009 17:43:49 +0100 Joseph Reeves iknowjos...@gmail.com wrote: Great, thanks Tom, I'll have a look at that later. Does it seem to make any difference for you? It's difficult to say, really. I haven't done any scientific tests, but it feels a little faster in some areas (suspend/resume, Illume sliders and toggles), and pretty much the same in most other places. I think it'll vary a lot depending on what userspace you're using, though. I thinkg that things other than scheduling are limiting the interactivity in my setup (Xorg KMS, SHR). Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel Mode-Setting (KMS) on Neo FreeRunner + Debian
On Wed, 19 Aug 2009 19:37:21 +0200 Michal Brzozowski ruso...@poczta.fm wrote: Sure, I'd like to test it. Any instructions on how to install it? Yep, there are build instructions here: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html Sorry for the slow response. I've just updated the instructions to use more recent versions of X.org and to be based on SHR (though your choice of distro shouldn't matter), and I wanted to check that things were OK. A very recent version of X.org is needed to use mixed mode pixmap handling, which speeds things up a lot. However, the dependencies are quite nasty so I'd welcome any feedback on whether the instructions work or not. You can build with a slightly older version (1.6.0 works), but it'll be a bit slower [1]. The binaries linked from that page are out of date - I'll update them shortly if anyone's interested in this lazy option. Tom [1] Actually, I think I just broke compilation with older version of Xextproto (7.0.5 and older). Some sort of version test and conditional code is needed to deal with a change in name of dpms.h to dpmsconst.h. -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel Mode-Setting (KMS) on Neo FreeRunner + Debian
On Tue, 25 Aug 2009 10:00:10 -0500 (CDT) KaZeR ka...@altern.org wrote: The binaries linked from that page are out of date - I'll update them shortly if anyone's interested in this lazy option. I am :) Let's say that i'd like to blind test the other option :) Up to date DRI binaries are now available on my site. They're built for SHR-Unstable, and your milage may vary with other distributions. The usual disclaimer about installing experimental and potentially FreeRunner-frying code is hereby made. On the other hand, I run this stuff day-to-day at the moment, and haven't had to run for the fire extinguisher just yet. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Kernel Mode-Setting (KMS) on Neo FreeRunner + Debian
On Tue, 18 Aug 2009 11:38:12 +1000 Chris Samuel ch...@csamuel.org wrote: I haven't seen anyone else post about this yet, but this looks really neat! (Found via Planet Ubuntu) http://losca.blogspot.com/2009/08/kernel-mode-setting-kms-on-neo.html Thanks to everyone for the encouragement! Apart from the GEM buffer object waiting ioctl not having been implemented (leading to garbled text in some cases, and a few other artifacts), I think the KMS driver is in a usable state right now. Anyone brave enough to test it is more than welcome. It's important to note that, at this stage, the work is less about performance and more about laying a solid basis for DRI [1]. The overheads involved with mmapping GEM objects appear to result in a slowdown for some things (for example, switching tabs in TangoGPS). But fear not - there is plenty of room for optimisation here. Tom [1] Give or take any bugs, the DRI protocol itself should actually work at this point. -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mplayer with rebased Andrzej Zaborowski patch for -vo glamo
On Mon, 20 Jul 2009 17:29:09 +0200 Martin Jansa martin.ja...@gmail.com wrote: I couldn't found it there too, thats why I started to update it to latest mplayer code :). I'll post it there after some testing here, it works for me, but I'm using latest DRI stuff from Thomas White and others (now from exa-via-dri branch [1]) so I'm curious about others experience with it. I'm fascinated that you managed to get a picture (of anything) on the screen using the exa-via-dri branch at the moment :).. It contains only a small amount of code leading up to the point when I realised the serious problem with trying to do EXA over DRI within an fbdev-based DDX without KMS [1]: http://tinyurl.com/lgu2d7 Both the exa-via-dri and dri-aware branches of xf86-video-glamo will be going away quite soon in favour of a new kms branch, which works round these issues, and has an added bonus of being much simpler. The kernel parts of KMS necessary to get an old-style fbdev Xorg driver running are working already, this part is about making our Xorg driver use the KMS framework. I'll send an email to OM-Devel to clarify this when this next stage of things is working. But anyway, are you interesting in making the mplayer driver use DRI? If so, that's fantastic - it'd allow cooperation between Xorg's acceleration and the video acceleration. Tom [1] If that's not too many TLAs for one sentence... -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: why openmoko is so slow? Is it a joke?
On Mon, 13 Jul 2009 12:30:29 -0700 Ben Wong lists.openmoko@wongs.net wrote: Thank you, Maddog, for your trenchant comment. I was having trouble verbalizing a response to mobiphil, but you've hit it exactly. To consider Openmoko a failure for having lower GPU performance is to misunderstand what Openmoko is about. From my point of view, Openmoko is a success that is still unfolding. I have exactly what I want, a free as in freedom phone and an active community of people to hack with. That's what I paid my money for. ... and don't forget that part of what's unfolding (albeit slowly) is better support for the acceleration features of everyone's favourite graphics chip.. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Update Who is who on wiki
On Sun, 21 Jun 2009 17:50:14 +0200 Fabian Killus fab...@ji-xiansheng.de wrote: As proposed before on this list it would be a good idea to update the information at http://wiki.openmoko.org/wiki/Who_is_Who. While I am afraid to touch this page directly, here is what I would have so far: I went ahead and wiki-fied the list we have at the moment - I think it'll speed things up a lot. Please get stuck in and fix the many glaring errors and omissions: http://wiki.openmoko.org/wiki/Who_is_Who Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Update Who is who on wiki
On Sun, 21 Jun 2009 22:30:40 +0300 Timo Juhani Lindfors timo.lindf...@iki.fi wrote: Fabian Killus fab...@ji-xiansheng.de writes: Xorg glamo: - Thomas White I'd add Lars-Peter Clausen here (38 commits to xf86-video-glamo). Absolutely - certainly before my own name. What me (and Andreas, and hopefully a few others) are doing is really just experimental at this stage. Lars is the one providing real useful code at the moment. Tom -- Thomas White t...@bitwiz.org.uk ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git checkout
On Wed, 27 May 2009 10:36:34 -0400 Iain B. Findleton ifindle...@videotron.ca wrote: The error message is fatal: not a git repository Same for git branch -a. Al this follows what looked like a successful git clone command A quick muppet check here: you *did* change directory into the newly cloned folder..? If you're cloning the kernel tree, it'll be called kernel, but you can tell it a different name if you want. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: git checkout
Iain B. Findleton ifindle...@videotron.ca wrote: I confess to not being too familiar with git, however, the web site says to use the command: git checkout origin/andy-tracking after cloning the kernel project. This does not work for me. I suspect that origin must be something else. Any suggestions? Can you paste an error message? Also, the output of the following command should help: $ git branch -a Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Unstable] Broken Batter Applet
On Mon, 25 May 2009 14:23:36 +0200 Hermann Lacheiner hermann.lachei...@gmail.com wrote: using internal shows the correct value, but the battery meter is jumping back to auto-detect automagically after a few seconds.. :( I found that as well. Is anyone able to comment on what HAL is being used for in SHR-Unstable? If it's simply been pulled in as a dependency (e.g. for X.org) and isn't actively being used (e.g. by X.org for input management), then it can be removed without breaking anything, which makes the problem go away. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Visit at Openmoko
On Mon, 25 May 2009 23:40:03 +0800 Sven Klomp s...@klomp.de wrote: I got invited to a conference in Taiwan and used the occasion to stop by the Openmoko office. I use the Freerunner as my daily phone, hence I was interested in the people behind it. When I arrived, the whole office was empty. 10 minutes later they came back from a company meeting. I had prepared quite some questions but I didn't got that far. It seems to me that almost everyone just got layed of in this very meeting. That's not how I'd imagined the visit :-( A not unimportant snippet of information is missing: How long ago was this? Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMooCow 0.4
Just a quite note to announce the release of version 0.4 of OpenMooCow. Mo. etc. :) The changes since 0.3 aren't very exciting, but ensure continued compatibility with the latest distributions. The changes are: - A crash, when the sysfs paths were not as expected, has been fixed. - The very latest changes to the sysfs paths have been handled. - The change from EV_REL to EV_ABS has been handled. - Proper categories have been added to the .desktop file. Download from http://www.bitwiz.org.uk/openmoocow, or from opkg.org. I've heard of a lot of people having trouble with OpenMooCow on various distributions. The combination of accelerometers and audio seems to show up lots of problems which wouldn't otherwise be noticed! For a discussion, look under Known Problems near the bottom of the page mentioned above. This release should fix all accelerometer problems, but some SDL audio problems will remain. I hope to be able to take a closer look at these (they're SDL problems, not my fault :), but I have other Forbidden Projects taking up my time at the moment... Enjoy! Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Fri, 3 Apr 2009 15:14:35 +0200 ri...@happyleptic.org wrote: Which fits very well with what I call a closed system. What if I just want to have a look, and, depending on the chip capabilities and some experiments, decide to go lowlevel or not ? A fair point... T ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Sat, 4 Apr 2009 15:04:27 +0200 Rask Ingemann Lambertsen r...@sygehus.dk wrote: The Glamo doesn't have a vblank interrupt. Try to search the bug tracker, though, because there was a mention of an alternative means of getting double buffering to work. Not having a vblank interrupt doesn't rule out double buffering in any way. It just means we may have to put up with tearing. If we can make proper use of what Glamo can do, we can do back-front buffer blitting with the 2D engine in a fast way - i.e. without draping, as it has been called. That would possibly give us tearing, since there's no nice way to synchronise our blits with vblank. In addition, Glamo can do page flipping which should be synchronised properly with the LCD (the datasheet claims tearing free operation). Just the ticket for full-screen applications, but not great (read: probably slow, but perhaps not - I haven't investigated properly yet) for an X desktop with multiple windows. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Fri, 03 Apr 2009 21:14:16 +0100 Ian Stirling openm...@mauve.plus.com wrote: What is the bandwidth for memory moves? About 6-8 or so - with 100% CPU utilisation Or one pixel per 2D engine clock cycle for moves inside Glamo's memory using its blitter (i.e. VRAM-VRAM). I think that in the Freerunner the relevant clock runs at 50MHz, but I haven't managed to properly decipher what's going on in that regard. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Thu, 02 Apr 2009 11:17:42 -0400 Iain B. FIndleton ifindle...@videotron.ca wrote: A significant issue for me is the performance of the graphics display on the FR. I recall some discussions a while back about making use of the XGlamo acceleration features. Has any progress been made here? It appears to me that the graphics performance on the FR is poor compared to, for instance, the iPhone or iTouch, both of which have slower CPUs. When applications running on the FR have their X output routed to a machine with accelerated graphics, it is apparent that the FR processor can deliver the X events fast enough, but the FR graphics chip interface can't keep up. [I wrote this before the other replies came through, so it re-covers a bit of ground.] We do have some acceleration already - both XGlamo (the Kdrive X server) and xf86-video-glamo (the Glamo driver for Xorg) make use of Glamo's 2D engine to accelerate tasks such as flood-filling large areas and moving blocks of data around the screen or onto the screen from offscreen. However, I do agree that we can do a lot more. So far, we've concentrated on trying to implement conventional acceleration protocols while being limited by what Glamo can't do. Instead, I think we should look at what the little chip CAN do, and really make it work, HARD, for us. Particularly its 3D engine. With that, we could do things like (dare I say it, iPhone-style) flying launcher icons, or alpha-blended overlays, or other things I can't even imagine right now... There are many limitations of the chip, but I don't see them as a reason to give up on this kind of thing. For example, it's often mentioned that the 3D engine won't render to a buffer larger than 511x511 pixels. That would seem to rule out such graphical fanciness at the native resolution of 480x640, but how about we just cover a 480x511 region of the screen with accelerated graphics and make the remaining area into some kind of tool or status bar? Maximum texture size of 256x256? Then design the UI so that the accelerated parts of the UI split into blocks of that size or less. And so on. I see more potential in working 3D acceleration than just Quake, and I'm not in the least bit put off by the knowledge that the chip is a one-off... Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Fri, 3 Apr 2009 14:12:55 +0200 ri...@happyleptic.org wrote: -[ Fri, Apr 03, 2009 at 11:36:39AM +0100, Thomas White ] There are many limitations of the chip, The main one being of course the lack of documentation. The stack of paper on my desk says otherwise... :) (Seriously, the necessary documentation has been released, under NDA, to people who have said they're serious about working on drivers). Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Sat, 4 Apr 2009 00:01:16 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: beware of jumping all over 3d as the solution. i have recently been working on a gles2 engine for evas. i have run it on 2 platforms (s3c6410 and omap3530). both with hardware opengles2 (and capable of high res etc.) and software beats gles2. yes - evas software rendering is faster. oddly enough the movial guys and trolltech (qt) guys see the exact same performance problems. gl is slower (i know that i and the trolls have seen about a 1/4 speed of gl vs software). I'm really interested as to why this might be the case. Do you have any ideas? Something like the increased overhead of the extra API and latency associated with swapping contexts? Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Fri, 3 Apr 2009 15:03:09 +0200 Nicola Mfb nicola@gmail.com wrote: Some time ago we focused about the wasting of cpu cycles to wait for X operations to complete (as no interrupts are exported to userspace). This impacts a lot the system as you use accelerated graphics but you have to hold and wait for it. Are there working in progress to solve this, it may be in a drm module? Well, we (I and a few others) have been working on DRI, which at its core has a DRM module which mediates access to the graphics hardware, but there's no reason why that should help with this particular problem in itself. But this is all (still) at a very early stage. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is Israel a Democracy? -- The problem with intellectually insecure whites -- Should Christians Support Israeli Terrorism in Gaza?
On Fri, 23 Jan 2009 11:14:10 -0500 john dowd jdowds...@gmail.com wrote: And you think that this is an appropriate forum because why? See the headers. I strongly suspect some forgery... Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.3
Helge Hafting helge.haft...@hist.no wrote: The accelerometers don't work though. hexdump /dev/input/event2 gets me changing output as I turn the phone around. event3 is dead, perhaps that is the problem? That would certainly prevent mooing. If the accelerometers don't work, you should still be able to test the audio parts by pressing the cow picture on the screen :) I think there might still be some locking problems lurking in the kernel parts of the accelerometer stuff. For me, re-starting OpenMooCow almost always makes it work the second time. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.3
Helge Hafting helge.haft...@hist.no wrote: My SHR is unable to open audio. But the older moocow worked with the same setup. I can stop speech-dispatcher, but it doesn't help. There is no snd-pcm-oss module to load, bt the previous moocow didn't need that. Previous meaning version 0.2? All the previous versions are available from my site: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ - would you be able to check version 0.2 again to be sure? This is particularly puzzling because the audio parts of the program haven't been touched between 0.2 and 0.3... Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Buying a FrogPad in the UK
Hi all, I'm interested in buying a FrogPad keyboard to use with my FreeRunner, but I can't find a UK distributor. According to www.frogpad.com, the UK distributor is Scan, but their website denies all knowledge of it. I also drew a blank with Amazon, Dabs and even eBay. Has anyone in the UK (or even in Europe) bought one recently? Thanks, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: (OM2008.12) Blackness
Paul p...@nlpagan.net wrote: I know, I am going through distro's like crazy, but that's how I am. I flashed OM2008.12 but I can't keep it going. It boots, and after something like only 30 seconds it already blanks the screen and plays dead. Is there some setting I can adjust quickly to keep it working? When you say it boots, do you mean it got all the way to an X desktop? It sounds like you might be experiencing a crash when suspending or resuming, and auto-suspend is switched on. You can disable this in Settings. I used to have problems like yours (almost every time I enabled automatic suspend, I would get resume problems), but now they seem to have settled down a bit. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buying a FrogPad in the UK
Sam Kuper sam.ku...@uclmail.net wrote: Whoa, that's a nifty keyboard! I'm in Cambridge too, and would love to see your FrogPad in action if you can get hold of one. I'd be very grateful if you'd keep me posted (on or off list, as you prefer). Will do. Watch out for the next Cambridge OM pubmeet as well. There's five or six of us in Cambridge, and the last meetup was in a quality establishment in the Beer Quarter back in October. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.3
On Fri, 19 Dec 2008 10:24:23 +0100 KaZeR ka...@altern.org wrote: my SHR doesn't play the sound... am i missing something? Unable to open audio: No available audio device I had the exact same issue last week (haven't tried again since, and i'm currently flashing 2008.12) This sounds odd. OpenMooCow uses SDL for all the audio work, and the No available audio device part of that messages comes from SDL itself. So this could indicate a problem with SDL or something lower-level. I've seen audio break before due to a mismatch of kernel modules. Does audio work in any other programs for you? Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMooCow 0.3
OpenMooCow 0.3 is now available: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ Changes since version 0.2 are: - My finest programmer art has been banished to a suitable place, namely the fiery depths of Hades. It's been replaced with some much better graphics from openclipart.org. It's a public domain image, but I thought I'd give a credit to user bsantos who created the picture. - Disables the accelerometer threshold while it's running. This makes the cow a lot more responsive. Your old threshold will be restored on exit, unless the threshold value has been changed from zero since MooCow started, in which case it won't restore the old one. - Ready for kernel 2.6.28 - aware of the new sysfs paths. - Thinkpad HDAPS support from Joachim Breitner has been merged in. Comments or abuse to this address. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2008.x] praise for the new testing image
On Wed, 03 Dec 2008 16:18:37 + Vasco Névoa [EMAIL PROTECTED] wrote: I've been trying the illume (gray) theme with the testing image, and it is badly broken - Enlightenment keeps crashing at random moments for reasons unknown. I find this too, but if you go into Illume's settings (this requires a little patience for the obvious reason), press Engine and select Software, then it should go away. I've been using that for weeks now with no problems after that adjustment. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, 01 Dec 2008 22:22:28 +0900 William Kenworthy [EMAIL PROTECTED] wrote: openmoocow (old version) started once out of three tries - left me at a grey screen otherwise. This is really my fault, due to a combination of MooCow's architecture in that version and the accelerometer driver behaviour. Try the newer version - it should work much better. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Optimization team update (11/23 ~ 11/29)
On Mon, 1 Dec 2008 15:31:03 + Joseph Reeves [EMAIL PROTECTED] wrote: There seems to be a strange problem with gtk apps that, when first loaded, they appear to freeze, but if you go back to home then select the open app from the top drop down list again, they work fine. It's an odd one to reproduce though, so I won't file a ticket yet. That's exactly bug #1946, so no need to file a ticket... https://docs.openmoko.org/trac/ticket/1946 Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.2
Joachim Breitner [EMAIL PROTECTED] wrote: Nice. Is your git tree publicly available? Here you go, sorry for the wait: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/openmoocow.git Could you let me know if there are any problems with the current tip of 'master' on Thinkpad? It's working fine on my Freerunner here. If there are no problems, I'll release that as version 0.3 sometime next week. I'd like to wait just a little longer to see if any more installation problems with the .ipk arise, to avoid another awkward intermediate release like this time. Thanks for all your help, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTK Redraw Issues (was: Optimization team update (11/23 ~ 11/29))
John Lee [EMAIL PROTECTED] wrote: Julian is working on the GTK redraw issue, please help him out. Be sure to see my previous analysis sent upstream: http://bugzilla.gnome.org/show_bug.cgi?id=561591 The problem arises because gtk_window_move_resize() temporarily freezes redraws on the assmption that gtk_window_configure_event() will be called shortly afterwards, but this never happens. It could be that the expected configure_event is actually happening _before_ the move_resize, but I don't know what the expected order is. In fact, I think it might not even required to be in any particular order. I think this arises from an interaction of the specific way Enlightenment manages things combined with the assumption mentioned above. This would also explain why running GTK programs on Neo via X forwarding works for me (with xfwm4 on my laptop). It also explains what someone described to me on IRC: that with Debian the same problems appeared only after changing WM to Enlightenment. They were going to add a comment to the ticket, but don't seem to have done so yet. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.2
William Kenworthy [EMAIL PROTECTED] wrote: tried to install it on 2008.9 - required new glib which predictably, killed some other apps - and on top doesnt run (enlightenment error). Will have to wait for possibly 2008.12 (?) until it can be used unless you are on another distro. Nyarg, really sorry about that, and thanks for reporting it. I've made a small change to the dependencies and a new package is now available: openmoocow_0.2-r2_armv4t.ipk from the usual place: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.2
Joachim Breitner [EMAIL PROTECTED] wrote: I took this as an encouragement to hack slightly on your code, so I did a slightly larger modification. Looks good. Just one comment: O_NONBLOCK doesn't seem to be honoured for the Neo accelerometers (hence the select() stuff). See this post on OM-Devel (and the responses): http://lists.openmoko.org/pipermail/devel/2008-November/003443.html I've added this to my Git tree for inclusion in later releases. For the purposes of the Debian package, are you happy to have this included from your own branch in the Debian Git repository, or would it be less complicated if I did a new upstream release with the HDAPS stuff? Many thanks, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMooCow 0.2
While waiting for the Christmas puddings to cook this afternoon, I've been making a few updates to OpenMooCow. You can get version 0.2 from the same place as before: http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ Changes since version 0.1 are: - Moos when tilted either up or down (not just after tilting both ways like before). This seems to be what people expect, even though it's not quite what I remember genuine mooboxes doing. - The packaging has been fixed to depend on the things it needs. - You can now press the cow to make her moo. - Mooing still occurs even if the graphics can't be shown. Run the following on a terminal and your Freerunner will be mooing until the next reboot: $ nohup openmoocow And some improvements under the hood: - It should behave a little better if the accelerometers are sticky. - Code simplified and altered to make it easier to add support for other types of accelerometer. OpenMooCow won't alter your accelerometer parameters in any way, so you might have a configuration which it doesn't like. In particular, the threshold setting can cause problems. If this happens to you, try this: # echo 0 /sys/devices/platform/lis302dl.2/threshold Comments or abuse to this address as ever, Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.2
Joachim Breitner [EMAIL PROTECTED] wrote: Nice! I hacked up some hdaps (read: Thinkpads) support, tested on a T41p Great stuff. Enrico told me that there was interest in making it work on Thinkpads, but I didn't expect it to happen within 90 minutes of releasing a new version. Feel the power of open-source... It now moos when tilting your laptop 90° away from to or towards you (and again when you tilt it upright, due to the latest change). Hmmm...mooing when tilted either way makes more sense for something like a phone than for a laptop. If you decide this doesn't feel right, feel free to revert this when using the Thinkpad driver (not that you need any permission for that, of course). When you're happy with the Thinkpad support, could you send me a patch to for the next version? (If a new version is ever necessary...). Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The forbidden topic: Glamo OpenGL
Tim Schmidt [EMAIL PROTECTED] wrote: As a GTA02 owner, as a founding member of the Open Graphics Project, as a Director of the Open Hardware Foundation, I believe I have the resources to accomplish such a task. I'd love to try. Can we make it happen? I would love to contribute in some way here. I've been programming OpenGL for almost two years (programming generally for a LOT longer), and I'm slowly learning kernel programming. However, I appreciate that it's going to take a whole lot more than that to make this work... Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RESEND(Wrong Thread): IMAGE/MP3 licensing issue.
On Wed, 12 Nov 2008 13:45:12 + Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: I can give you the rest: http://mp3licensing.com/royalty/software.html http://stopsoftwarepatents.eu/ Oh, I got that far. I'm curious to know what's changed in particular to prompt the sudden removal: has some kind of legal threat been made by someone? Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: RESEND(Wrong Thread): IMAGE/MP3 licensing issue.
On Wed, 12 Nov 2008 20:15:44 +0800 Ray Chao [EMAIL PROTECTED] wrote: We are sorry that currently we have to remove all the images on the download server of Openmoko. http://downloads.openmoko.org/release/ Erk... are you able to give any more details about the exact reasons? Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bugs from Openmoko Public Trac in Devel list?
On Fri, 31 Oct 2008 16:29:57 +0100 Leonti Bielski [EMAIL PROTECTED] wrote: Since a couple of days ago I started receiving a lot of bug reports from Openmoko Public Trac into Devel list. Why is it so? Personally I don't like it - if I want to see what tickets are available I go to http://docs.openmoko.org/trac/report where I can sort them and view in defferent ways. Now It's just a spam in my mailbox and it's hard to find meaningful mails from actual people into all these bug reports. Can someone explainto me whay is it happening? I agree it's a little messy, but it's just John Lee clearing up a huge backlog of old bug reports. What we're seeing is updates as bugs are marked as closed. I don't think it's going to be like this for too long... Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: General GPS Question
On Thu, 30 Oct 2008 18:09:47 + Matthias Camenzind [EMAIL PROTECTED] wrote: The satellites are moving around. So on a different time the position is different. There is a number called the dilution of precision which quantifies the factor by which the accuracy of the GPS reading is reduced by the positions of the satellites. For instance, if a reading were from three satellites all positioned close to the zenith, the accuracy would be reduced compared to how it would be if they were widely spaced apart. To see how this works, visualise how the GPS correlator calculates your position by the intersection of spheres centered on the satellites, and consider how this would be affected by an inexact measurement of the radii of the spheres. Then consider how that would in turn be affected by the positions of the satellites. While in theory your suggestion would work, the geometrical dilution of precision would be HUGE, and so the measurement would overall be very inaccurate. Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.1
On Wed, 15 Oct 2008 16:21:19 +1000 nickd [EMAIL PROTECTED] wrote: This has now shot to my favourite app. I wonder if we could make the 'moo' earlier. I assume you're trying to replicate those little toys that make the same kind of noise when you do the same thing. Yes - originally I planned to do a full emulation of the physics that goes on inside a proper moobox, and to vary the pitch and volume depending on the speed of the flap inside. Then I realised that that was a bit harder than I have time for at the moment so it's saved for a later version. If you look in the source code, you'll see data structures and methods completely over-engineered for what it actually does at the moment... Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMooCow 0.1
On Wed, 15 Oct 2008 11:15:13 +1000 Denis Johnson [EMAIL PROTECTED] wrote: Sounds like fun, what distros will this run on ? more specifically can this run on qtextended ? I developed it on Om2008.8-testing, but it should run on anything with an X server and GTK. I don't think QtExtended provides this unfortunately :(. A port should be pretty easy, but it'd be an almost completely new program because all there is to it is a window with an image (GTK), a timer callback (glib), a few file handling calls (stdio) and a hook into SDL to play the sound. When I tested it on FSO a couple of weeks ago I found some interesting problems with the accelerometer data - the range seemed different so it wasn't possible to trigger the sound. I know about the range setting of the accelerometers, but I didn't think that changed the units of the readings, only the maximum range (and hence resolution). Glad everyone enjoys it :) Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMooCow 0.1
I'm pleased to be able to announce version 0.1 of my advanced accelerometer and audio framework testing system, OpenMooCow. Available from http://www.srcf.ucam.org/~taw27/openmoko/openmoocow/ When installed and run, OpenMooCow displays an artistic rendition of a fine specimen of Friesian dairy cattle. Invert the device and return it to an upright orientation to experience the pinnacle of audio rendering kwality. The sound effect can be altered by putting a suitable WAV file in /usr/share/openmoocow/moo.wav. A credit is due to Chris Hendricks who is the author of the original sound file (obtained from www.flashkit.com). Comments/abuse to this address. Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian/gta02v5] zhone suspend not working anymore
On Mon, 29 Sep 2008 16:52:48 +0200 Fox Mulder [EMAIL PROTECTED] wrote: Since over a week suspend isn't working anymore for me. Perhaps this could be related to the recent re-opening of ticket #80: https://docs.openmoko.org/trac/ticket/80 - which reports problems with the wakeup reason stuff? I was previously using a (self-compiled) kernel built from the 'stable' git.openmoko.org kernel branch, revision a1e97c611. Last night I updated to a kernel built from the latest revision (968c41d0c), and I had similarly serious suspend problems (didn't seem to wake up at all). As far as I know, the latest OM kernel is still a1e97c611. So, on the (tenuous) assumption that all the problems described here are the same regression, I suspect either fix-one-mmc-race.patch or fix-glamo-idleclock-around-suspend.patch of breaking things. These are the two commits between a1e97c611 and the revision described in ticket #80 as causing trouble (ca19d1564). In either case, when I get the chance, I intend to do a git bisect to isolate my own problems between revision a1e97c611 and the current head. Hoping that this is at least vaguely helpful, Tom -- Thomas White Department of Materials Science and Metallurgy Electron Microscopy Group (PhD Student) University of Cambridge / Downing College ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [2008.9] Suspending questions
On Tue, 23 Sep 2008 11:50:04 +0200 Christoph Siegenthaler [EMAIL PROTECTED] wrote: I've got the following problem: suspending the FR works (by pressing on/off and automatically) but every time I wake it up (by pressing on/off) the device wakes up for about 2s and returns straight back to its suspended state - until I press on/off again. The second time, resuming works ok. Any hints on how to fix this? I have problems that sound a lot like this if I have automatic suspend enabled. With it turned off, the problems go away but obviously there's a danger of flattening the battery if (say) the Neo gets woken up by a missed call and you don't notice for a number of hours. I think it's related to the screen blanking (maybe it's not actually falling asleep, just blanking the screen) - but I haven't tested thoroughly yet. Tom -- Thomas White - Downing College - Electron Microscopy Group (PhD Student), Department of Materials Science and Metallurgy University of Cambridge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Measure of the file /dev/input/event3 (Accelerometer data)
On Tue, 23 Sep 2008 13:28:26 +0200 Jacob Peterson [EMAIL PROTECTED] wrote: I think the Accelerometer data retrieval page on the wiki should have all the information you are looking for: http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval I didn't come across anything about units in my travels. To me, it looks like they're in cm/s/s, i.e. divide by 100 to get the familiar value of 9.8ish pointing downwards. Don't forget that (a) I may be wrong, and (b) The orientation of the accelerometers might need some calibration. Tom -- Thomas White - Downing College - Electron Microscopy Group (PhD Student), Department of Materials Science and Metallurgy University of Cambridge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Measure of the file /dev/input/event3 (Accelerometer data)
On Tue, 23 Sep 2008 12:34:26 +0100 Thomas White [EMAIL PROTECTED] wrote: I didn't come across anything about units in my travels. To me, it looks like they're in cm/s/s, i.e. divide by 100 to get the familiar value of 9.8ish pointing downwards. Ok, Paul's code says that the number is in units of 1/1000 of 'g' (g=9.8 m/s/s), which also makes sense to me. So, I'll defer to his expertise unless anyone says otherwise :) Tom -- Thomas White - Downing College - Electron Microscopy Group (PhD Student), Department of Materials Science and Metallurgy University of Cambridge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Customized layout for illume keyboard
Thomas B. [EMAIL PROTECTED] wrote: I customized the layout of the illume Numbers keyboard a bit, and thought I'd share the result with the community. I love the illume keyboard, the only minor annoyance was that the keys in the Numbers layout were pretty small, so I had to fumble quite a bit when entering my PIN without a stylus. EXACTLY what I was looking for (and was about to have a go at creating myself). Many thanks! Tom -- Thomas White - Downing College - Electron Microscopy Group (PhD Student), Department of Materials Science and Metallurgy University of Cambridge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Questions regarding shell/startup scripts
SCarlson [EMAIL PROTECTED] wrote: Does anyone's resolv.conf get stomped on every time the machine is rebooted? I have been adding my nameservers by hand.. Just wondering if there is a good reason for this? I don't know about why it happens, but you can have the nameservers added automatically by adding a couple of lines to /etc/network/interfaces on your Neo. Check the section Configure Default Neo DNS in http://wiki.openmoko.org/wiki/Usb_networking. Also, Where should I go to force BASH as my default shell, and/or how do i get an ASH init script that loads everytime I open a terminal. (If I could do this, I'd just automate the resolv.conf stuffer.) Take care if you change your default shell to Bash. I tried this (by editing /etc/passwd manually - of course the right way would be to use chsh or usermod, but neither exists in OM 2008.8 as far as I can see), and while it worked, it caused some problems when using SCP to transfer files to and from the Neo. Digging on the web suggested the problem was due to Dropbear sshd not getting along with Bash. I can describe more details of the problem if anyone's interested... Tom -- Thomas White - Downing College - Electron Microscopy Group (PhD Student), Department of Materials Science and Metallurgy University of Cambridge ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
