FOSDEM 2010 Devroom
Hi guys, due to some lucky (for us) coincidences, even after our request for a devroom was officially declined, we got hold of a small time slot to gather and hold some presentations. We have cooked the following timeslot: http://fosdem.org/2010/schedule/devrooms/openmoko Hope to see you there, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
ANN: Vibration API
Hi folks, in order to expand the list of (hardware) platforms FSO runs on, I had to create a Vibration API. Previously, we just used the LED API for vibrators, since on the Openmoko devices, the vibrator is just a LED class device. On the Android/Linux-inspired kernels for HTC devices (such as the Touch Pro), the vibrator is exported via a timed-output class device. On the Palm GNU/Linux devices, it's exported via a completely different way. Hence, reusing the LED class API didn't cut it anymore. As of today, we can talk to the vibrator via /org/freesmartphone/Device/Vibrator/0 served by org.freesmartphone.odeviced, the API is documented at http://docs.freesmartphone.org/org.freesmartphone.Device.Vibrator.html Please adjust applications as you see fit. Regards, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Hello and possible "broken zhone" question?
Hi, please note that smartphones-standards is concerned about API disussions, not so much implementations, which is on topic for smartphones-userland. As for your problem, you might run into the dbus timing problem that's happening on debian systems. Try patching dbus -- please see the latest posts on smartphones-userland. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Fwd: A big and important change in opimd: Types.
Awesome, good work. Thanks, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Framework Ready
Dear Chaitanya, sorry for the delay in answering. I have cc'ed this mail to smartphones-standards, which is the best place to talk about this. > 1. I wanted to know if there was a signal emitted/ any other way > for a program to know when the framework was ready after a reboot. > Basically, I want to be able to run launcher as through a startup script - > but start getting the data from opim only after the framework is ready to go. > Also, how can I check that the framework is ready or not, in case launcher is > started after the framework is already up? There is no global signal for the framework (since it is composed of multiple resources, subsystems, plugins, and processes), however you can listen to a) ResourceAvailable signals from ousaged, if you're interested in actual resource availability, or b) NameOwnerChanges from dbus, if you're interested in whether a subsystem is already serving. > 2. Is the alarm interface ready for setting alarms that will wake up the > freerunner? How do I go about doing this. I have multiple alarms (b'day > reminders, tasks etc). > The documentation mentions that I should use the PIM events - but I dont > see any info in that. Is that something in the pipeline? By now the Alarm interface for opimd should be ready. Can someone from SHR comment, please? > How do I do this before the PIM events interface is ready? In case the PIM alarm interface is not ready yet, you can always use the low level alarm interface from FSO that can wake up one by one. You need additional code that always programs the 'next' event though. > 3. How can I reduce the logging to /var/log/frameworkd.log? Change /etc/frameworkd.conf, e.g. log_level = INFO instead of DEBUG. > I've also noticed that the phone responds faster to an incoming call now - > though it keeps vibrating for about a sec or so even when I can start > hearing the other side. This is a definite improvement over the > erlier state where the conversation started after the vibration was > over. But, can the vibration freq be reduced? Do you mean the pulse or the actual time how long it vibrates? The fact that it still vibrates for a short time after you pick up the call is merely due to the slowness of the whole system. With current distros using the compiled fsodeviced and fsousaged this should be much better, and as soon as we have oeventsd in Vala as well, it will not be a problem anymore. Best regards, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: /var/lib/python-support/python2.5/framework/?
Am Montag, den 19.10.2009, 16:15 +0200 schrieb arne anka: > > pyc files should be generated during the package configuration, so > > `dpkg-reconfigure fso-frameworkd` should update the pyc files. This > > system has been introduced to support multiple python versions with > > one package (of course only if the package's source support it). > > interesting. i always thought, python does that automatically if either no > .pyc is present or the .py is more recent. You are both right. You can pregenerate them, but python does that automatically as well. Depending on the configuration, it might also emit .pyo files. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: new positioning API
Am Mittwoch, den 14.10.2009, 10:39 +0100 schrieb Al Johnson: > On Wednesday 14 October 2009, Michael 'Mickey' Lauer wrote: > > On a slightly related note (please open a seperate thread, if anyone > > wants to talk about that), now that gypsy is more or less dead and the > > protocol didn't find much distribution/acceptance, I seriously consider > > proposing to ditch it for FSO2 and come up with a sane GPS dbus API for > > fsogpsd (we talked about that last year on this mailing list). Your work > > on a GPS configuration API could be the first bits of the new style. > > If we're looking at a fresh API we should be looking at positioning in > general. We have other sources of data such as cell lookup and magnetometers. > In cars we may have access to speed data over CAN bus. We should provide some > reasonably direct interface to each sensor available, plus a best estimate of > position, orientation and velocity bsed on the available data. True, however I see this as seperate layer above GPS, which projects like geoclue work on as well. I always like to provide multiple layers of abstraction for application programmers to chose, this approach is manifested by things like org.freesmartphone.GSM (lowlevel) -> org.freesmartphone.Phone (highlevel), or org.freesmartphone.Device (lowlevel) -> org.freesmartphone.Usage (highlevel). I think we should still create a GPS level protocol that fits the dbus model better than gypsy. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: API needed for configuration of the GPS
Hi Baruch, > The GPS in the FR can have different modes of operation, currently there > is only one mode usable, which is the one that is set by frameworkd. I'd > like to add APIs to add some measure of control over the GPS > configuration. > > Such configuration includes: > - SBAS (active, uses test signals, various SBAS parameters) > - NAV2 (pedestria, car, sea, flight also a filter for minimum > movement) > - RXM (fast acquisition or high sensitivity or auto, also the fix now > feature) > - FXN (fix now parameters) > - Rate of messages, we could reduce or increase the rate according to > need, it also changes power consumption of the GPS module. This is all very interesting. In fact, we had this on our agenda since the 2008 FSO meeting @ Openmoko Taipeh. Alas, due to the downsizing of Openmoko Inc, we never got around to actually doing it. > I only really care about SBAS and NAV2 at this stage, the rate change > also seems like an interesting and useful option. The others are less > interesting, to me. > > First thing is to ask if there are objections to adding such APIs? > Then, where do I set this? Under the existing UBX module? It makes sense > to me since it's tied down to the UBX implementation and is a > proprietary extension rather than a known standard. There may even be > differences between U-blox 4 and 5 and 6. Please go ahead and implement it in the current UBX module, however lets talk about the API first. Could you come up with an RFC that while being inspired about the UBX possibilities bears no UBX-specifics in the API? On a slightly related note (please open a seperate thread, if anyone wants to talk about that), now that gypsy is more or less dead and the protocol didn't find much distribution/acceptance, I seriously consider proposing to ditch it for FSO2 and come up with a sane GPS dbus API for fsogpsd (we talked about that last year on this mailing list). Your work on a GPS configuration API could be the first bits of the new style. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: omusicd
On Monday 14 September 2009 17:12:38 Frederik Sdun wrote: > I'm writing the specs file and realized that I'm using ints at some > points which are enums. Should i replace them by strings and use string > marshalling? > The methods are: > [SIGNAL]org.freesmartphone.MusicPlayer.State( i:state ) > //possible values: stopped =0, playing=1, paused=2 > > //possible values: normal=0,endless=1,random=2 > [METHOD]org.freesmartphone.MusicPlayer.Playlist.GetMode() -> ( > i:result ) [METHOD]org.freesmartphone.MusicPlayer.Playlist.SetMode( i:m > ) -> () [SIGNAL]org.freesmartphone.MusicPlayer.Playlist.ModeChanged( > i:mode ) > > I think FSO prefers the string version. Yes. Enums are not a good choice in DBus. Please convert them to all-lower- case-strings. We can use the libfso-glib way of string-via-enum-marshalling here to deal with enums for static dbus. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] Default to STDERR if no logger is specified. Remove NullLogger in the process
Hi Sudharshan, the NullLogger is for maximum performance(*), hence we definitely want to keep it. I can see the desire of default going to stderr though and will apply that part of your patch accordingly. Cheers, :M: (*) Unfortunately even the NullLogger wastes some cycles due to the fact that Vala is missing VA_ARGS on Vala level (it's only present on VAPI level) -- hence we're doing things like logger.info( "some message with many format arguments %d %s %.2f".printf( ... ). I'd wish the compiler could somehow optimize the time consuming call to printf, if it would know that the logger is throwing it away anyways. Unfortunately I'm afraid this does not work. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: omusicd
Great stuff! Can't wait to write an app using this API. Livestreams would be absolutely the icing on the cake, btw. :) I'm addicted to SOMA.FM internet radio :) Thanks a lot for your work! Can you create an XML file and upload it to the specs directory, so we have everything documented? Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Device Orientation API
On Wednesday 09 September 2009 13:23:55 Nils Faerber wrote: > Michael 'Mickey' Lauer schrieb: > > Hi folks, > > > > I'm sketching a simple device orientation API for FSO. The purpose is to > > be informed about changes in the physical device orientation. My first > > take is at > > http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesm > >artphone.Device.Orientation.html;hb=HEAD > > > > Basically, it's sending you a string whenever the orientation changes. > > Valid substrings contain "portrait", "landscape", "faceup", "facedown". > > > > Comments? > > Sind it will for sure be supposed to become an general interface I would > suggest not to use names which can be confusing (if landscape is the > native orientation it becomes messy) but rather use degrees, i.e. > "45", "90", "180", "270" > > Which represent the number of degrees turned from native device > orientation. Hmm, good point. Let me think about this. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Device Orientation API
On Tuesday 08 September 2009 01:18:32 Nicola Mfb wrote: > Nice! in the past I heard about accelges integration, something moving? Unfortunately not. This work is completely independent of accelges. I always hoped that Paul would help us integrating accelges into FSO, but that didn't quite happen. In order to do something meaningful with our accelerometers in the meantime, I decided to start with some simple algorithms that would at least cover some common cases like waking up / suspending on certain orientations or running an application or rotating the screen based on orientation. Once we have something simple going, we can eventually revisit accelges and its algorithms and integrate more complex processing into FSO. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Device Orientation API
Hi folks, I'm sketching a simple device orientation API for FSO. The purpose is to be informed about changes in the physical device orientation. My first take is at http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD Basically, it's sending you a string whenever the orientation changes. Valid substrings contain "portrait", "landscape", "faceup", "facedown". Comments? :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [Shr-Devel] New features in opimd queries
On Thursday 27 August 2009 12:07:09 Sebastian Krzyszkowiak wrote: > And: > > The Problem with a timestamp string is: what format does it have? In this > > case we have to include the format defenition into the API. Then it's a > > lot easier to use unix-timestamps they are easy to parse and compare... > > In my opinion we should use unix timestamps and that's what i'm > implementing in my test apps. Correct. Epoch(UTC) should be the native format on dbus API level, but remember to include a flag that indicates whether timestamps are always following local time or stick to the timezone they have been entered (which could be handy at times). UI can convert this to fancy things. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: New features in opimd queries
Great stuff, thanks for the update. As this phase of FSO is all about getting the interfaces right, I'd wish we could get some feedback from application programmers about the opimd API. Guys? :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
FSO core team founds BGB company
Braunschweig, Germany, 2009-07-29. For immediate release.
The freesmartphone.org core-team founds a BGB company to facilitate
the further development of free and open source middleware for
Linux-based mobile systems: "Lauer, Lübbe, Schmidt, Willmann,
freesmartphone.org GbR".
The core-team members of the freesmartphone.org project today announced
the founding of a legal entity offering consulting, training, and
implementation services around the freesmartphone.org middleware
platform, also known as FSO[1].
"We now have a single point of contact for both commercial and
non-commercial parties who want to use our services to create compelling
solutions. This is of interest for groups or individuals creating new
devices or freeing existing devices ("anti-vendor-ports") and who
decided to incorporate the FSO middleware", says Dr. Michael Lauer,
founder of the FSO project. "If you care about the further development
of this platform or if you need guidance for tailoring or customizing
the FSO middleware, contact us via E-Mail at
coret...@freesmartphone.org".
With todays' smartphones evolving into ubiquituous companions, a gap has
emerged between widely used FOSS components like the Linux kernel and
core system libraries on one side, and end-user applications on the
other side. The lack of a complete free mobile software stack hinders
innovation and leads to reinventing proprietary solutions for services
middleware.
FSO's mission is to close this gap by designing and developing solid
middleware for mobile systems in an open fashion; this refers to not
only publishing source code under open source licenses, but also to
sharing the whole design and development process with the community and
giving both commercial and non-commercial entities a way to co-drive and
steer the process.
Built on top of the Linux kernel, FSO implements high level services for
mobile application development, accessible via the DBus interprocess
communication standard. Leveraging the FSO APIs allows the developer to
concentrate on solving application domain problems, such as business
logic and presentation of data, without having to worry about the device
specifics and low level details, such as how to access resources,
telephony, location awareness, data storage, etc.
About freesmartphone.org:
Previously funded by Openmoko Inc, freesmartphone.org is a collaboration
platform for open source and open discussion software projects working
on interoperability and shared technology for Linux-based smartphones.
freesmartphone.org operates on the services layer (middleware) and
offers APIs and reference implementations that support modern
interconnected mobile devices. To provide reference solutions,
freesmartphone.org works closely together with various device-specific
communities such as the Openmoko, OpenEZX, and HTC-Linux groups. The FSO
team honours and bases on specifications and software created by the
freedesktop.org community.
[1] http://www.freesmartphone.org
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: OT: LinuxTag '09 in Berlin, Germany
On Tuesday 16 June 2009 18:50:41 Nils Faerber wrote: > I am currently wondering if forking the Android would in theory be > possible? Could some open source enthusiast community "hijack" the project? Code-wise, I don't think Android/Linux provides much value to the GNU/Linux world, it's way too diffferent to advance the movement of free software beyond some kernel patches of questionable style. Marketing-wise it's ambivalent; on the upside it strengthens the brand Linux, on the downside it communicates a wrong picture of openness, if you consider a platform being a combination of hardware and software. Concept-wise, it's nice. We should definitely look at the architecture and "steal" the best concepts. > Oh well... I am not very keen on Java programming... :) So let's stop > this Android philisophical stuff, there's more important things to do... Word! :) Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: OT: LinuxTag '09 in Berlin, Germany
On Tuesday 16 June 2009 16:05:35 Nils Faerber wrote: > This Android stuff is by far not as bad as > I thought. I am really amazed about the stack's high quality (in terms > of speed and stability) compared to the comparibly short time they had > to develop it. Uhm Google bought Android Inc. in 2005 who already have been working 2 years on Android with a small number of highly qualified engineers. Let's guess it was just 5 guys -- that makes it 10 manyears until 2005. Until 2008 Google worked 3 years on it with ... guessing again .. 50 engineers. That makes an additional 150 manyears. I would consider 160 man years as everything but a "comparibly short time". :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: OT: LinuxTag '09 in Berlin, Germany
> If I remember correctly there was a hacking area somewhere in the > basement that was free for everyone to use. It provides tables, chairs, > network, power, etc. Everything we need. > Do we want to be present with a booth or just be there, meet and be open > to visitors? The latter could be done in the hacking area too. We could > setup a poster/banner that makes the gathering visible and simply meet > there for a few days and hack along, exchange ourselves f2f, etc. > For me this is now the most appealing alternate solution, although I > would have like to make a booth but I don't want to step into that orga > turmoil right now... This actually sounds like a good idea to me. Lets make a non-booth, combining the advantages of not having to manage it all the time, having a relaxed environment where we can show some interested folks what we have, and being able to just hack on things in between. I like that. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: OT: LinuxTag '09 in Berlin, Germany
Dear Christian, thanks for your mail! Some of us will definitely be present on the LinuxTag, alas I don't know yet whether we are enough to cover a booth for the whole time. It would certainly be a good opportunity (especially now that we are looking for funding) to show our work and raise some awareness for the state of Linux on open and semi-open mobile devices. Guys, can I see a show of hands? :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Capitalization for freesmartphone.org
Hi Luca, > On Wed, 13 May 2009 12:10:50 +0200, Michael 'Mickey' Lauer wrote: > > the name is freesmartphone.org. If used on the beginning of a > > sentence, you may capitalize the first F. > > I would prefer not and now that I have checked it seems the main > freesmartphone.org website as well as others, e.g. freedesktop.org, do > like that :-) ACK. > > The term FreeSmartphone.Org should only be used as legend in > > conjunction with the acronym. > > Should I assume that the acronym alone must be lowercase, i.e. fso? Or > the acronym must never be used? In formal writing (package descriptions etc.), I would not use it at all. In informal writing (mailing list posts, IRC, etc.) it has its place as FSO. I wouldn't use "FreeSmartphone.Org" at all since it look really ugly ;) > Thank you for the precise explanation: I will fix it in every Debian > package, at least before uploading to main. Great, thanks for your work! :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Capitalization for freesmartphone.org
Hi Luca, the name is freesmartphone.org. If used on the beginning of a sentence, you may capitalize the first F. The term FreeSmartphone.Org should only be used as legend in conjunction with the acronym. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Enumerations are in!! (Was: Enhancements of the Vala bindings)
Hi Didier, > The final XML syntax is: > > ... > >... > > >fso:type="org.freesmartphone.GSM.CallStatusEnum"/> > > >... > > name="org.freesmartphone.GSM.CallStatusEnum"> > > > > > > ... > > vala-dbus-binding-tool has support for it is in its master branch. [1] > > The Vala support for it is in the dbus-experimental topic branch of our > vala-lang.git repository. [2] > > The commits have been reported to the pending-upstream-move branch as > are all the things that are needed to build/execute correctly stuff from > the FSO and SHR projects. > > Also I commited an example the specs.git. [3] Sweet! Excellent job, man! > Enjoy! I hope a lot of people will help us to specify all the > enumerations in the specifications. I hope so, too. It's not exactly rocket science, but rather a lot of boring work ;) Anyways, I'll start this weekend. Thanks, again! Mickey. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Meeting minutes
On Wednesday 22 April 2009 10:55:51 Julien Cassignol wrote: > On Wed, Apr 22, 2009 at 9:51 AM, Daniel Willmann > > wrote: > > * opimd integration in ophoned (include contact info) > > As well as contact modification/deletion. I don't know about messages > yet. Klaus from SHR developed a working contacts reader from opimd, he > hit the aforementioned issues. We briefly talked about that. As it stands, we have no one who is really into PIM in the team, so one of us needs to seriously look into it. I don't think this will happen before the conference though. > > * Discussion reference architecture UI/FSO (Mickey) > > I'm interested in that too, and I'd like us to discuss about some > convergence between what we did with libframeworkd-phonegui and a > generic view on the UI, callable on top of dbus. We already have a lot > of material on SHR for that. Very good. The basic idea here is that we all share the same vision of a "reference" architecture of a free mobile (phone) platform. Only if we have a goal -- albeit a major and far away one -- we can seriously follow a path. > > * Bring SHR to OE (Stefan, Daniel, Jan, Mickey) > > I don't know if this will be "truly" necessary as I think we'll commit > by then. But it'll be necessary to talk about what we need as a > full-fledged distro. Right. This ties into the idea of our common reference platform, i.e. how does the SHR-Project sees its responsibilities towards such a platform. > I'd like to add something in the lines of "SHR Architecture" would be > necessary, related to the reason ophonekitd is there, plus how we want > to handle multiple UI libraries and such. I'd like to do that talk. Yes, this we should have as a seperate talk. > > = Different issues = > > * framework freezes > > * kernel resume fails > > -> Wasn't reproduceable with current images, need to keep an eye on > > The CPU resource staying requested is a big issue too, IMHO, c.f. > http://trac.freesmartphone.org/ticket/404 I'm planning to look into this soon. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [libfso-glib] Enhancements of the Vala bindings
On Saturday 18 April 2009 14:43:38 Didier "Ptitjes" wrote: > >> Thus it can easily be built as part of OE. If one feels like cooking a > >> recipe for it (and vala-dbus-binding-tool) that would be super cool! > > > > If no one beats me to it, I'll do that. > > Great! Thanks! Done as per http://cgit.openembedded.org/cgit.cgi?url=openembedded/commit/&id=d0e0791eb9562fc0d3ade781cfe330f118537f84 How do you want to handle generating the interfaces on the fly? Via autotools integration or OE integration? If the latter, then we need to add a build class that calls vala-dbus-binding-tool with the appropriate parameters. If the former, then we should be already finished. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Meeting minutes
On Wednesday 22 April 2009 14:43:39 Timo Juhani Lindfors wrote: > Daniel Willmann writes: > > * ogsmd loose ends are done (more or less) > > Some improvements would require too fundamental changes > > Which ones would these be? Everything but small fixes has to wait until milestone 5.5 is out, like proper freeze/thaw support, handover to 3rd party channel consumers (for data call), abstraction for commands that need to be sent multiple times or until sucess, etc. > I'd like ogsmd to cope with cases where > calypso crashes Me too. > or goes to "every attempt to start gprs fails with CME > ERROR" state. Never seen that one. > > * Switch Unsol-Handling back to the way it was > > Can you elaborate a bit on this one? I changed the unsolicited handling via %CUNS=0 to be more agressive (read: unsolicited allowed at _any_ time), since we now have a parser that copes with it. For some reason, this shows a bug in the firmware where AT%EM results are thrashed, so we will revert to %CUNS=2. This won't change anything but fixing AT%EM again. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [libfso-glib] Enhancements of the Vala bindings
Hi Didier,
> > Looks good to me. This only refers to string-enumerations, right? I'm all
> > for that, since I don't think int enumerations make much sense over dbus
> > -- however, perhaps we should encode a type entity here from the start to
> > support folks that have special needs:
> >
> > > name="org.freesmartphone.Phone.CallStatus">
>
> Yeah, I was just thinking there was no interger enumerations in the
> FSO's APIs... (yes you can spank me!! :))
>
> Maybe we should use the same format for type as dbus ? type="s", no ?
Good plan.
> >> 2) DBus errors
> >>
> >> ...
> >>
> >>
> >>
> >>
> >
> > Ok. Although for clarity we perhaps should make this , since
> > it's not a part of the standard XML introspection notation (which is a
> > crazy omission, but anyways...).
>
> Okay can we take profit to change that ?
Yes, let's change it. Should be a simple 'sed' job.
> >>...
> >>
> >
> > I wonder whether we need to have this in the method specified, rather
> > than just documented. Do we gain any static testability from it?
>
> Ok maybe we should have only have a throws="1", that would let us generate
> :
>
> public void set_antenna_power(boolean antenna_power)
> throws DeviceError, DBusError;
>
> In fact I thought that the error tag were from DBus spec. But if it is a
> FSO extension then, I would be very glad if we can transform this as the
> enumeration proposal above:
>
>
> ...
>
> ...
> fso:throws="org.freesmartphone.GSM.DeviceError">
> ...
>
>
>
>
>
>
>
>
> ...
>
> That would be more consitent and then we could have cross interface
> error-domains, which arise to happen very commonly.
Agreed.
> Then we could generate the following code in Vala:
>
> [DBus]
> public errordomain DeviceError {
> NotPresent,
> Timeout,
> Failed
> }
>
> public void set_antenna_power(boolean antenna_power)
> throws DeviceError, DBusError;
>
> Note that I let the DBusError on the throws clause, because their might
> arise any technical DBus error. I take on my own to implement that on
> the Vala side. (And Jürg already told he is OK with that.)
OK, good.
> >> 3) Transparent proxies
> >>
> >> ...
> >>
> >>...
> >>
> >>
> >>
> >>
> >> >>fso:type="org.freesmartphone.Phone.Call"/>
> >>
> >>
> >> >>fso:type="org.freesmartphone.Phone.Call"/>
> >>
> >>
> >
> > Can you elaborate on that with an example?
>
> Sure, a Vala example:
>
> [DBus (name = "org.freesmartphone.Phone")]
> public interface Phone : GLib.Object {
> ...
> public abstract PhoneCall create_call(
> string number, string protocol, bool force)
> throws DBus.Error;
> ...
> }
>
> [DBus (name = "org.freesmartphone.Phone.Call")]
> public interface PhoneCall : GLib.Object {
> ...
> }
>
> would make this possible:
>
> Phone phone = (Phone) connection.get_object(
> "org.freesmartphone.Phone",
> "/org/freesmartphone/Phone",
> "org.freesmartphone.Phone");
>
> PhoneCall call = phone.create_call("123456", "gsm", false);
>
> instead of:
>
> Phone phone = (Phone) connection.get_object(
> "org.freesmartphone.Phone",
> "/org/freesmartphone/Phone",
> "org.freesmartphone.Phone");
>
> DBus.ObjectPath call_path = phone.create_call("123456", "gsm", false);
> PhoneCall call = (PhoneCall) connection.get_object(
> "org.freesmartphone.Phone",
> call_path,
> "org.freesmartphone.PhoneCall");
>
> You might say there is no big difference, but in fact it is really. This
> makes possible to use the Phone object as if it was really a local
> object (modulo the fact it can throw DBus technical errors). And the
> mechanics to navigate through a set of DBus objects are completely
> abstracted from developers' perspective.
Ah, I understand now. Yes, that's slick -- I like it.
> Note that I intend to add a command-line option to
> vala-dbus-binding-tool to enable/disable that form of generation.
>
> On the Vala side, it would still be possible to have methods returning
> object paths. The Vala compiler would behave differently on knowing the
> fact that the returned object is a DBus object or not. Also, this would
> work for object path as return value or as in arguments (like for
> Phone's signals in this specific example).
>
> Finaly, this will be easily usable on the server side too, by returning
> a Phone implemeation that implements the "string get_dbus_path()" method
> (sorry I don't remember the exact existing method name).
>
> ...
> public PhoneCall create_call(
> string number, string protocol, bool force)
> throws DBus.Error {
> ...
> return new FsoPhoneCall(...);
> }
> ...
>
> public class FsoPhoneCall : PhoneCall, GLib.Object {
> ...
>
> public string get_dbus_object_path() {
>
Re: [libfso-glib] Enhancements of the Vala bindings
On Friday 17 April 2009 15:03:25 Christian Gagneraud wrote: > Yesterday, i was working on QT4 bindings (at least give it a try), as > i went through the FSO DBUS specs, some questions start rising in my > heads. Of these questions some are related to what's being discussed > in this thread, so here i am! :) Welcome on board! > Why do you think so? Enumerations being a set of predefined values, i > don't see the point to send strings over DBUS, using integer constants > means less overhead in DBUS and in the clients as well, it is far less > CPU consuming to compare integers than strings. > Or perhaps i missed something... There seems to be a consensus that when working with DBus in the first place, it's more important to have self-descriptive formats than to save every possible bit of bandwidth. Please take a look at modern DBus APIs, they use string constants a lot. Especially since you can use DBus from interactive prompts, it makes a lot of sense to use descriptive formats. > >>... > >> > > > > I wonder whether we need to have this in the method specified, rather > > than just documented. Do we gain any static testability from it? > > For C++, it can be useful as function members can have a exception > specification like: > void SetAntennaPower(bool antenna_power) throw(NotPresent, Failed); The problem is that it's not giving you the specifics you want, i.e. it's not an API contract that gets enforced somewhere. Moreover, the DBus method could call other DBus methods which raise different errors. Regards, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [libfso-glib] Enhancements of the Vala bindings
I have reviewed the telepathy format when I started working on the documentation of our APIs and found it overcomplicated. If you guys (more input from different people here, please) think we should use it and if someone comes up with a patch that a) converts the existing documentation root files to the new format and b) switch the build system to use the new tools required by the telepathy format, then I have not a strong opinion to not move. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: FSO Opimd - some questions
Leonti, I'd love to answer these questions, but I can't. I'm not familiar enough with the opimd code base at the moment and no one else is, since the original author is missing in action -- and will probably not return. I'm willing to spend some time understanding opimd right after we released fso 5.5, but until then I need to concentrate on fixing some bugs. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [libfso-glib] Enhancements of the Vala bindings
Hi Didier, thanks for the update regarding your developments -- it's much appreciated, especially for the folks who can't hang around on IRC 24/7 ;) > Thus it can easily be built as part of OE. If one feels like cooking a > recipe for it (and vala-dbus-binding-tool) that would be super cool! If no one beats me to it, I'll do that. > 1) Enumeration values: > > ... > > ... > > fso:enumeration="org.freesmartphone.Phone.CallStatus"/> > > ... > > > READY > ... > Looks good to me. This only refers to string-enumerations, right? I'm all for that, since I don't think int enumerations make much sense over dbus -- however, perhaps we should encode a type entity here from the start to support folks that have special needs: > 2) DBus errors > > ... > > > > Ok. Although for clarity we perhaps should make this , since it's not a part of the standard XML introspection notation (which is a crazy omission, but anyways...). > ... > I wonder whether we need to have this in the method specified, rather than just documented. Do we gain any static testability from it? > 3) Transparent proxies > > ... > > ... > > > > > fso:type="org.freesmartphone.Phone.Call"/> > > > fso:type="org.freesmartphone.Phone.Call"/> > > Can you elaborate on that with an example? Thanks, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: How can I help in founding FSO?
Dear David, thanks for your mail. > I know I have send you a mail directly to you about this but I belive > is better to put it to disscuss on the list to more brainstorming Agreed. We should make this public right from the beginning. Multiple people have approached me with regards to community-based funding -- there's a whole lot of organizational questions to be answered though before we can do something like that. I will discuss this with the team over the easter weekend and then post something more with regards to our options. Thanks for getting this started! Mickey. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] Add Display interface to cornucopia
On Thursday 09 April 2009 14:58:48 Sudharshan S wrote: > On Thu, Apr 9, 2009 at 4:07 AM, Michael 'Mickey' Lauer wrote: > > On Wednesday 08 April 2009 20:50:27 Michael 'Mickey' Lauer wrote: > >> Commited, thanks a lot! > >> > >> One nitpick: Since the time you did fsodevice, a lot of things have been > >> added to Vala posix support. I'd rather use no C helpers, if possible, > >> so please have a look whether you can do the ioctl directly from within > >> Vala. > > > > Done :) > > Okie dokie. Will use 4 space indentations and look into the ioctl thing > asap. Posix.ioctl seems to work fine here for simple cases such as the display blanking (see last commit), I hope it will also work for more complicated as the rtc, could have a look at that? :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Future of an Open Phone - Diner at FSOSHRUDCON
Thanks Stefan for professionalizing this! I'm also rather overorganized than underorganized, so please continue. Regarding the program, I'm in for one talk covering "freesmartphone.org -- Past, Present, Future" Rough outline: * From the iPaq to the Neo (6 years of struggeling for open hardware) * What application developers want * The state of things * Plans for the future Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] Fix compiler errors, and a little cleanup in cornucopia
Applied (with style changes), thanks! :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Couple of questions regarding the Cornucopia code organization
Hi, > Am I right in thinking that each plugin should be organized as follows > > 1.) All entry points must be in plugin.vala > 2.) The plugin sources must be under fsodeviced/ or > fsodeviced/kernel26_ if it is using the kernel26 > interfaces. Yeah, both correct, although neither one is a must, I think it's good for organization. The monolithic kernel26.py was just because of lazyness, we should split it in FSO2 same as you split it in odeviced. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: No DBus signal when call ongoing, but signal strength changes
Am Dienstag, den 24.03.2009, 19:37 +0100 schrieb Onen: > Onen wrote: > > I made some experiment with > > gsmnetwork.GetStatus() > > > > I have a signal strength of 95. When I have a call outgoing or > > incoming, the strength returned by gsmnetwork.GetStatus() > > falls to 80 or so. > > > > Nevertheless I get no org.freesmartphone.GSM.Network.Status signal. > > > > Is this normal behavior? > > > Some more testing shows that when the signal strength changes, we > receive a org.freesmartphone.GSM.Network.SignalStrength signal, but no > org.freesmartphone.GSM.Network.Status. > > Is this supposed to be normal behaviour? Yes, it is. org.freesmartphone.GSM.Network.Status is only sent on network registration changes (such as handover to a different cell, or losing registration). > If so, I would propose to add a > comment on the specs (I can write a patch for this, if you want)? Yes, please. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: FSO/SHR Meeting, a.k.a FSOSHRUDCON (c) mrmoku
Dear Julian, I'd be very interested in such a gathering. Let me toss a vote for Berlin. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: GetNeighbourCellInformation, MCC and MNC
Am Montag, den 09.03.2009, 21:24 +0100 schrieb Onen: > the GetNeighbourCellInformation() method in > org.freesmartphone.GSM.Monitor interface does not provide MCC and MNC > fields. MCC and MNC is a higher level functionality connected to the notion of a service provider which you are registered with. The cell monitoring gives you access to the LAC/CID, which is on a lower level. > Is it safe to say: it is impossible for neighbour cells to have > MCC and MNC different than the one of the serving cell, provided by > org.freesmartphone.GSM.Network GetStatus()? IIRC multiple MCC and MNC may be served on one cell. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: GSM and VoIP
Hi, >Quick question about the smartphone and VoIP. I would like to work on > a scenario in which when you're in your office your OpenMoko handset > becomes an extension of the Internal PaBX, using the WiFi connection. > This means that your handset is contactable either by it's GSM phone > number or via VoIP. You could of course be contactable by a number of > VoIP accounts. > > My question is how the framework will deal with multiple ways of > connecting. Obviously if I'm connected on a GSM call I can't accept a > VoIP call and vice versa. I may be wrong but I think that this > functionality belongs at a low level in core of the framework? Correct. This is what org.freesmartphone.Phone was supposed to handle. It's a higher level phone call API that could contain a VoIP abstraction as well. Eventually, apps may use that instead of org.freesmartphone.GSM.Call and just resort to direct calls if necessary. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: 'GSM' sometime means GPRS, sometime not
Am Samstag, den 07.03.2009, 12:22 +0100 schrieb Onen: > I was wondering if it was not misleading to have GSM and GPRS distinct > in one method, and GSM meaning GPRS in another? Yes, that's misleading, but it comes straight of out the GSM specs. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Google Summer of Code
Hi guys, since there is no Openmoko GSoC this year, we're going to apply (together with the SHR project) as mentoring organization. We put a list of ideas on our pages, if you some more, please feel free to add to http://www.freesmartphone.org/index.php/GSoC_Ideas Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Default FSO system group
I don't have any objections to increasing the granularity of access control, the fact that [in OE] everything runs under the same user and all services share one dbus permission file is merely due to a mixture of not enough time and being lazy. It was -- however -- always my plan to have this fine granular control, that's why I decided to split the FSO architecture into individual subsystems [and plugins] in the first place. More over, once we move from the Python implementation to another reference implementation, the individual subsystem will be seperate processes again. Three random examples to make it clear what I'd like to see: 1.) Everyone being denied to access the serial device node except ogsmd, 2.) Everyone but ophoned and opimd being denied to call ogsmd, 3.) Everying but ousaged being forbidden to call any frameworkd's object org.freesmartphone.Resource, _if_ ousaged is present in the system. Some of these might be a bit too extreme, we need a couple of iterations here. Bottom line though is that I'd appreciate patches going into this direction. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
Am Samstag, den 28.02.2009, 00:49 +1100 schrieb Carsten Haitzler: > > Feel free to disable the idlenotifier plugin in frameworkd.conf, it's a > > one liner. (Of course I will not remove the idlenotifier at all, since > > it's all we have, if X is not running) > > if u dont have x - you dont have a functional system... That's a bit far fetched, don't impose your use pattern on others. There are tons of interesting single-purpose apps (think vertical market solutions) here that might not want to run X, but rather some UI they hooked on the framebuffer. They might even be fine with console mode, only giving input over a keyboard. frameworkd should be a nice companion as well for these kinds of patterns. > be it x or any > replacement (an fb based app) it will have the same ability as x does as it is > the one and only controller of the screen and input - so it can do the same. > > > You will then have to worry about the display being still dark when e.g. > > the PIN dialog opens, or a call arrives. Oh and please take care about > > applications that do not want autosuspend to trigger. > > apps should deactivate x screensaver as part of a toolkit call when such > actions happen. Good, lets spread the word to the application developers and have them disable the idlenotifier plugin. Screensaver also deals with suspend/resume yet? -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
Unfortunately that's not the full story. As I have repeatedly stated, "busyness" is not just about user input, but also about input from external sources. Feel free to disable the idlenotifier plugin in frameworkd.conf, it's a one liner. (Of course I will not remove the idlenotifier at all, since it's all we have, if X is not running) You will then have to worry about the display being still dark when e.g. the PIN dialog opens, or a call arrives. Oh and please take care about applications that do not want autosuspend to trigger. I absolutely not insist on _where_ that functionality is present, though I insist _that_ the functionality is present. If X/launcher/window manager wants to cover all that, be my guest, I have less work then. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
By the way... s/FSO/frameworkd/, it's late and I'm tired ;) -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
Am Donnerstag, den 26.02.2009, 23:58 +0100 schrieb Luca Capello: > Hi there! > > On Wed, 25 Feb 2009 11:54:40 +0100, arne anka wrote: > > in commun...@om there's a thread going on how to disable automatic > > screen blanking. > [...] > > something like that is my idea for fso: > > list all applications (reading the desktop files) and allow to specify > > that ie the screen should not blank. > > > > is that a) feasible and b) a task for fso? > > I guess that "fso = frameworkd"... > > Without being an expert coder nor having read documentation on it, I > would say that screen blanking (as suspension and other stuff) is not > frameworkd's business. Instead, this should be managed by X or the > window manager. I consider the rules not being a strict part of FSO, hence FSO does not blank the screen. It sends you notifications about when it thinks the system is busy, idle, etc. -- and I due to its crosslayer architecture FSO definitely knows this better than X. We can change the rules to talk to X instead of handling the blanking/dimming via org.freesmartphone.Device.Display, but I think the general concept of system idleness is indeed FSO's domain. (OTOH, I'm happy to move this to X/launcher/window manager once the functionality is there, then it's someone elses problem :D) Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
Am Donnerstag, den 26.02.2009, 20:43 +0100 schrieb arne anka: > > not so nice to have the display enabled the whole time for all users > > by default. > > that's exactly, what i _did_not_ say! > > on a very generic level: fso takes some default actions which conflict > with some specific apps. > be it blanking the screen, auto suspend, diabling sound, beeping, > vibrating, calling your mom, yelling at your girl-/boy-/animal friend, > whatever. > > how to make fso aware of such an app running and suppress the default > action (blanking the screen, auto suspend, diabling sound, beeping, > vibrating, calling your mom, yelling at your girl-/boy-/animal friend, > whatever)? > how to do it in a generic, non-app-specific way (no writing of specific > desktop files or wrapper scripts)? > > the video or gps app was a simple _example_ just to make it clear and > because everybody intuitivelly would see the point (well, almost anybody). I think there are only two ways to do this -- either with a whitelist or with launcher (window manager) assistance. Illume could provide something like a launch configuration (tap-and-hold on an icon) where things like: [ ] this app needs continuous display [ ] this app needs continuous cpu etc. can be specified. Illume could then set some X-properties or modify the .desktop file to specify this (the FDO desktop file explicitly permits extensions). -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fso: list of applications not to blank?
Am Mittwoch, den 25.02.2009, 11:54 +0100 schrieb arne anka: > in commun...@om there's a thread going on how to disable automatic screen > blanking. > navit or tangogps are likely not to be the only applications requiring > disablement of some of fso's automatisms, but powering of the screen is > the first issue that springs to mind. > > so, it occured to me: wouldn't it be sensible if fso has some way to > specify a list of applications together with the actions to take (or not) > when one of the apps is running? > > an example to make it more clear. > my last palm, a treo650, had no graffiti anymore -- to use it again, one > needed graffiti anywhere. but having graffiti enabled in every situation > conflicted with keystrokes predefined. > so, graffiti anywhere offered a list of all applikations installed and > allowed to specify for every application if ga should run or not. Interesting idea and I can understand the requirement. > something like that is my idea for fso: > list all applications (reading the desktop files) and allow to specify > that ie the screen should not blank. > > is that a) feasible and b) a task for fso? a) For sure, we just need some information from the launcher (window manager?) to tell us when an application starts. For this we can write an oeventsd trigger so you can run any actions you want as per rules.yaml. b) is actually the tougher question, I'm not sure. Opinions? -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Qi officially supported now
Hi Gismo, > Does this mean that U-Boot is no more "officially" supported by Openmoko > (including FSO)? Simple question, complex answer. My announcement didn't make things clear, so some additional points here: 1.) Openmoko has deprecated U-Boot for quite a while now and indeed Qi runs great on GTA02. I did not have the time to test Qi on GTA01, but will do that eventually. 2.) Since FSO is just middleware, the bootloader does not matter to us. 3.) I expect future images including FSO for Openmoko devices being built by Openmoko, rather than us. I really want us to get out of the distro business. In the future we will only build images for devices, when no one else cares (such as HTC, EZX, and friends). 3.1.) If Openmoko would do things to their distribution that would make it impossible to run on U-boot-based GTA02, we would do our own images again. Hopes that clears it up a bit. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Side effects of Device.SetAntennaPower(1) ?
Hi Thomas, Yes, AT+CFUN=1 resets the SIM (even if you supply the no-reset parameter). I did document this in http://git.freesmartphone.org/?p=framework.git;a=blob;f=docs/ogsmd/ti_calypso/modem though, since it's specific to the TI Calypso. Now that I have experience with more modems, I feel the urge to deprecate org.freesmartphone.GSM.Device.SetAntennaPower(), since setting +CFUN directly is not a good idea on many modems. I'd rather introduce org.freesmartphone.GSM.Device.SetFunctionality( level ), level being 'none', 'sim', and 'full'. > If this is in fact the case, and not just a gremlin in my particular setup, > then that should probably be documented in the spec for SetAntennaPower. Yes, until we have org.freesmartphone.GSM.Device.SetFunctionality() I will document this. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Qi officially supported now
FYI: I'm using Qi now on GTA02, so it's "officially" supported by FSO. In a couple of days, we're releasing milestone5.1 which fixes the read-only issue and also a bunch of other buglets that crept into ms5. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] patterns/processguard.py: workaround python-gobject bug 571890
Applied, thanks. Small note: smartphones-userland seems more on-topic for that. smartphones-standards was thought for API discussion, not implemetations. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Docs and Source
Am Thursday 05 February 2009 09:26:21 schrieb Arigead: > 1- I spend a lot of time off line and I'd like to download the API > Specifications. > > Now I did checkout the repository with the command listed on the web site: > > git clone git://git.freesmartphone.org/specs > > I opened html/index.html but all links in there point back to the Internet. > > I tried to do a "make docs" but that failed as well: > > make[1]: Entering directory `/home/john/tmp/specs/odevice' > processing xhtml/docbook-org.freesmartphone.Device.Audio.xhtml ... > warning: failed to load external entity > "/usr/share/sgml/docbook/xsl-stylesheets/xhtml/docbook.xsl" > cannot parse /usr/share/sgml/docbook/xsl-stylesheets/xhtml/docbook.xsl Sorry, mandriva here. Debian-based distributions have that at another path. > make[1]: *** [xhtml/docbook-org.freesmartphone.Device.Audio.xhtml] Error 4 > make[1]: Leaving directory `/home/john/tmp/specs/odevice' > make: *** [docs] Error 1 > > > 2- I'm building the fso-image in openembedded and I'm wondering which > recipe contains the framework. I was hoping to have a look at the code. packages/freesmartphone/frameworkd_git.bb -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: PowerSupply and PowerSupplyApm
Am Monday 02 February 2009 14:26:24 schrieb Tim Niemeyer: > is it right, that GetEnergyPercentage() is going to be removed? Correct, the whole PowerSupplyApm will vanish soon. > But how should get the GTA01 users the Power? Mike Wester contributed a power class device for GTA01 to the kernel, this one will be used. > Shouldn't be the interface the same for GTA01 and GTA02? Yes. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: FSO kernel Git branch (was Re: Hot phase for MS5 schedule)
Am Friday 30 January 2009 14:55:18 schrieb Stefan Schmidt: > Hello. > > On Fri, 2009-01-30 at 11:26, Luca Capello wrote: > > This basically is a continuum of the discussion started at [1]. I cc:ed > > the smartphones-kernel mailing list, since I guess that is the correct > > place for such kind of questions. > > Honestly I don't know which focus was planned for smartphone-kernel. If it > is about problems with the specific kernel port and FSO I think the list of > the active kernel work would be better. The idea was to have a list where general issues regarding userland/kernelspace interfaces could be discussed, i.e. sysfs, ioctls, kobject, netlink, ... to find out about best practices, getting input from both sides of the 'fence', to eventually streamline userland/kernel space interaction. Perhaps lkml is a better forum for that, but I doubt too many userland guys are listening there. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: FSO kernel Git branch (was Re: Hot phase for MS5 schedule)
(NOTE: kernel is the proper mailinglist for that, are we all subscribed to that?) Am Friday 30 January 2009 14:55:18 schrieb Stefan Schmidt: > > What is going on here? Should Debian abandon the stable branch in favor > > of andy-tracking? > > That is a decision that you guys have to make. :) > > For GTA02 I can say that we are happy with this version so far. Battery > improvement is nice and some other things are, too. I don't know the > policies you have for debian when changing kernels so I can't decide this > for you. A fact is that the kernel team more or less stopped the work on > .24 so we have to move on sooner or later. Let me follow up on that and assure you guys that we are completely NOT interested in joining the latest fashion just because -- we actually use our devices as phone and we want something stable as much as you. If 2.6.24 was full featured and bugfree on gta02, I would not have encouraged the switch in the first place. The reality is though that there are still several bugs and the only chance for us getting fixes from the Om kernel developers is to follow the (only) branch where development happens. So in short: As soon as there is a fully working and stable kernel for gta02, we will pinpoint that and after that the hurdle for any further changes will have to be justified very well. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: how to suspend with using only ogsmd?
Am Wednesday 28 January 2009 11:34:54 schrieb Timo Juhani Lindfors: > I am testing frameworkd from git to help fix bugs. However, I only > want to run ogsmd to avoid bugs in other modules since I do not truely > need them right now :-) How can I prepare GSM for suspend with this > version? > > $ mdbus -s org.freesmartphone.frameworkd /org/freesmartphone/GSM/Device > org.freesmartphone.Resource.Suspend /org/freesmartphone/GSM/Device: Suspend > failed: org.freedesktop.DBus.Error.UnknownMethod > > Worked with fso-frameworkd in debian but fails with frameworkd from > git. As per http://git.freesmartphone.org/?p=framework.git;a=commit;h=8551825260f31baea9b8b3900d92e4e98d4c6a17 you now need to use the proper bus name. Try $ mdbus -s org.freesmartphone.ogsmd /org/freesmartphone/GSM/Device org.freesmartphone.Resource.Suspend Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [Shr-devel] Opimd - some information ?
Hi folks, apart from gsm stability a major concern these days for the freesmartphone.org framework seems to be PIM support. I have to confess that the plans I had for that didn't work out yet, namely that someone else than me would take over ownership of that subsystem and continue to develop the prototype that has been implemented as part of the Openmoko Google Summer of Code. I will spare you the details, but here's the current plan: I will now take over this job for the next couple of weeks, trying to get the current implementation of opimd into a state where it can be used for the most pressuring needs -- then, take a step back and evaluate if and how it fits our application developer's usecases. So, please don't expect a concrete roadmap and a plan for action with regards to opimd now since I have to familiarize myself with the current codebase first. Anyhow I'll try to answer some of your questions now: > I have read that all the pim stuff will be handled by opimd : > contacts, messages, etc.. I have tried to search for opimd in google, > but could not find anything relevant. Could anyone please help me > know : > * when opimd will be ready to be integrated I have no idea at this point. I will know once I had the chance to get familiar with the code. > * if there is/will be tools/methods to easily synchronize pim data > with local/remote storages Next to data storage and retrieval, synchronizing is among the most important aspects of PIM, so yes, I expect that at some point of time opimd will cover that. > * which pim data will be handled : contact, sms, calendar, notes, > tasks ? Or only some of them ? In my opinion, the usefulness of working with PIM data is depending on the ability to cross-reference data -- as such, I'd like to have as much categories of information in the database as possible. In the order of important I'd say we should target: * Contacts * Messages (SMS) * Appointments * Tasks * Messages (E-Mail) * Notes * Message (IM) Note that depending on the amount of resources we can put into this, it might take a while. Then again, I hope that we can all co-work on that. Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] fix bug in tasklet.WaitDBusCall
applied, thanks! -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Fwd: Odaemond
I'm fine with adding this subsystem to FSO, provided you can make sure it doesn't interfere with the rest of the subsystems, i.e. please no sync. dbus calls and no "long" callbacks outside mainloops. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: RFC: FSO, filtering signals, and interapplication interfaces
First off, thanks for this proposal. Unfortunately I'm not sure whether this idea is suitable for FSO. I'm not feeling too well when thinking about the possible consequences. Assuming your primary use case is a call and SMS firewall, I don't think we want that in ogsmd. Ogsmd offers simple procedural access to the gsm low level functions and as such its signals should not be filtered or altered in any way -- otherwise you change application behaviour for any listeners, such as call loggers etc. Going one layer above, it might be more suitable for ophoned, which is the object-oriented technology-independent voice call service. Then again, I think I would rather change its API to an agent-model than filter signals. That way you would get roughly the same effect. In general though, I question whether these features might be better off living in the application layer. Remember that a full fledged telephony application will probably not use the oeventsd rules anyways. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: does a fr wake up when nobody notices it?
Am Thursday 08 January 2009 18:16:41 schrieb Alastair Johnson: > > Good idea. On the last FSO meeting we came up with the idea of an > > fso-monitor that logs exceptional conditions and provides some operation > > statistics. > > > > I think this would be a natural fit. > > That sounds good. Would this also be a good place to put monitoring for > #1024 debugging? Logging GetServingCellInformation and > GetNeighbouringCellInformation after reregistration may help to narrow > down the possible causes. Agreed. Since this is pretty important to further debug our issued, I'll come up with a skeleton for such a process over the weekend. We can then continue developing it collaboratively. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: does a fr wake up when nobody notices it?
Am Wednesday 07 January 2009 23:13:50 schrieb Asheesh Laroia: > On Wed, 7 Jan 2009, Michael 'Mickey' Lauer wrote: > > I just had a bogus wakeup and immediately inspected > > > > /sys/bus/platform/neo1973-resume.0/reason > > > > which pointed me to a WLAN wakeup -- interesting and completely > > unexpected. I will take this up with the kernel people. > > > > So, whenever you encounter an unexpected wakeup, please check the sysfs > > node and report that. > > Perhaps we can have a daemon that logs the reasons for wakeups to a file, > possibly in a RAM disk to avoid the I/O overhead of having to? > Since most of these bogus wakeups happen when people aren't looking, it's > a lot to ask that people manually check the file every time the phone > wakes up when they do not notice. Good idea. On the last FSO meeting we came up with the idea of an fso-monitor that logs exceptional conditions and provides some operation statistics. I think this would be a natural fit. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Smartphone standards public working documents
Dear Sargun, > Is there a collection of working standards for FSO? Something like > Python's PEP, or Erlang's EEP maintenance, and submission system. I > understand that FSO isn't really mature yet, as it doesn't have an > infrastructure formed around it yet, but it would be a good idea to > publicize "working standards" and have a guide for proposing new > standards. Also, it would be nice if we had a way to approve/defer > standards to some later point/deny standards. What does the FSO team > think? I agree that this is the way to move forwards, once we have reached the critical mass. We should take the time and come up with an evaluation of our present set of APIs and -- seperated, but connected -- our reference implementation. Until we have a formalized enhancement process, feel free to just come up with informal RFC's (just as you did already). Cheers, :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: FSO meeting agenda
Am Mittwoch, den 17.12.2008, 19:41 +0100 schrieb Martin Lucina: > Does "the battery issue" concern the problem of not being able to boot > up a GTA02 device if the battery is too low? No, it referred to the problem with multiple power_supply class devices and the question whether we should abstract all these power supplies into one aggregated object on dbus. The problem of deep discharge during suspend should be fixed now. The kernel will emit a low-bat IRQ waking up the device. The frameworkd is checking the wakeup reason and is performing an emergency shutdown, if the reason was due to the low-bat IRQ. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] GSM LAC Cell ID of surrounding networks
Am Mittwoch, den 26.11.2008, 05:38 +0100 schrieb Sascha Wessel:
> Hi,
>
>
> On Tue, Nov 25, 2008 at 07:13:05PM +0100, Michael 'Mickey' Lauer wrote:
> > > so far using the DBus API for reading current GSM LAC and Cell ID I am
> > > connect to works.
> > >
> > > * is it possible to see LAC and Cell IDs of *all* signals I see?
> >
> > Only through proprietary commands and even then I'm not sure whether the
> > additional properties you receive contain the real LAC and CIDs.
> >
> > Reference Implementation of the necessary additional dbus APIs are pending
> > a
> > patch which no one did write yet (please see archives of
> > smartphones-standards, this issue has been discussed).
> >
> > Patches for the %EM commands welcome.
> >
> > > if not
> > > * is it possible to see the LAC and Cell IDs of all the signals I see,
> > > which belong to the network I am connected to?
> >
> > Minus proprietary commands (see above), the GSM standard only includes LACs
> > and CIDs in unsolicited +CREG messages.
>
>
> I attached a quick and dirty hack for DebugCommand("AT%EM=2,3\r\n").
Thanks. I just added org.freesmartphone.GSM.Monitor and am working on
the TI Calypso implementation for GetServingCellInformation() and
GetNeighbourCellInformation().
:M:
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: does a fr wake up when nobody notices it?
I just had a bogus wakeup and immediately inspected /sys/bus/platform/neo1973-resume.0/reason which pointed me to a WLAN wakeup -- interesting and completely unexpected. I will take this up with the kernel people. So, whenever you encounter an unexpected wakeup, please check the sysfs node and report that. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH]: (frameworkd) remove hardcoding of sysfs nodes in GetInfo (org.freesmartphone.Device.PowerSupply interface)
Am Freitag, den 21.11.2008, 00:04 +0530 schrieb Sudharshan S: > Not sure if its any helpful, but attaching a tiny patch that removes the > hardcoding of sysfs nodes in the GetInfo method of PowerSupply interface. > Instead iterate through all the files adding it and its contents to the dict > to be returned through DBus. Thanks. This is in git now. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] prevent suspend during a call and other minor patches
Hi Giray, I didn't apply your patch since I consider the way you solved your main isse (not suspending while there is an active call) being a layering violation. In the meantime I solved this by adding a CPU resource that prevents triggering the suspend signal plus a rule that requests this resource whenever you're on a call. Thanks for your input though, since this issue was blocking autosuspend for many users. Cheers, Mickey. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Translating GSM signal strength into dBm
Hi Ronan, > thanks for pointing this out. If I understand this correctly. With the > code you pointed me, I can find back the signal quality value given by > the modem (called rssi in 07.07 8.5). > > From there, is it then safe to apply: percent * 2 - 113 = dBm ? Of course, you can reverse the function I'm using to compute the percentage and then just try to linearly scale that towards a dbM as per 07.07 -- I seriously doubt that this leads to more precision though (see below). > May I ask why you translated the value returned by the modem to a > percentage? Would it not be more straightforward to directly return the > value following the GSM standard? I don't think so. First, the value can't be computed properly anyways, since the scaling is completely undefined (might be linear, logarithmic, discrete, or whatever). Second, to most non-EEs, a value in percent should be much more meaningful than a dBm value. > If FSO runs on another modem, will this code still be valid? Yes. > Basically, reading your code, I see that if the modem returns something > greater than 31, I will get 0 from FSO API. But out of curiosity, does a > modem never return a value between 31 and 99? Never [at least if the modem does not violate the GSM standard]. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: what subsystems of frameworkd can be disabled if only GSM is needed?
Am Wednesday 17 December 2008 18:34:12 schrieb Timo Juhani Lindfors: > "Michael 'Mickey' Lauer" writes: > > If the resource system is not seeing ousaged running, it will > > automatically turn on the resource (which may be what you want for your > > case). > > Does it play a ringtone? (I can surely implement it on the other side > of the dbus interface too if needed). No. For the ringtone you need oeventsd (for processing the rules directory) and odeviced (for the audio device). -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: what subsystems of frameworkd can be disabled if only GSM is needed?
Am Wednesday 17 December 2008 10:05:53 schrieb Timo Juhani Lindfors: > I'd like to use fso-frameworkd for only talking to GSM to reduce the > number of moving parts inside fso-frameworkd for reliability. You can disable everything but ogsmd. I usually do my ogsmd developing by launching framework as: ./frameworkd -s ogsmd. If the resource system is not seeing ousaged running, it will automatically turn on the resource (which may be what you want for your case). -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
FSO meeting agenda
http://www.freesmartphone.org/index.php/Meeting_2008-12-18_Braunschweig Please contribute, if you have something you think we _need_ to discuss. We'll update the minutes of the meeting on this wiki page as well. Cheers, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] ogpsd: Support for E-Ten gnufiish devices
Hi Stefan,
> The baudrate change in gpschannel.py is a bit hacky. I need the baudrate
> set to 57600, and with this change everything works fine. On the other hand
> I don't know if it breaks other stuff. Some feedback on this would be good.
The baudrate should either set by the actual device incorporating that channel
or by adding a 'speed' parameter to the configuration.
> diff --git a/framework/subsystems/ogpsd/eten.py
> b/framework/subsystems/ogpsd/eten.py new file mode 100644
> index 000..67a4c98
> --- /dev/null
> +++ b/framework/subsystems/ogpsd/eten.py
> @@ -0,0 +1,51 @@
> +#!/usr/bin/env python
> +# -*- coding: UTF-8 -*-
> +"""
> +Open GPS Daemon
> +
> +(C) 2008 Jan 'Shoragan' Lübbe
> +(C) 2008 Daniel Willmann
> +(C) 2008 Stefan Schmidt
> +(C) 2008 Openmoko, Inc.
> +GPLv2 or later
> +"""
> +
> +DEVICE_POWER_PATH = "/sys/devices/platform/neo1973-pm-gps.0/pwron"
Better add the proper path right from the start.
> +
> +from nmea import NMEADevice
> +
> +import helpers
> +import os
> +import sys
> +import time
> +from datetime import datetime
> +from datetime import timedelta
Please check whether these modules are actually used.
> +import logging
> +logger = logging.getLogger('ogpsd')
> +
> +class EtenDevice( NMEADevice ):
> +"""E-Ten specific GPS device"""
> +
> +def __init__( self, bus, channel ):
> +
> +# Make sure the GPS is off
> +helpers.writeToFile( DEVICE_POWER_PATH, "0" )
> +
> +super( EtenDevice, self ).__init__( bus, channel )
I think super() is very dangerous, but that's taste.
> +
> +def initializeDevice( self ):
> +helpers.writeToFile( DEVICE_POWER_PATH, "1" )
> +
> +# Wait for the device to be powered up
> +time.sleep(0.5)
Eeks, do we really need that?
> +
> +super( EtenDevice, self ).initializeDevice()
> +
> +def shutdownDevice( self ):
> +
> +super( EtenDevice, self ).shutdownDevice()
> +
> +helpers.writeToFile( DEVICE_POWER_PATH, "0" )
> +
> +#vim: expandtab
> diff --git a/framework/subsystems/ogpsd/factory.py
> b/framework/subsystems/ogpsd/factory.py index 0bf75dc..73bc834 100644
> --- a/framework/subsystems/ogpsd/factory.py
> +++ b/framework/subsystems/ogpsd/factory.py
> @@ -17,6 +17,7 @@ from gpsdevice import DummyDevice
> from nmea import NMEADevice
> from ubx import UBXDevice
> from om import GTA02Device
> +from eten import EtenDevice
> from gpschannel import *
>
> NEEDS_BUSNAMES = [ "org.freedesktop.Gypsy" ]
> diff --git a/framework/subsystems/ogpsd/gpschannel.py
> b/framework/subsystems/ogpsd/gpschannel.py index 1bfd245..7ddf5e9 100644
> --- a/framework/subsystems/ogpsd/gpschannel.py
> +++ b/framework/subsystems/ogpsd/gpschannel.py
> @@ -111,7 +111,7 @@ class FileChannel ( GPSChannel ):
> class SerialChannel( GPSChannel ):
> """Serial reader"""
>
> -def __init__( self, path, baud = 9600, rtscts = False):
> +def __init__( self, path, baud = 57600, rtscts = False):
See above. 9600 is a reasonable default, lets check for presence of a 'speed'
attribute in [ogpsd] and overwrite on demand.
--
:M:
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [Shr-devel] shr-testing no longer visible
Apart from networking, PIM seems to be the most-wanted-thing in FSO atm. I have a "strategic" meeting next tuesday with Sören Apel, the opimd gsoc student, and will write a report of things afterwards. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Translating GSM signal strength into dBm
Hi Ronan, > the API (such as org.freesmartphone.GSM.Network.GetSignalStrength) > returns the signal strength in percent (0-100). Correct. Since this output is meant to correspond to dbM (however not really exactly specified as you have read in 07.07 8.5), I took the liberty to convert these values to percent. I'm using a logarithmic scale for the valid values between 0 and 31., so if you want the real dBm, you need to take this into account. The respective code is in module ogsmd.gsm.const: #=# def signalQualityToPercentage( signal ): #=# """ Returns a percentage depending on a signal quality strength. """ assert type( signal ) == types.IntType if signal == 0 or signal > 31: return 0 else: return int( round( math.log( signal ) / math.log( 31 ) * 100 ) ) Hope that helps, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: fsod status (frameworkd vala implementation) and a few clarifications
I guess it is my turn to answer here. Executive summary: The Vala/C implementation is of crucial importance to me and I will push it in 2009. As much as I stand behind Python as a language, I have always refered to the Python implementation as the first and reference implementation -- but not the only or last one -- of the FSO API. The gory details: Looking back for the last 12 months, I'm incredibly glad the I was stubborn enough not to start with a compiled language implementation in the first place -- no matter the critics I got (and still get) for this choice. freesmartphone.org has a tough job here in defining a dbus API that people love to use in domains were we have little reference work to base upon. This makes it a major learning experience for all of us and our APIs are prone to change majorly before they settles down (which is happened now for the first bunch of subsystems). If the reference implementation would not support an efficient catching up with lots of changes during the API development, then it would not be suitable. And given my lack of experience when I started several of the subsystems, I can assure you promise we would not be here if it wasn't Python :D That said, if freesmartphone.org will be successful in complementing freedesktop.org as an interoperation body for Linux on mobile devices, then a single implementation in Python will -- unfortunately -- be a major hindrance for wide adoption. I have no illusions about that. Still, the timing and the order of steps is important here. I feel confident enough with -- say -- the state of odeviced, ogsmd, ogpsd, and ousaged so that we can start looking at the Vala implementation of said subsystems soon. However, I'm not at all satisfied with oeventsd, opreferences, and opimd -- let alone the completely missing integration of networking, bluetooth, etc. So: Fear not, the only reason that I didn't spend time with it until now is that I want to get the reference implementation of the FSO APIs plus a full test coverage working well. Only then we can really start focusing on the Vala implementation. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: GSM.Call.Transfer() question...
Dear Thomas, thanks for once again spotting an inconsistency in our API! +CTFR is actually limited to incoming calls only. Since there's still D and +CHLD though, I'm pondering whether we should a) restrict 'Transfer' to operating on incoming calls only, suggesting to use Initiate() and Join() for clients who want to transfer incoming calls, or b) enhance 'Transfer' to operate on active calls (thus implementing what Initiate and Join does beyond the scenes). I'm slightly in favour of a) since I don't like to offer two ways for the same. Then again, org.freesmartphone.GSM.* is about _abstracting_ AT, so we might as well do it. What do you guys think? :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: frameworkd singleline modem with cinterion mc75i gsm
Hi Charlie, pushed to 'master', thanks! Hope everything is fine for you, cheers, Mickey. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] GSM LAC Cell ID of surrounding networks
cc'ed to smartphones-standards. > so far using the DBus API for reading current GSM LAC and Cell ID I am > connect to works. > > * is it possible to see LAC and Cell IDs of *all* signals I see? Only through proprietary commands and even then I'm not sure whether the additional properties you receive contain the real LAC and CIDs. Reference Implementation of the necessary additional dbus APIs are pending a patch which no one did write yet (please see archives of smartphones-standards, this issue has been discussed). Patches for the %EM commands welcome. > if not > * is it possible to see the LAC and Cell IDs of all the signals I see, > which belong to the network I am connected to? Minus proprietary commands (see above), the GSM standard only includes LACs and CIDs in unsolicited +CREG messages. :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] DBus, MCC and MNC
cc'ed smartphones-standards.
Am Tuesday 25 November 2008 17:58:16 schrieb Ronan Daniellou:
> I am working on a logger using GSM and GPS. I need the MCC[1] and
> MNC[2]. AFAIK the only place where to get these data is in the result of
> (description taken from the freesmartphone.org page):
> org.freesmartphone.GSM.Network
> ListProviders ( ) -> a(isss)
> An array of four-tuples with the following structure:
> * Unique numerical operator code,
> * Status ("unknown", "available", "current", "forbidden"),
> [snip]
>
> The numerical operator code is in fact the concatenation of the two MCC
> and MNC.
>
> When I get a signal about GSM registration changing, I see if I am
> 'home' or roaming. So once I know the values for 'home', I don't need to
> check again MCC and MNC. But when I am roaming, these values could any
> time change. My problem is that using ListProviders needs at least 20
> seconds (it returns 3 networks in my case). Which is too long for me in
> my logger loop.
>
> Thus I was wondering if there is another place where is located the
> current MCC and MNC?
I see your point and I have fixed it for you (luckily I could do that without
changing the API, otherwise I would have hesitated) with
http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=f0feecb9ee0a4d64d9828016531f6a4e36cb85e0
I have adjusted the API docs with
http://git.freesmartphone.org/?p=specs.git;a=commitdiff;h=501c6a3a53b0220e782c704f0148812f800f83f9
You will now get an additional property called 'code' in GetStatus() (likewise
the Status() signal) which contains the concatenated MCC and MNC.
Hope that helps!
--
:M:
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] ogpsd speed unit
Please cc' smartphones-standards for such questions. Am Tuesday 25 November 2008 17:55:42 schrieb Ronan Daniellou: > Hi all, > > the documentation I found on freesmartphone.org and > gypsy.freedesktop.org does not explicitly give the unit of the speed. > Thus I was wondering what is the unit of speed returned by: > org.freesmartphone.ogpsd, /org/freedesktop/Gypsy, GetCourse() > > Is it in knot, km/h? Daniel? -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] add QCT msm7* modem support
Didn't see that this mail didn't arrive yet: Am Saturday 22 November 2008 18:53:16 schrieb Lukas Gorris: > Hello, > > Of course the thing with the list was pebcam. I registered with > gmail.com domain but sent with googlemail.com. > > ## Original mail which did not go to the list yet is following > > Hi, > > Everyone feel free to add infos here. I will do as > > > well over the next days: > > http://www.freesmartphone.org/index.php/HW_Platforms > > I will update the msm section there. > > >> msm7200 devices (for gsm networks): (htc-msm branch) > >> kaiser (aka HTC TyTn II; buildable machine type in OE), polaris (aka > >> HTC Touch Cruise; also in OE), nike, neon, sedna, wings, ... > > > > Are there plans to have machine support for more devices in OE? > > I will sit down and add some more. atm there are only kaiser and > polaris with msm7200 chipset. I'll try adding everything we have a > machine type and working git for. The older htc machines could use > some updating I think. > > >> msm7500 devices (for cdma networks): (htc-vogue branch) > >> vogue (aka HTC Touch), titan (Sprint Mogul), ... > > > > So far we don't have any devices with cdma on our agenda. This is not > > very likely driven by us as we live in GSM countries. Not sure what > > mickeys opinion is on this, but if anybody would came up with clean > > support for CDMA in FSO we could discuss this. > > I see no problem about no OM devs living in CDMA countries. I will > talk to people who have the devices and live in cdma areas. Interesting. I don't know anything serious about CDMA. Do they use an AT protocol between TA and ME at all? > 12:46:51 Tx: AT+CLCC\r > //List current calls > > 12:46:51 Rx: 0\r > > 12:46:54 Tx: AT+COPS=2\r > //Operator selection; 2: sign off network > > 12:46:54 Rx: +CREG: 2\r\n > //Network registration; 2: enable > network registration and location information > > 12:46:54 Rx: +CGREG: 2\r\n > //Network registration; 2: enable > network registration and location information > > 12:46:55 Rx: 0\r > > 12:46:55 Tx: AT+CGAATT=2,1,1\r //GPRS > Attach/Detach Mode > > 12:46:55 Rx: 0\r > > 12:46:55 Tx: AT+COPS=0\r > //Operator selection; 0: automatic (oper > ignored) > > 12:47:4 Rx: +CREG: 1,"",""\r\n > //Network registration; 1: > enable network registration > > 12:47:4 Rx: 0\r > > 12:47:4 Tx: AT+COPS=0\r > //Operator selection; 0: automatic (oper > ignored) > > 12:47:4 Rx: 0\r > > 12:47:4 Rx: @HTCCSQ: 2\r\n //prop. > HTC Signal Quality > > 12:47:4 Tx: AT+COPS=0\r > //Operator selection; 0: automatic (oper > ignored) > > 12:47:4 Rx: 0\r > > 12:47:4 Tx: AT+COPS=0\r > //Operator selection; 0: automatic (oper > ignored) > > 12:47:4 Rx: 0\r > > 12:47:4 Tx: AT+COPS=0\r > //Operator selection; 0: automatic (oper > ignored) > > 12:47:4 Rx: 0\r > > 12:47:4 Tx: AT+CSQ\r > //Signal quality > > 12:47:4 Rx: +CSQ: 12,99\r\n0\r > //Signal quality > > 12:47:4 Tx: AT+COPS=3,2;+COPS?\r > //Operator selection; 3: set > format only, 2: sign off network > > 12:47:4 Rx: @HTCCSQ: 2\r\n > //Signal quality > > 12:47:4 Rx: +COPS: 0,2,"x",0\r\n0\r > //Operator selection; 0: > automatic (oper ignored), 2: sign off network > > 12:47:4 Tx: AT+CIMI\r > //International Mobile Subscriber Identifier > > 12:47:4 Rx: xxx\r\n0\r > //International Mobile > Subscriber Identifier > > 12:47:6 Rx: @HTCCSQ: 4\r\n //prop. > HTC Signal Quality > > 12:47:12 Rx: +CGREG: 1\r\n > //Network registration; 1: enable > network registration > > 12:47:17 Tx: [EMAIL PROTECTED],47,17,2008,11,22\r > > 12:47:17 Rx: 0\r Not surprising [which is good]. If we have all of the proprietary commands documented, we'll be up to speed wrt. ogsmd quickly. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] add QCT msm7* modem support
Yo, > >> > Let me add on that -- it is always desirable to have more than just > >> > one channel for usual AT commands, that way you can drastically > >> > simplify the gsm server logic. I would prefer three independent > >> > homogenous command channels, if we can have them, one for call > >> > control, one for unsolicited responses, and one for everything else. > >> > >> Why does it simplify gsm server logic? > > Is the gsm server logic fso here? For example. > > Example: > > If you have one channel where you always retrieve unsolicited responses, > > you can > > a) disable unsolicited responses on the other channels and use them > > solely in request/response mode, and > > b) retrieve unsolicited responses while the other channels are busy (e.g. > > during dialing the ATD command hangs and blocks any other commands or > > unsolicited messages coming in) > > My knowledge of the AT communications is poor, so I guess I can't > judge whether or not it will be worth creating all this extra > abstraction for the msm7*. Still I would like to understand it. What > is the benefit in the a) case? You would not have to check whether you have an outstanding request pending -- which you always have to do otherwise you can't differenciate an unsolicited response from a solicited response. > In the b) case, how would ATD hang? ATD hangs while you are dialling. If you have multiple channels, you can still receive signal strength updates, incoming sms, incoming ussd, or whatever updates from the network while you are calling. Likewise, when you are doing long-lasting commands (scanning for networks e.g.), if you only have one channel, you can not do two things simultaneously -- i.e. no dialling during SIM access, no SIM access during network scan, etc. > In > case it would, how would the unsolicited-only channel win over the > normal serial device method? The multiplexing mode handles this transparently for you. In MUX mode you have (sorry for repeating, but it's the correct description) multiple independent channels where you can talk AT. > If this will require any modification of the arm9 (modem) code like > modifying the AT communication behaviour, we can't do the multiplex > stuff. In msm7* we have nothing like ti tools luxury you have for the > calypso. > > Where can the sources to this soft-multiplexing mechanism used for the > calypso modem be found? The modem-part is in the TI Calypso firmware, closed, hidden, proprietary, you name it. The userland part is in git.freesmartphone.org -> gsm0710muxd. > Could you be more specific and name things so > in future I can have a look at the sources right away? Abstract terms are important to describe concepts, whereas concrete names describe implementations. Therefore it's important to know what to use when. > > On the Freescale Neptune, we have hard-multiplexing (done in > > hardware+kernel) giving us 8 channels, however they're not independent > > nor homogenous. Still they have something like a dedicated channel for > > several types of commands (i.e. unsolicited), so that's nice as well. > > > > Don't get me wrong, we can use a singleline modem fine as well, but you > > will have to live with certain limitations. > > What are these limitations? As explained above. Less concurrency, some commands block other commands. > You mean if we use the single present msm > AT channel (/dev/smd0) only, we can't recycle as much of the calypso > modem code in fso for use with msm7* as we could with the > soft-multiplexing? Or are these limitations on a higher level of > abstraction than fso? They are influencing each other. If you can't get a +CRING while you're performing a +COPS? the UI will not be able to indicate that someone is calling you while you are scanning for networks. > Assuming I'm brave and I would want to run fso on my kaiser's > /dev/smd0, which (single line) modem type would I want to pick? > Calypso? As I have tried to explain, we don't use the Calypso in single line. I have provided a single-line modem type for reference (called 'singleline' (sic!)) , but I have never actually tested it. It might make a good starting point, if you really have no way to have multiple channels going. > Could you comment on the AT debug logs I sent? I thought I did with http://lists.openmoko.org/pipermail/devel/2008-November/003349.html -- or are you referring to other logs? -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] add QCT msm7* modem support
Hi, > > Let me add on that -- it is always desirable to have more than just one > > channel for usual AT commands, that way you can drastically simplify the > > gsm server logic. I would prefer three independent homogenous command > > channels, if we can have them, one for call control, one for unsolicited > > responses, and one for everything else. > > Why does it simplify gsm server logic? Example: If you have one channel where you always retrieve unsolicited responses, you can a) disable unsolicited responses on the other channels and use them solely in request/response mode, and b) retrieve unsolicited responses while the other channels are busy (e.g. during dialing the ATD command hangs and blocks any other commands or unsolicited messages coming in) > What do you mean by independent and homogenous? Independent: They keep their own state, e.g. if you enable +CREG on channel A, it would not get sent on channel B. Homogenous: Channels are equal, e.g. you the same set of commands work equally on channel A and B. > If you want to change the way you access the modem in the msm7*, you > must modify the AMSS. It is the software which provides us with the > shared memory fifos where the serial nodes run on. The kernel driver > is only a thing that manages the data flow on them and provides the > devices. So that would be very hard. If I got this wrong and you want > to make userspace software that "sorts" different commands it's > something else. But I don't understand the reason. Does it work like > that on the mokos? On the TI Calypso, we have soft-multiplexing (done in userland) giving us 4 independent, homogenous channels. This is a quite nice base for any gsm server. On the Freescale Neptune, we have hard-multiplexing (done in hardware+kernel) giving us 8 channels, however they're not independent nor homogenous. Still they have something like a dedicated channel for several types of commands (i.e. unsolicited), so that's nice as well. Don't get me wrong, we can use a singleline modem fine as well, but you will have to live with certain limitations. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] add QCT msm7* modem support
Heya,
Am Saturday 22 November 2008 17:01:40 schrieb Stefan Schmidt:
> > > Modem is, as always, a bit more difficult. Does the modem support
> > > standard TS 07.10 muxer support on these devices?
> >
> > Afaik we don't have any muxing here because all the data goes through
> > different serial channels. That was also the first thing mickey asked
> > about the msm7* modems. I don't know exactly how the 3g stuff works,
> > because in angstrom I only use gprs on the kaiser. Never tried the
> > other data connections. But it must be very similar.
>
> So it is:
> /dev/smd0 for AT commands. (Any restriction, or all all comand allowed?)
> /dev/smd1 for GPRS
> /dev/smd7 for GPS
>
> What it about about /dev/smd{2,3,4,5,6} ? does they exist? If yes it could
> good be that we really need to userspace muxer for this as it is all
> handled inside the kernel. We have a similar setup for EZX. The kernel
> driver already does the multiplexing, a heavily modified variant of TS07.10
> from Moto, and just exports the char devices to userspace.
Let me add on that -- it is always desirable to have more than just one
channel for usual AT commands, that way you can drastically simplify the gsm
server logic. I would prefer three independent homogenous command channels,
if we can have them, one for call control, one for unsolicited responses, and
one for everything else.
> > ATZE0S0=0Q0V0X3&C1&D1|+GTKC=2
> > +CMEE=1
> > +CRC=1
> > +CR=1
> > +CREG=1
> > +FCLASS=0
> > +CMGF=0
> > +CSCS="HEX"
> > +CSSN=0,1
> > +CLIP=1
> > +COLP=0
> > +CCWA=1
> > +CMUT=0
> > +CLIR=0
> > +CNMI=1,2,2,2,0
> > +CGREG=1
> > +CUSD=1
Pretty standard.
> > +CPPP=1|@v
That one is special, choses PAP vs. CHAP?
> > +RADIOVER|@HTCCSQ=1
> > +ENCSQ=1|@HTCDIS=1
> > @HTCSAP=1|
No idea about these.
> The three above are for sure HTC specific. Mickey, can you comment on the
> others?
>
> > # Send the modem init and access point name
> > /bin/echo -e "AT+CGDCONT=1,\"IP\",\"$1\",\"\",0,0\r" > /dev/smd0
>
> Mickey, normal?
Completely standard.
> > As you can see we send the AT commands to smd0 and pppd is ran on smd1
> > where the gprs data flows.
Good. Again, if we can have three independent channels I'd be glad. If not, we
have to take what we can get :)
--
:M:
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [FSO] add QCT msm7* modem support
Hi Andy, > Just curious about this "machine name" concept, what does it actually > address? This is what you give to OE as the MACHINE settings, it defines things like * jffs2 params for the rootfs * flash size * serial tty setting * preferred X server * machine capabilities in general (phone, screen, keyboard, usbhost, ...) This MACHINE setting is also used as OVERRIDE for config file in packages such as: [EMAIL PROTECTED]:/local/pkg/oe/openembedded$ find . -name om-gta01 ./packages/scummvm/files/om-gta01 ./packages/uclibc/uclibc-0.9.29/om-gta01 ./packages/uclibc/uclibc-0.9.30/om-gta01 ./packages/netbase/netbase/om-gta01 ./packages/u-boot/u-boot-1.2.0/om-gta01 ./packages/base-files/base-files/om-gta01 ./packages/tslib/tslib/om-gta01 ./packages/gpephone/gpe-applauncher/om-gta01 ./packages/gpsd/files/om-gta01 ./packages/pointercal/files/om-gta01 ./packages/freesmartphone/frameworkd/om-gta01 ./packages/openmoko2/openmoko-dialer2/om-gta01 ./packages/initscripts/initscripts-1.0/om-gta01 ./packages/fbset/fbset-modes/om-gta01 > It has become clear lately that we need single rootfs image > that deals with several types of device, is that what it actually does? While a single rootfs image is very appealing, our experience says it only works well on device families where the siblings are _very_ related. (It may work for gta01 and gta02, but we're also talking about machines like the Motorola EZX series here or the Zaurus family which have dozens of somewhat similar, but still too different variants) Of course you can try to achieve most of this with runtime configuration and shipping stuff for all variants, but you will run into limitations, especially regarding flash size. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [PATCH] prevent suspend during a call and other minor patches
Dear Giray, first of all, thanks a lot for your patch, which I'm going to review as soon as possible. I'd be grateful if you could send patchsets though instead of one big lump -- quilt is a great tool for that. Cheers, Mickey. ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Audio file playing options for frameworkd
Hi Tobias, I have just sent this patch to 'master'. I have a slight feeling of unease with encoding audio engine specific options into the "filename", but until I have a better idea, this patch improves the state of things, so thanks! :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: periodic unregistering even with AT%SLEEP=2
Am Sunday 16 November 2008 19:45:36 schrieb Timo Juhani Lindfors: > Timo Juhani Lindfors <[EMAIL PROTECTED]> writes: > > I patched fso-frameworkd 0.2.0-git20080909-7 debian package to send > > AT%SLEEP=2 on init. However, I still see periodic unregistering: > > Ignore my previous report. I seem to have accidentally sent > "ATAT%SLEEP=2" :-) *phew* :) By the way, you can achieve the same without patching: [ogsmd] ti_calypso_deep_sleep = never -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: is really SetWakeupTime really implemented on some freerunner?
Am Saturday 15 November 2008 20:30:03 schrieb Timo Juhani Lindfors: > while reading fso-frameworkd source code (to figure out what > unnecessary subsystems to disable) I noticed that kernel26.py supports > > def SetWakeupTime( self, t ): > """Set wakeup time in seconds since epoch (UTC). Set 0 to disable.""" > if os.path.exists( "%s/wakealarm" % self.node ): > writeToFile( "%s/wakealarm" % self.node, t ) > > Does this really work on freerunner? You forgot to quote the interesting part... else: # use ioctl interface try: import pyrtc except ImportError: logger.error( "pyrtc not present. Can not operate real time clock" ) if time == "0": pyrtc.rtcDisableAlarm() else: pyrtc.rtcSetAlarm( time.gmtime( t ) ) > It would be a really useful > feature. Indeed, that's why I added it. It seems to work fine here. The implementation of the sysfs-wakealarm attribute is (unfortunately) optional to RTC implementations, so we fallback to the ioctl implementation. > Stable-tracking branch of linux-2.6 has a few mentions of wakealarm > but the string "wakealarm" only seems to appear in the names of > functions and in comments, not as string constants. It's a relatively new feature in the 2.6 sysfs RTC support. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: how to reduce stat()ing done by fso-frameworkd?
I bet that's my extra-debugging in ogsmd. Does applying the following patch
fix it?
diff --git a/framework/subsystems/ogsmd/gsm/decor.py
b/framework/subsystems/ogsmd/gsm/decor.py
index 7dc5916..477f0fd 100644
--- a/framework/subsystems/ogsmd/gsm/decor.py
+++ b/framework/subsystems/ogsmd/gsm/decor.py
@@ -10,8 +10,8 @@ GPLv2 or later
import logging
logger = logging.getLogger('ogsmd')
-# FUNCTION_DEBUG = False
-FUNCTION_DEBUG = True
+FUNCTION_DEBUG = False
+# FUNCTION_DEBUG = True
colorclasses = { "MiscChannel": 38, "CallChannel":
35, "UnsolicitedResponseChannel": 31 }
:M:
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: how to turn GSM power off with frameworkd?
Am Saturday 15 November 2008 16:06:49 schrieb Joachim Breitner: > Do you (as in: all users of Debian on the FreeRunner) prefer new > versions ASAP (but with possible) breakage, or rather wait and hopefully > have less problems? Btw., I'd advise to always build the latest HEAD of stabilization/milestone4 branch for a release -- we already have fixed a bunch of minor bugs since MS4. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: how to turn GSM power off with frameworkd?
In MS4 and later, if you release the GSM resource, gsm0710muxd gets shut down, which in turn turns off the modem completely. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Avoiding the use of ctypes in frameworkd
Am Wednesday 12 November 2008 21:16:04 schrieb Joachim Breitner: > milestone4 starts to use the standard python libray “ctypes”. Due to > some unfortunate bug in the Debian python package[1], this is missing on > Debian on armel, and it’s not clear whether it’s easy to fixed. That's unfortunate, since the alternative to using ctypes is having more compiled code, which in turn slows down the development cycle. Then again, the offending parts are in odeviced which is the first one scheduled to be replaced by a Vala-plugin eventually anyways. > I noticed that the only reason, the pyglet modules (who use ctypes) are > uses is to find out whether an input device supports ABS (i.e. whether > it is a pointer device). I found out that this is readily available via > $ grep ABS /sys/class/input/input*/uevent > so for Debian I created this very small module to check for ABS: [...] That's cool, but please check the 'master' branch -- we would also need an alternative for is_key_pressed() (in the same module) which I have just added a couple of days ago to prepare for coldplug support (again, this all will be obsoleted by the Vala plugin, however I don't have a time frame for that). > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505318 ctypes was broken for us as well -- we have a patch in OE, perhaps it helps you. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: [pkg-fso-maint] milestone4 and Debian
Hi Joachim, to be honest, I didn't think of setup.py. I have always said though that there will be milestone releases until we reach 0.9, from then we will release versioned. To be able to upgrade packages, I have always increasen the frameworkd version in OE though, so you should have seen packages with increasing version number starting from 0.2 until 0.8.4.3 (which is the version number our milestone4 packages have). Hope that clarifies it. Regards, -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Audio file playing options for frameworkd
Am Monday 10 November 2008 15:05:35 schrieb Joachim Breitner: > Hi, > > Am Montag, den 10.11.2008, 00:01 +0100 schrieb Tobias Gruetzmacher: > > Here is a patch for frameworkd that allows to inject gstreamer options > > into file names for the audio playing service. I wrote it because I > > wanted to use the title music from Giana Sisters as a ring tone, which > > is tune number 5 in Great_Giana_Sisters_PSID.sid ;) > > Just curious, woudn’t it make more sense to write a script that extracts > a specific tune from a .sid file, instead of having gstreamer do that? No, subtunes are an inherent feature of SID tunes and not extractable. (Not that it would matter anyways given an average file size of 5K...) -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Some debian questions
Am Wednesday 29 October 2008 04:21:01 schrieb Guillaume Chereau: > > You can already add new rules using the dbus call : > > org.freesmartphone.Events.AddRule(s) > > > > the string should be in the same format than the rules in the rules > > file. > > > > For the way to modify rules, it is planned. Rules can have name (using > > 'name' attribute in the rules file.) > > I will take some time today to add a RemoveRule, so that you can add and > > remove rules. > > Ok I added the RemoveRule method to oeventsd, you can check oevents.py > in the framework tests directory to see how to add and remove rules. Hi Charlie, I have just added a skeleton for org.freesmartphone.Events in the specs repository, please fill it with some docs when you have a chance. -- :M: ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
