Framework telefonico

[raster]

Certo che definire Michael Lauer un persona non seria ......
per il resto se ofono "offre" un qualcosa di meglio e di più stabile usatelo pure.
io finché non lo provo non lo giudico.
sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce.  

bye

[maurelio79]

CE L'HO FATTAAAAAAAAAAAAAAAAAAAAAAAA
Il tempo di fare uno script da console e posto tutto
Ragazzi, ofono è limitato ma ha un sacco di funzioni che per la distro base sono più che sufficienti! Ho fatto una registrazione in rete e una chiamata solo da riga di comando!!!!!
WOWOWOWOOWOW!!!!!!!!!!

Non capisco tutto sto casino.
Non che io tenga particolarmente a FSO però sono cose che si possono fare anche con FSO (già da una vita)
Mi sembra che avete scoperto l'acqua calda.
Non prendetela come una provocazione 

bye

LOL! Sei incredibile... quasi uno spasso!!

[dorje]

sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce.  

"Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++. "

Il fatto è che questa frase si può interpretare anche in modi non proprio simpatici!

[djdas]

Uh stavo dimenticando di chiedertelo, ma hai solo fatto uno squillo o hai provato che l'audio fosse correttamente routato?

No fatto solo squillare perché nella mastrolindo non ci sono ancora le alsa-utils, in ogni caso credo che per quello sia sufficiente agire come al solito con gli stati alsa che ruotano l'audio, anche se io ho in mente un'altra idea che, appena sarà più chiara nella mia mente, proporrò nella dovuta sede

Certo che definire Michael Lauer un persona non seria ......
per il resto se ofono "offre" un qualcosa di meglio e di più stabile usatelo pure.
io finché non lo provo non lo giudico.
sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce. 
bye

Per me una azienda seria (non parlo del singolo) è quella che pianifica PRIMA di decidere il da farsi, non dopo che è stato rifatto due volte (chi paga tutto sto tempo di ricerca e sviluppo?), male e senza un criterio logico, se Openmoko è fallita è anche per questo, dopo 3 ANNI di lavoro è inconcepibile avere un telefono che non telefona bene mettendoci 3 minuti a partire! Dietro oFono ci sono Nokia e Intel e non credo che abbiano sicuramente tempo da perdere con l'Open Source se non avessero i loro interessi, e loro dal 19 giugno al 21 settembre hanno già una piattaforma che, anche se non perfetta, funziona decentemente, ben documentata (il doc con le API è disponibile e loro si attengono a quelle, PUNTO!) multipiattaforma (supportano 2 o 3 tipi di modem oltre al modem simulato e quello via socket da remoto!) e soprattutto scritta nell'unico linguaggio che va usato per i framework e i backend nei sistemi embedded: il C.

sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce. 

"Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++. "

Il fatto è che questa frase si può interpretare anche in modi non proprio simpatici!

Appunto, io vedendo i risultati finora ottenuti lo interpreto nel peggiore dei modi: non sappiamo cosa fare, speriamo che l'idea ci venga dall'alto, la facciamo in python perché non ci va di aspettare 20 secondi per compilare ma proviamo al volo, se funziona lo rilasciamo e vediamo quanti ci bestemmiano dietro: se sono meno di 1000 allora è OK...
Prova ne è il thread dei giorni scorsi in ML ufficiale sulle API di gestione degli accelerometri, andate a leggerlo per capire come ragionano questi folli!!!
Detto questo, quando loro avranno finito di portarlo in Vala (che praticamente è il C di chi non vuole imparare il C ), noi saremo qui a cambiare semplicemente un demone di sistema e un paio di righe di applicazione telefonica: se sarà più performante, ben venga, ma penso che nel frattempo oFono ci metterà a disposizione l'infrastruttura di gestione dei contatti basata su evolution-data-server (scusate se è poco) oltre che una fonia stabile e funzionante....io sono qui, i sistemisti pure, la distro è in crescita e c'è tanta voglia di fare vedere al mondo di OM che la gente cazzuta esiste anche se usa il proprio know-how nel tempo perso e A GRATIS
Ciau!

[xela92]

Uh stavo dimenticando di chiedertelo, ma hai solo fatto uno squillo o hai provato che l'audio fosse correttamente routato?

No fatto solo squillare perché nella mastrolindo non ci sono ancora le alsa-utils, in ogni caso credo che per quello sia sufficiente agire come al solito con gli stati alsa che ruotano l'audio, anche se io ho in mente un'altra idea che, appena sarà più chiara nella mia mente, proporrò nella dovuta sede

Certo che definire Michael Lauer un persona non seria ......
per il resto se ofono "offre" un qualcosa di meglio e di più stabile usatelo pure.
io finché non lo provo non lo giudico.
sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce. 
bye

Per me una azienda seria (non parlo del singolo) è quella che pianifica PRIMA di decidere il da farsi, non dopo che è stato rifatto due volte (chi paga tutto sto tempo di ricerca e sviluppo?), male e senza un criterio logico, se Openmoko è fallita è anche per questo, dopo 3 ANNI di lavoro è inconcepibile avere un telefono che non telefona bene mettendoci 3 minuti a partire! Dietro oFono ci sono Nokia e Intel e non credo che abbiano sicuramente tempo da perdere con l'Open Source se non avessero i loro interessi, e loro dal 19 giugno al 21 settembre hanno già una piattaforma che, anche se non perfetta, funziona decentemente, ben documentata (il doc con le API è disponibile e loro si attengono a quelle, PUNTO!) multipiattaforma (supportano 2 o 3 tipi di modem oltre al modem simulato e quello via socket da remoto!) e soprattutto scritta nell'unico linguaggio che va usato per i framework e i backend nei sistemi embedded: il C.

sul perché FSO sia in python Mickey la spiegato più volte, poi se uno vuole capire capisce. 

"Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++. "

Il fatto è che questa frase si può interpretare anche in modi non proprio simpatici!

Appunto, io vedendo i risultati finora ottenuti lo interpreto nel peggiore dei modi: non sappiamo cosa fare, speriamo che l'idea ci venga dall'alto, la facciamo in python perché non ci va di aspettare 20 secondi per compilare ma proviamo al volo, se funziona lo rilasciamo e vediamo quanti ci bestemmiano dietro: se sono meno di 1000 allora è OK...
Prova ne è il thread dei giorni scorsi in ML ufficiale sulle API di gestione degli accelerometri, andate a leggerlo per capire come ragionano questi folli!!!
Detto questo, quando loro avranno finito di portarlo in Vala (che praticamente è il C di chi non vuole imparare il C ), noi saremo qui a cambiare semplicemente un demone di sistema e un paio di righe di applicazione telefonica: se sarà più performante, ben venga, ma penso che nel frattempo oFono ci metterà a disposizione l'infrastruttura di gestione dei contatti basata su evolution-data-server (scusate se è poco) oltre che una fonia stabile e funzionante....io sono qui, i sistemisti pure, la distro è in crescita e c'è tanta voglia di fare vedere al mondo di OM che la gente cazzuta esiste anche se usa il proprio know-how nel tempo perso e A GRATIS
Ciau!

Perfetto.
ma

evolution-data-server

WHAAAAT??? :O

[dorje]

"Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++. "

Il fatto è che questa frase si può interpretare anche in modi non proprio simpatici!

Appunto, io vedendo i risultati finora ottenuti lo interpreto nel peggiore dei modi: non sappiamo cosa fare, speriamo che l'idea ci venga dall'alto, la facciamo in python perché non ci va di aspettare 20 secondi per compilare ma proviamo al volo, se funziona lo rilasciamo e vediamo quanti ci bestemmiano dietro: se sono meno di 1000 allora è OK...

Vedo che sei stato addirittura gentile...

[LeOS]

Approfitto per risponderti qui così condividiamo con tutti: probabilmente ho assunto io una cosa sbagliata, dunque, se guardi lo script vedrai che chiamo il path /modem0 per accedere al modem, in realtà bisognerebbe chiedere preventivamente al Manager quali modem ha connessi, usando il metodo GetProperties così:

Code:

dbus-send --system --print-reply --type=method_call --dest=org.ofono / org.ofono.Manager.GetProperties

e sostituire nello script /modem0 con la strina ritornata (magari lo aggiungerei nello script per renderlo più custom )

uhm sara' ma non riesco ancora a farlo andare:

root@XMBmastrolindo:~# dbus-send --system --print-reply --type=method_call --dest=org.ofono / org.ofono.Manager.GetProperties
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files


che mi manca?!

[djdas]

ARGHHHHHHH Forse ho capito!!!

Vai in /etc/ofono/modem.conf e verifica che la parte relativa al modem calypso sia decommentata:

Code:

# Sample for Openmoko Freerunner
[freerunner]
Driver=calypso
Device=/dev/ttySAC0

La riga di sopra ti dovrebbe dare:

Code:

root@smoccolo:~# dbus-send --system --print-reply --type=method_call --dest=org.ofono / org.ofono.Manager.GetProperties
method return sender=:1.0 -> dest=:1.3 reply_serial=2
   array [
      dict entry(
         string "Modems"
         variant             array [
               object path "/calypso0"
            ]
      )
   ]

Scusami sono un idiota, ho postato il pacchetto di ofono compilato non i file del TARino, sorry!
Ciau!

[djdas]

Scusate, ho fatto una prova di ricezione di chiamata e vi posto l'output della console Figata (è cambiato anche il signal strength nel frattempo )

Code:

root@smoccolo:~# dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.14 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.14"
signal sender=:1.0 -> dest=(null destination) path=/calypso0; interface=org.ofono.VoiceCallManager; member=PropertyChanged
   string "Calls"
   variant       array [
         object path "/calypso0/voicecall01"
      ]
signal sender=:1.0 -> dest=(null destination) path=/calypso0; interface=org.ofono.NetworkRegistration; member=PropertyChanged
   string "Strength"
   variant       uint16 93
signal sender=:1.0 -> dest=(null destination) path=/calypso0/voicecall01; interface=org.ofono.VoiceCall; member=PropertyChanged
   string "State"
   variant       string "disconnected"
signal sender=:1.0 -> dest=(null destination) path=/calypso0; interface=org.ofono.VoiceCallManager; member=PropertyChanged
   string "Calls"
   variant       array [
      ]

In pratica la chiamata è indicata dal path /calypso0/voicecall01 e poi con il CallManager si gestisce la risposta, l'hangup etc etc....direi che è perfetto
Ciau!

[LeOS]

abbi pazienza ma non ci sono ancora
a parte il file che era tutto commentato, ottengo sempre lo stesso errore!

il monitor funziona:

Code:

root@XMBmastrolindo:~# dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.3"

(anche se ho dovuto killare a mano il processo)

na l'altro da sempre:

Code:

root@XMBmastrolindo:~# dbus-send --system --print-reply --type=method_call --dest=org.ofono / org.ofono.Manager.GetProperties
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files

[djdas]

Si il monitor va killato di brutto... uhm, dopo avere modificato il file immagino che hai riavviato ofonod
In ogni caso puoi lanciarlo manualmente da console con

Code:

ofonod -n -d

così entri in debug e vedi a syserr cosa fa, prova così e poi a dargli a mano i comandi che trovi nello script.
Ciau!

[LeOS]

non capisco
avevo addirittura riavviato il tel, adesso sono entrato in debug e mi da correttamente l'output!
comincio a pensare che non venga avviato correttamente ofonod! adesso indago e aggiusto

[LeOS]

ok funziona
secondo me c'e' un problema sul dbus, che se ci mette un attimo di piu' a partire ofono fallisce brutalmente
ora tolgo  il & dal dbus.sh in rc e vedo che funziona:

Code:

root@XMBmastrolindo:~# cat /etc/rc
#!/bin/sh
sh /etc/scripts/x.sh &
sh /etc/scripts/pseudofs.sh
sh /etc/scripts/ramdisk.sh >/dev/null 2>&1
sh /etc/scripts/dbus.sh start
sh /etc/scripts/modeminit.sh &
sh /etc/scripts/net.sh
sh /etc/scripts/dropbear.sh &

[djdas]

Ma infatti io non l'avevo messo con & apposta Hai visto lo script che avevo postato ieri sera? Tra l'altro visto che il modem ci sta più tempo di X a registrarsi IMHO dovrebbe partire prima.
Comunque l'importante è che sia risolto
Ciau!

[LeOS]

io farei partire x per primissmo, questo perche' l'utente puo' vedere a schermo le operazioni di partenza modem e registrazione della rete!