Re: RFC: GSM flowcontrol handling, GTA01 and GTA02
Werner Almesberger wrote: Mike (mwester) wrote: ... So, since my preferred solution (TERMIO mechanism) won't ever make it upstream, and nobody actually implements that in user-space anyway, it seems that the sysfs-based solution is the one that wins by default Hmm, you mean that the ugliness is in the semantics of having crtscts set (thus telling the serial subsystem that we want it to be in charge of handling RTS) _and_ TIOCMBIx'ing TIOCM_RTS (thus changing RTS "manually", hoping that the serial subsystem won't override this in the next microsecond) ? Actually, I'm not even that far along. I'm only referring to the GTA0x-specific implementation that I put together -- it does exactly what we need for the GTA01 and GTA02, but nothing more. The s3c24xx serial driver has absolutely no code to manage RTS and CTS at all. So as written, the patch I put together would not be accepted upstream since it is not complete nor does it completely follow the expected behavior (for example, it leaves (and actually relies on) crtscts mode being set *while* we override the RTS signal). One could fix all of that, I expect -- by adding full support for the RTS and CTS signals to the driver, and then addressing the resulting potential race conditions that, as you described in detail, will result. But frankly, I don't see that as a good use of time when we can just leave the serial driver untouched and accomplish the same end goal in neo1973_pm_gsm.c. All we really want is to leave the UART in auto-flowcontrol mode, but override the RTS line by switching it to GPIO mode. A dozen lines of code in neo-specific source, versus some unknown amount of code with sweeping impact to all users of s3cx24xx devices? -- I've switched from my original position to support the more practical solution :-) ... Or, we could signal both, I suppose, with multiple asterisks in the wakeup reason? That looks like the most logical solution, yes. Perhaps we really don't need to worry about this at this time Yeah, I think the wakeup reason isn't something an application should actually try to make sense of. Since many of the events there could happen while suspended and while awake, there must be a mechanism to signal that event already. So this mechanism should just signal it after the resume. Anything else is likely to lead to race condition hell. It's easy to remove the sysfs entry; that's a half-dozen lines of code in neo1973_pm_gsm.c that can be pulled out at any point. But I'd love to hear the opinion from the folks working on the user-space stuff, especially the next generation replacements for neod and gsmd -- do they need anything from the kernel, and if so, how would they like to see it? Who was going to use the wakeup reason interface, and is the GSM wakeup one of those of interest? - Werner Mike (mwester)
Re: gconf or not gconf ?
On Friday 06 June 2008 13:39:13 Jan Lübbe wrote: > I'm CCing Ryan Lortie (developer of dconf). For Ryan: > Openmoko is currently looking for a framework-wide configuration > server/api. Do you think we should use dconf (instead of gconf-dbus or > something new)? > > On Fri, 2008-06-06 at 16:36 +0800, Guillaume Chereau wrote: > > On the other hand, gconf doesn't have a dbus interface, which is quite > > annoying when all the other freesmartphone services do. There is a > > project called gconf-dbus > > (http://developer.imendio.com/projects/misc/gconf-dbus) but as far as I > > understand, it doesn't provide a d-bus api, but just internally uses > > d-bus instead of CORBA to communicate with the gconf daemon. > > Here's a thread that seems relevant: > http://mail.gnome.org/archives/gconf-list/2007-September/msg0.html > > In summary: > * GConf currently uses ORBit2 and seems to be deprecated > * There is a port to D-Bus (which you mentioned above) > * Current development is focused on dconf (http://live.gnome.org/dconf) > > > I am not used to gconf, so I can't decide if it is a good thing or not. > > > > So what would you like to have : > > a) just gconf ? > > b) a dbus interface to gconf ? (that may be a little overkill, the flow > > would be like this : app -> dbus daemon -> dbus2gconf -> gconf) > > c) an other conf manager ? > > d) something totally new ? > > I've had short look at dconf and i seems like something we could use. I agree with Jan. Guillaume, please take a deep look into dconf and its dbus API and find out whether it's ready for prime time. We might get away with basing on that. See also Ryan's mail that for some reason didn't make it to the list (I guess non-member moderation, sorry Ryan). Ryan wrote: >On Fri, 2008-06-06 at 13:39 +0200, Jan Lübbe wrote: >> I'm CCing Ryan Lortie (developer of dconf). For Ryan: >> Openmoko is currently looking for a framework-wide configuration >> server/api. Do you think we should use dconf (instead of gconf-dbus or >> something new)? >Thanks for writing about this. >Depending on your timeframe, dconf is very possibly the right choice for >you. I hope you also looked at the GSettings API since this is a much >nicer option for application developers. >Since you've probably already read about the technical issues about how >this will all work, I'll give a bit of a summary of the status: >It's currently under somewhat heavy development so it won't be >immediately ready. I'm not sure I can give an estimation on when it >will "be ready" -- it's one of those things where the final 10% is >taking most of the time. >Just these past days I'm finishing up a large set of changes to the >value system (GVariant) on which this will all be based. Due to some >outside requests not related to dconf, this part of the project ended up >being somewhat more complex than originally anticipated. Once I move >back to hacking on dconf itself, work should move more rapidly. The >code there is mostly complete, but needs to be 'adjusted' for the >changes in GVariant. >After that, I will move on to the GSettings stuff, where substantial >code remains to be written (with respect to schemas, etc). >Things are fairly API stable for GVariant and dconf, but there will >almost certainly be small changes when proposed for inclusion in glib. >There will probably be some more moderate changes to the GSettings APIs >but the flavour will remain the same. >In any case, except for a small test suite, there is nobody testing the >code. Any efforts in this direction would be greatly appreciated and >help to improve my sense of confidence towards getting ready to merge. >I hope this provides some useful information. If you have any >questions, you know where to send them :) :M: -- Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de
Re: application for biking/fitness/training
On Sun, 2008-06-08 at 14:53 +0200, Joerg Reisenweber wrote: > Am So 8. Juni 2008 schrieb Marcus Bauer: > > On 6/5/08, Jens Meyer <[EMAIL PROTECTED]> wrote: > > > 2. fitness (with bluetooth heartrate-sensor) > > > > So not USB seems to be the topic to investigate, but BT profile and protocol > /jOERG > Well, for the cadence sensors they are all with cable. But googling for 'heart rate sensor bluetooth' didn't give me any useful results. There is a company called "blatant" who produces them, but they wont sell them as spare parts - I just gave them a call and although it is sunday sombody answered the phone. The garmin stuff seems to work only with garmin devices. But anyway, it would be cool to have any such sensors. Thus if somebody investigates further I'm a taker of any decent information. Marcus
GSoC Accelerometer-based Gestures Update 2
As promised, the classifier is ready. Does anyone have a Wii Remote near by? Check out the files from SVN and compile with Eclipse CDT. svn checkout https://svn.projects.openmoko.org/svnroot/gestures In gesphone folder, there's a shell script. Run it with ./gesphone.sh --load call/call.ges Follow the instructions on the screen. You should be able to see some accelerometer values when a sudden motion is determined. The classifier actually does this: separated normal moves from sudden moves (gestures). If you think it's too sensitive, you can always re-estimate it for your own taste with the gesapp In gesapp folder, there's also a shell script. Run it with ./gesapp.sh --new-class call/noise.gauss (for noise) and ./gesapp.sh --new-class call/motion.gauss (for motion) To train ./gesapp.sh --train-class call/noise.gauss and ./gesapp.sh --train-class call/motion.gauss (for motion) There's still a problem with the training: when more training sessions occur, the values in the covariance matrix will converge to 0.0 (as expected) and then when the determinant is computed it will end up to be 0.0 and when the probablity density function divides with this determinant which is 0.0, it will give nan. I'll have to enforce a minimum value for the covariance matrix. Thanks, Paul http://www.borza.ro
Re: application for biking/fitness/training
Am So 8. Juni 2008 schrieb Marcus Bauer: > On 6/5/08, Jens Meyer <[EMAIL PROTECTED]> wrote: > > 2. fitness (with bluetooth heartrate-sensor) > So not USB seems to be the topic to investigate, but BT profile and protocol /jOERG signature.asc Description: This is a digitally signed message part.
Re: application for biking/fitness/training
hello jens, should be no problem to integrate fitness sensors. question is if there are any available that -one way or other- interface with the USB. A quick search on google seems to indicate that most of them are proprietary? On 6/5/08, Jens Meyer <[EMAIL PROTECTED]> wrote: > Hello all! > > After some interesting information from some of you about the great > GPS-chip in the Freerunner before some weeks I considered not to buy an > external/additional GPS-handheld. Yesterday while surfing I found > incidentially the Magellan Triton - but after detailed view of the > Triton-image the "Freerunner" and all his possibilities came into my > mind immediately... ;-) > > I would like to use the Freerunner for biking and training-/ > fitness-purposes also. The specialized reference-product for this is > IMHO the Garmin Edge: https://buy.garmin.com/shop/shop.do?cID=160&pID=10885 > Of course there are several things which can the Freerunner do better... > > Is there any bicyle-/training-application in combination with GPS under > active development? > I found a short thread about this in December 2007 only. > The project-database shows the follwong projects: "Coach", "Mokosport", > "GPS 3D Outdoor Navigation" and GPS-based "GPS Sight" and "TangoGPS". > > Of course I see the steady releases of the great TangoGPS but from my > point of view this is only one part of such an application. Are there > more training-specific applications under development? > > Some suggestions which features may be integrated in such a solution: > > 1. GPS > - show actual position on map > - load map (online connection) > - store/use offline map > - show actual track > - store tracks, export tracks > - save waypoints, export waypoints > - load/show/import tracks > - import/show waypoints > - send actual position to server, HTTP-request/SMS > - show actual speed > - show average speed > - show top speed > - show distance > - show altitude > > 2. fitness (with bluetooth heartrate-sensor) > - show heart rate > - save heart rate (with time/position) > - show average heart rate > - give signal when leaving special heart rate zone > - clock: show training period > - stop training period while not moving (auto pause) > - save laps, show lap-specific information > - export training-info (track, heart-rate/altitude/speed per trackpoint) > to external application > ... > > As far as I can see many of these GPS-functions are already possible > with TangoGPS. So my ingenuous question is how would you develop such an > application? Add some fitness-functions to TangoGPS (into the main > application - as external modul if possible?) or create a completely new > application? > Is anybody working on that or interested? > > Sorry for my nonprofessional questions. I would like to contribute as > much as I can to such a projekt. But actually I am "only" a > PHP-developer with Linux-skills - and only an interested reader of the > C-source... > > Any suggestions are welcome! > Kind regards, Jens > > > > > > >
