inky has quit [Quit: Leaving.]
belcher has quit [Read error: Connection reset by peer]
inky_ has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 240 seconds]
belcher has joined #maemo-leste
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 245 seconds]
inky_ has joined #maemo-leste
lyubov has quit [Ping timeout: 240 seconds]
lyubov has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
sunshavi has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
uvos has joined #maemo-leste
Pali has joined #maemo-leste
pere has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
Blikje has quit [Ping timeout: 256 seconds]
Blikje has joined #maemo-leste
<lel> IMbackK opened a pull request: https://github.com/maemo-leste-upstream-forks/ofono-d4/pull/1 (Add handler for state change to "active" mode when call gets picked up.)
<Wizzup> uvos: want to ask tmlind to review?
<uvos> sure tmlind ^^
<uvos> Wizzup: parazyd: please fix the branches on that repo
<uvos> its a bit of a mess
<uvos> also do we use this ofono for all devices or mapphones only?
<Wizzup> mapphones
<uvos> we should stop doing that
<uvos> the mapphone patches just add a driver
<Wizzup> maybe
<uvos> anyhow please make the branches sane ie delete everything except the maemo/ ones and add a master branch, keep the d4 branch maybe thats the non qmi backend iiuc
<Wizzup> there are branches with old work which I think are of value
<Wizzup> which ones bother you in particular?
<Wizzup> also it's entirely common to have many branches in a git repo afaik
<uvos> it mainly bothers me that there is no obvious main branch
<uvos> made worse by the fact that there are many not-so-greatly named branches
<uvos> like fixes or m-v1.29-1
<uvos> is not helpfull and should be cleaned up
<uvos> that could mean renaming those
<uvos> but yeah
<Wizzup> agreed
inky has joined #maemo-leste
zhxt has joined #maemo-leste
dreamer has quit [Ping timeout: 248 seconds]
inky_ has quit [Ping timeout: 240 seconds]
dreamer has joined #maemo-leste
branon has quit [Ping timeout: 248 seconds]
pere has quit [Ping timeout: 252 seconds]
<tmlind> fyi, updated wlroots hacks pushed to https://github.com/tmlind/wlroots/commits/pvr-gles2-v2
<tmlind> still needs more work, the issue with suing render node vs primary node is still unresolved
<tmlind> weston-simple-egl works now and stellarium, but somehow glmark2-es2-wayland is not working compared to 0.14.1
ikmaak has quit [Read error: Connection reset by peer]
ikmaak has joined #maemo-leste
<Wizzup> Anyone here with fremantle ipv6 installed? Wondering what the gconf module string looks like for ipv6
<lel> MerlijnWajer deleted a repository: https://github.com/maemo-leste/libicd-network-tor
<Wizzup> (merging with provider repo)
inky_ has joined #maemo-leste
sunshavi has quit [Ping timeout: 252 seconds]
inky_ has quit [Ping timeout: 245 seconds]
inky has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
inky has joined #maemo-leste
pere has joined #maemo-leste
zhxt has quit [Ping timeout: 256 seconds]
sunshavi has joined #maemo-leste
<uvos> Wizzup: so how do i convert a gtk_scrolled_window_new to a hildon_pannable_area_new
<uvos> is there some documentation on this somewhere
<uvos> is a hildon_pannable_area a subclass of a gtk_scrolled_window or something?
<uvos> ie where is the documentation on the hildon specific widgets
<Wizzup> uvos: trying to search for the doc I remembered, but idk atm
<Wizzup> maybe grep on our github repos
<uvos> its a subclass of GtkContainer
<uvos> at least
<uvos> so got it work
<uvos> new version of sphone has audio routing via pa
<Wizzup> cool, how does it work?
<uvos> it just setts the ucm profile, ie this is the "fallback" code i intend to keep/use outside of leste later
<uvos> note this only works with the ofono pr
<uvos> as otherwise sphone never gets the signal that a call is active
<uvos> so it never switches profiles
<Wizzup> ok
<Wizzup> I can merge it now, but wanted to get tmlind's comment
<uvos> no sure if he missed it before
<uvos> tmlind: ^^^^ can you review the ofono pr?
<uvos> a rats i forgot to merge the changes into beowulf-devel :P
<uvos> ok correct version building for devel now
mardy has quit [Quit: WeeChat 2.8]
<lel> MerlijnWajer closed a pull request: https://github.com/maemo-leste-upstream-forks/ofono-d4/pull/1 (Add handler for state change to "active" mode when call gets picked up.)
<tmlind> Wizzup, uvos: looks ok to me, does the ofono_voicecall_notify() need to be paired somewhere on hangup?
lyubov has quit [Ping timeout: 252 seconds]
lyubov has joined #maemo-leste
<uvos> tmlind: no the ofono_voicecall_notify here works only on existing call ids ofono_voicecall_disconnected is the pair
<uvos> Wizzup: ofono-d4-source is broken
<tmlind> ok
<uvos> tmlind: if you can find the time it would be really helpfull if you could investigate how to proparly fix the disabled PGA problem during voicecall in snd-soc-cpcap
<uvos> tmlind: i really failed to figure out how to do this
<uvos> tmlind: and dont know what to look at to figure it out
<lel> IMbackK opened an issue: https://github.com/maemo-leste/bugtracker/issues/569 (adding a new profile in profilex fails)
<tmlind> uvos: yeah i guess we should eventually deal with it..
<uvos> tmlind: any idea whats up with sre?
<uvos> Wizzup: yes we should build ofono for all arches
<uvos> Wizzup: and we should unify the ofono version we build
<uvos> there is no reason whatsoever to not just add the motorolamodem driver to our "regular" ofono
<Wizzup> uvos: yes, I understand, I guess think only went into the droid component or something
<uvos> "I guess think only went into the droid component or something" cant parse
* enyc meows
<uvos> you mean we should only build armv7 for droid componant packages?
<Wizzup> uvos: yeah I think that was my expectation, but if we merge there's no point to that
<uvos> ok
<uvos> btw we should seperate the droid4 componant into mapphone and droid4
<uvos> with the d3 and mz6XX this arrangement is going to become increasingly akward
<Wizzup> yeah, probably
<Wizzup> unless we can share things :)
<uvos> so except the kernel bug on mapphones, cellular calls should just work now on leste, i think thats pretty neat, whens the next newspost :P
<Wizzup> I think realistically after the 13th
<uvos> ok
<Wizzup> I'll be home on the 21st so I can also send some more hw to folks if they want
<Wizzup> uvos: if you have a list of things you'd like to see included, please share here and I can add it as notes to me and ivan
<uvos> Wizzup: ok
<Wizzup> uvos: and yes very sweet for sure, I'm apt upgrading
<uvos> btw anyone messing around with the mz617..
<uvos> tmlind maybe
<uvos> do you also have the problem that under android the device often just dosent charge, it looks like its charging but its really not
<uvos> dosent seam to depend on the charger used at all
<uvos> and happens randomly
<uvos> and conceringly often
<tmlind> uvos: seems to charge ok for me, or have not paid attention to it
<uvos> ok its very obivous
<tmlind> uvos: the mainline kernel patches charge too, but at a slow rate as the bq driver support with cpcap-gpio is missing
<uvos> i plug it in and android plays the charging animation and says its charging
<uvos> but then in reality the battery will drain
<uvos> all the way untill the device crashes
<uvos> if i unplug and replug the device it will charge for real for some time (not that you can tell if it suceeded in starting to charge)
<uvos> but inevitably it will drop again at some point
<uvos> maybe my unit is simply defective
<tmlind> i don't think i have seen that
<uvos> might androids reaction to it detecting the battery having failed
<Wizzup> uvos: so the calls are on the loudspeaker, right, not on the earpiece?
<uvos> by some internal metric
<uvos> Wizzup: yeah
<uvos> Wizzup: earpice is impossible
<uvos> due to the kernel bug
<uvos> its alls really quiet
<uvos> but thats becasue of
<Wizzup> right, just good to know for testing
<uvos> missing that
<Wizzup> parazyd will be back tomorrow, I hope he can help pick up some of that
<uvos> ok
<uvos> note other blemishes with voice calls on mapphones: multiple calls (ie heldcalles multiparty etc) dont work
<uvos> sphone supports all of this
<uvos> but cant test
<uvos> may work on pp
<Wizzup> I've never really used that much
<tmlind> uvos: i think i've been mostly charging mz617 with my laptop usb and not with a real charger so may not have seen your issue
<tmlind> or if i've had a low battery, i've used the charge mode only, not android
inky_ has quit [Ping timeout: 245 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
inky_ has joined #maemo-leste
Blikje has quit [Ping timeout: 250 seconds]
<inky_> is it a pire coincidence that motorola devices are supported by mainline kernels?
<inky_> or did motorola contribute to kernel?
<inky_> how high is the cisc that kernel devs would decide to remove a device support because it is old?
<inky_> sorry, s/cisc/risc/ ((((:
<inky_> s/pire/pure/
<uvos> motorola did nothing to help the kernel along in fact they locked the devices down as mutch as possible
<uvos> the reason why the moto devices are well supported is mostly becasue the omap is well supported becasue of ti's efforts and the efforts of the sbc community and sutch
<uvos> the moto devices are also very dev frendly hw wise in that the cpcap chip allows you to debug the device easly becasue it allows you to muliplex the omaps uart and any of the connected usb devices out to the usb port
<uvos> which is nice
<inky> uvos: thanks for explaining!
Pali has quit [Ping timeout: 240 seconds]
uvos has quit [Ping timeout: 240 seconds]
marex has quit [Ping timeout: 245 seconds]
yanu has quit [Ping timeout: 240 seconds]