Re: Very fast power drain, hot device

2012-03-23 Thread Thomas White
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

2011-07-13 Thread Thomas White
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,

2010-06-06 Thread Thomas White
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

2010-05-17 Thread Thomas White
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

2010-05-17 Thread Thomas White
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

2010-04-13 Thread Thomas White
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

2010-02-22 Thread Thomas White
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

2010-02-16 Thread Thomas White
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

2010-02-16 Thread Thomas White
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

2009-11-20 Thread Thomas White
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

2009-11-20 Thread Thomas White
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

2009-11-20 Thread Thomas White
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

2009-11-19 Thread Thomas White
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

2009-11-19 Thread Thomas White
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?

2009-11-10 Thread Thomas White
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

2009-09-22 Thread Thomas White
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

2009-09-09 Thread Thomas White
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

2009-09-09 Thread Thomas White
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

2009-09-09 Thread Thomas White
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

2009-08-25 Thread Thomas White
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

2009-08-25 Thread Thomas White
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

2009-08-19 Thread Thomas White
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

2009-07-20 Thread Thomas White
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?

2009-07-14 Thread Thomas White
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

2009-06-22 Thread Thomas White
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

2009-06-21 Thread Thomas White
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

2009-05-27 Thread Thomas White
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

2009-05-26 Thread Thomas White
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

2009-05-25 Thread Thomas White
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

2009-05-25 Thread Thomas White
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

2009-04-14 Thread Thomas White
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

2009-04-07 Thread Thomas White
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

2009-04-06 Thread Thomas White
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

2009-04-06 Thread Thomas White
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

2009-04-03 Thread Thomas White
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

2009-04-03 Thread Thomas White
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

2009-04-03 Thread Thomas White
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

2009-04-03 Thread Thomas White
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?

2009-01-23 Thread Thomas White
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

2009-01-07 Thread Thomas White
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

2009-01-05 Thread Thomas White
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

2009-01-04 Thread Thomas White
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

2009-01-04 Thread Thomas White
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

2009-01-04 Thread Thomas White
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

2008-12-19 Thread Thomas White
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

2008-12-18 Thread Thomas White
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

2008-12-03 Thread Thomas White
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)

2008-12-01 Thread Thomas White
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)

2008-12-01 Thread Thomas White
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

2008-12-01 Thread Thomas White
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))

2008-11-30 Thread Thomas White
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

2008-11-29 Thread Thomas White
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

2008-11-29 Thread Thomas White
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

2008-11-27 Thread Thomas White
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

2008-11-27 Thread Thomas White
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

2008-11-14 Thread Thomas White
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.

2008-11-12 Thread Thomas White
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.

2008-11-12 Thread Thomas White
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?

2008-10-31 Thread Thomas White
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

2008-10-30 Thread Thomas White
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

2008-10-15 Thread Thomas White
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

2008-10-15 Thread Thomas White
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

2008-10-14 Thread Thomas White
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

2008-09-29 Thread Thomas White
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

2008-09-23 Thread Thomas White
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)

2008-09-23 Thread Thomas White
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)

2008-09-23 Thread Thomas White
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

2008-09-10 Thread Thomas White
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

2008-09-10 Thread Thomas White
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


Re: 10 Pack in West Midlands, England?

2008-04-28 Thread Thomas White
On Mon, 28 Apr 2008 11:00:39 +0100
Mo Abrahams [EMAIL PROTECTED] wrote:

 Is anybody in the West Midlands interested in getting a 10 pack? Would
 be great to save that bit of money and get the extra goodies.

The UK group sales list is undergoing a bit of a process of splitting
up into regions:  Add yourself to the list and hopefully there'll be
enough people to have a separate group order for the various corners of
the country:

http://wiki.openmoko.org/wiki/GroupSales#UK

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