meridion has quit [Server closed connection]
meridion has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #maemo-leste
Pali has quit [Ping timeout: 256 seconds]
eval has quit [Server closed connection]
eval has joined #maemo-leste
LjL has quit [Server closed connection]
LjL has joined #maemo-leste
ahmed_sam has joined #maemo-leste
ahmed_sam has quit [Read error: Connection reset by peer]
moparisthebest has quit [Server closed connection]
gnarface has quit [Ping timeout: 268 seconds]
gnarface has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
Kabouik has quit [Server closed connection]
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
Kabouik has joined #maemo-leste
nohit has quit [Server closed connection]
nohit has joined #maemo-leste
noidea_ has quit [Server closed connection]
noidea_ has joined #maemo-leste
Daanct12 has joined #maemo-leste
doc has quit [Ping timeout: 255 seconds]
<sicelo> arno11 we'll need to do something about proximity sensing for calls
xes has quit [Server closed connection]
xes has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__> sicelo: dose it not work on n900?
<uvos__> ah its on the evdev interface and not iio so not supported
<uvos__> do i remember that right?
vectis has quit [Ping timeout: 260 seconds]
ceene has joined #maemo-leste
tk has quit [Server closed connection]
tk has joined #maemo-leste
elastic_dog has quit [Ping timeout: 268 seconds]
vectis has joined #maemo-leste
elastic_dog has joined #maemo-leste
Juest has quit [Ping timeout: 260 seconds]
Juest has joined #maemo-leste
pere has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
ac_laptop has joined #maemo-leste
<sicelo> yes. when support for the interface was removed in leste, it didn't matter, because we had no calls.
<sicelo> now it matters. can we have it restored?
<uvos__> well we could write a mce module that implements reading prox from evdev
<uvos__> but evdev is a depricated interface for this usecase
<uvos__> so adjusting the driver would be better
<uvos__> the driver was trivial iirc? its just a gpio or something?
<sicelo> evdev is definitely not deprecated for this
<uvos__> writeing a mce module would also be the wrong thing to do
<sicelo> there's no driver for the proximity, since it's just a switch
<uvos__> since the abstraction is hanndled by iio-sensor-proxy
<uvos__> sicelo: sensors on evdev are deprecated
<uvos__> the prox is a sensor
<uvos__> no matter how its implemented
<uvos__> imo
<sicelo> it's fine to havean opinion opinion about it. doesn't work in this case though
<uvos__> so how is it a "switch"
<sicelo> iio prefers standalone sensors, with drivers, as you correctly said
<uvos__> its just a gpio key then?
<uvos__> or is it on the kbd matrix
<sicelo> anyway, ill
<sicelo> it's gpio key yes
<uvos__> ok
<uvos__> then its not really a key
<uvos__> its a gpio
<uvos__> and we can trival write a iio driver
<sicelo> ok.
<uvos__> so those are the options: write a iio driver for the gpio
<uvos__> or write a evdev module for iio-sensor-proxy
<uvos__> both are not very hard, iio-s-p allready has a evdev module for accelerometers that we can reference/cut down
Pali has joined #maemo-leste
<Wizzup> can we make the kernel module do iio ?
<Wizzup> yeah what uvos said
<sicelo> you can't change this proximity from evdev on kernel side. it's just how it is, and definitely not deprecated by anyone
<sicelo> and yes, iio can be taught to support evdev sensors. see the discussion i had with iio folk some months ago, https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/363
<Wizzup> What I mean is that the kernel seems to want to move this into a single subsystem, right?
<Wizzup> Or, why would they have some in evdev and some in iio?
<sicelo> that's for 'sensors' ... not binary switches
<Wizzup> isn't the proximity sensor a sensor, just exposed as binary switch through evdev?
<Wizzup> or is the actual sensor not exposed on the hw interface?
<sicelo> no, it's a binary switch
<Wizzup> hah, wow
<sicelo> yeah, hence evdev. I'm away from laptop . .. would show you the actual part.
<uvos__> its still a sensor
<uvos__> its just a 1 bit proximitry sensor
<uvos__> that dosent make it not a sensor
<uvos__> and yes we can absolutly change it on the kernel side
<uvos__> doing so is almost trival
<uvos__> take the ping-gpio iio proximitry sensor driver
<uvos__> rip out the time of flight code
<uvos__> done
<sicelo> cool waiting for your patch
Daanct12 has quit [Ping timeout: 256 seconds]
Daanct12 has joined #maemo-leste
<uvos__> its just a gpio
<uvos__> sure ill do it
ceene has quit [Ping timeout: 260 seconds]
aat596_3 has quit [Quit: ZNC 1.8.2 - https://znc.in]
pere has quit [Ping timeout: 260 seconds]
aat596_3 has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 4.1.1]
moparisthebest has joined #maemo-leste
<sicelo> i think now i see how it could be done kernel side
<uvos__> great
<uvos__> but dont worry about it ill do it
<sicelo> is it just my device, but many times when i get an incoming call (droid 4), touchscreen doesn't work to accept call. i have to double-tap power key first
<sicelo> and of course, that means have to pull lock slider before i can pick the call as well
<sicelo> also, when call terminates, at least from remote end, the 'in-call' screen remains for a noticeable while
<Wizzup> sicelo: yes, it does remain, that is on purpose
<Wizzup> what it should do is render a notification bar (the tiny one) saying the call was hung up
<sicelo> I'm curious - what's the purpose behind it?
<Wizzup> to do exactly what fremantle does
<Wizzup> show the UI for a bit after the call is done
<sicelo> but yes, some notification is fine. as it is now, you're not sure if the other person still hears you, phone is hung, etc.
<Wizzup> before I basically felt like the UI crashed
<Wizzup> that's how quickly it disappeared
<sicelo> Wizzup: ok... it seems a bit too long to me though
<sicelo> anyway, notification will be fine
pere has joined #maemo-leste
<sicelo> does the touchscreen issue happen for you?
<Wizzup> rarely, but sometimes @ ts
<sicelo> i also would like to have ussd (it's important with my operators). i guess it must go into sphone. what's best - directly via ofono, or via something like telepathy (not sure if it supports ussd)?
<sicelo> note to self - must cleanup and post ofono patch for review by upstream :-)
<freemangordon> sicelo: I would bet there is already iio-gpio driver
<freemangordon> lemme check
<sicelo> wonder why i get the ts issue so much then. do you have any idea what could be causing it? maybe some race within mce between unlocking and reactivating ts ?
<freemangordon> uvos__: actually, are we sure this is a sensor? because proximity sensor is supposed to measur the distance
<freemangordon> what type of sensor would that be then?
<uvos__> freemangordon: its a proximity sensor that only tells you if the object is closer than x cm or father than x centimeters
<uvos__> android phones have this setup often
<uvos__> and they do use iio here too
<freemangordon> I understand what you say
<sicelo> for the record, i do consider it a sensor ... but yes, a switch, hence i quoted my use of that word in the earlier discussion. i see my meaning wasn't obvious
<sicelo> freemangordon: sure. yes that ping driver is close enough. there's also cros_ec_mkbp_proximity. i didn't realize it was already in mainline. it has some resemblance with the one for N900
<freemangordon> the point is - do we know how close it switches and does proximity iio iface allows us to report state only
<uvos__> the latter, absolutly
<freemangordon> ok
<sicelo> 1 = near
* freemangordon checks
<uvos__> the former, the datasheet presumably has referance values
<sicelo> it's about 3cm, iirc
<uvos__> great so we report 0cm if its near and 3cm if its far, thats how the d4 works too (it saturates at some cm and then thats "infinite")
<sicelo> mmm, why not just 0 & 1?
<freemangordon> becasue it is proximity
<freemangordon> :)
<sicelo> then in dts, have near-level =1
<sicelo> I'm not sure we should report bogus values
<uvos__> so actually what the d4 dose
<uvos__> is it dosent report a real distance at all
<freemangordon> sicelo: what is the name of the evdev driver?
<sicelo> there isn't:-)
<uvos__> it reports 0 for "cant see anything" and 255 for "0 cm"
<freemangordon> ah
<uvos__> and iio-sensor-proxy scales this based on udev data
<sicelo> freemangordon: just EV_SW
<freemangordon> right
<freemangordon> so this sensor is not on i2c bus?
<sicelo> nope.
<uvos__> its just a gpio
<freemangordon> ok
<freemangordon> ok
<freemangordon> I think we shall create a general-purpose driver
<uvos__> yes
<uvos__> as i say just rip the time of flight stuff out of the ping driver
<sicelo> uvos__: you mean the sensor only ever reports 0 and 255? weird
<uvos__> writes itself essentally
<uvos__> sicelo: no it reports 0-255
<sicelo> ok. that sounds ok then
<uvos__> but we dont have scale in dts
<uvos__> so we dont get real values on d4
<freemangordon> ok, but that's not what we have here
<uvos__> (should improve this)
<freemangordon> so on d4 you have a real sensor
<uvos__> freemangordon: sure but 0-255 is arbitrary
<uvos__> freemangordon: we can do 0-1 too
<freemangordon> albeit uncalibrated/poorly supported
<freemangordon> we don;t have the same on n900
<uvos__> the d4 has 8 bits and n900 has 1 bit
<uvos__> its the same otherwise
<freemangordon> heh
<freemangordon> I think if you try to upstream that they will say this is not a sensor
<uvos__> i doubt
<sicelo> yes it's tricky :-)
<freemangordon> sicelo: maybe post a question to LKML
<freemangordon> to iio maintainers
<freemangordon> to see what is their stance
<sicelo> sure.
<freemangordon> once we know what we shall do, either me or uvos will write the appropriate driver
<freemangordon> if needed
<freemangordon> because my gut feeling tells me they will say "this is SW_FRONT_PROXIMITY"
<freemangordon> and nonestly, to me this seems right
<sicelo> but when i read it earlier, i thought ... maybe things have changed, that was 2012 after all
<uvos__> this was before iio was really established
<freemangordon> but wait, we still have that defined in dts
<sicelo> changing to iio will also break any userspace that depended on EV_SW ... not that this should stop progress, and yes, there's no much remaining old userspace
<uvos__> ofc we do currently its exposed on evdev
<uvos__> sicelo: no issue, or new driver can report to both
<uvos__> sicelo: some accelerometer drivers do this to
<freemangordon> uvos__: I think if they wanted to change it to iio, they would have removed SW_FRONT_PROXIMITY"
<uvos__> to ease migration from evdev to iio
<uvos__> freemangordon: no they also dident remove th evdev accelerometer drivers either
<sicelo> they s
<freemangordon> ok, lets just ask...
<uvos__> sicelo: ?
<sicelo> they won't remove those drivers. they provide a lot of stuff that's not accounted for in iio
<sicelo> sorry typos ... terrible android vkb
<uvos__> right, it makes no sense to remove working drivers
<uvos__> but newer drivers are universally iio
<sicelo> lok
* sicelo gives up with typing on the phone :-p
<freemangordon> "shall we create a new "maybe general purpose iio-gpio driver that moves n900 proximity sensor from evdev/SW_FRONT_PROXIMITY to iio"
<freemangordon> what do you think?
<uvos__> freemangordon: sure
<sicelo> +1
<freemangordon> ok, sicelo, please, when you find a device you can type on, send a question to iio lkml/iio maintainers
<sicelo> ok. will do so
<freemangordon> thanks
uvos__ has quit [Remote host closed the connection]
<dsc_> freemangordon: i'm done moving and ready for abook stuff if need be
<Wizzup> freemangordon: the ask being how to integrate osso-abook dialog to pick a contact in a qt app
<Wizzup> (I think)
<freemangordon> maybe have a look how it is done for mafw
<freemangordon> it should be the same
pere has quit [Ping timeout: 255 seconds]
<Wizzup> freemangordon: in omp?
<freemangordon> mhm
<Wizzup> what mafw UI elements/dialogs are integrated/raised?
<Wizzup> I see a bunch of g_object stuff
<Wizzup> the string gtk doesn't really occur apart from in the .pro file and a single documentation line
<freemangordon> hmm, right
<Wizzup> iirc you said before to look at how the qt5 theme/style does things
<freemangordon> ok, don;t have time today
<freemangordon> will try to make example program tomorrow
<Wizzup> cool, ty
<Wizzup> qtstyleplugins/src/plugins/styles/maemo5/maemo5/qmaemo5datetimepickselector.cpp has some example
<Wizzup> that is helpful, is that class accessible to other programs?
<freemangordon> no
<Wizzup> ok
<freemangordon> but we can export it
<freemangordon> qmaemo5datetimepickselector.cpp does more or less the same
<freemangordon> but, iirc, for account selection, you need to run a dialog and to connect to response signal
* freemangordon checks
<Wizzup> we'd probably also want to provide additional context, like what specific TP account we might want contacts for
<Wizzup> (I think something like that should be possible?)
<freemangordon> please... do not do that app-centric
<freemangordon> lets keep the spirit of maemo
<Wizzup> this is literally what maemo does
<freemangordon> you choose the contect, and there you choose what to do with it
<freemangordon> no
<Wizzup> go to dialer, select xmpp
<Wizzup> and try to pick a context that has a regular phone number
<Wizzup> contact
<Wizzup> brb
<freemangordon> Wizzup: go to conversations and select "new im"
<freemangordon> you are presented with a list of contacts you can start chat with
<freemangordon> nowhere there where in dialer you can select xmpp?
<freemangordon> sorry..typos
<freemangordon> where in dialer you can select xmpp?
<sicelo> freemangordon: i think what he means is ... in Phone, you can select SIP
<freemangordon> yes, but that's not chat
<sicelo> you could select XMPP too, but i think the Fremantle plugin didn't support calls
<freemangordon> conversations is about messaging
<freemangordon> it does
<freemangordon> iirc
<sicelo> s/could/technically could/
<freemangordon> gtalk was xmpp back then
<freemangordon> and bot voice and video calls were working
<sicelo> you couldn't call on gtalk
<freemangordon> argh
<sicelo> there was a separate application for it
<freemangordon> that used to work
<freemangordon> no
<freemangordon> you were dialing from the phone dialer
<Wizzup> freemangordon: yes
<freemangordon> for gtals and skype
<Wizzup> conversations does it thay way
<Wizzup> and we can keep that
<Wizzup> np
<sicelo> mmm, maybe i remember wrong then (for xmpp)
<freemangordon> yes, you remember wrong
<Wizzup> xmpp calls still work fwiw
<Wizzup> video calls too
<freemangordon> Wizzup: what is the point in showing a contact you can't start IM to? from copversations that is
<Wizzup> so actually I can't select a contact from dialer directly, and I can select a contact but it doesn't let me decide what xmpp account to use for actually CALLING it
<Wizzup> freemangordon: I agree that's not good, I got confused
<freemangordon> WTYM "does not let me decide"?
<freemangordon> you already did
<Wizzup> hah the dialer is stuck dialing on fremantle!
<freemangordon> by pressing the button with the remote account
<Wizzup> freemangordon: so if you have say 5 accounts set up
<Wizzup> and several accounts share a context
<Wizzup> contact
<Wizzup> I don't think it lets you select the account you want to call the shared contact from
<freemangordon> you choose the remote account
<freemangordon> and this is linked with the local one
<Wizzup> that's the problem
<Wizzup> the same probllem will occur with multiple sims
<freemangordon> how's that?
<freemangordon> leave sims aside for now
<Wizzup> freemangordon: I can't really describe is better than above, can you re-read and let me know if it's not clear?
<Wizzup> actually I can make it more clear...
<Wizzup> Say I have two XMPP accounts configured: foo@jabber.org and bar@jabber.org. They're both online and they both have a contact called merlijn@jabber.org
<freemangordon> you have more than one account on same server/service?
<Wizzup> if I want to call merlijn@jabber.org (or call)
<freemangordon> ah, so both are @jabber.org
<Wizzup> how do I say I want to use foo@ or bar@
<Wizzup> I don't think the server matters
<freemangordon> it does
<Wizzup> I just think there's no way in general
<Wizzup> hmm
<freemangordon> lemme describe
<freemangordon> you have 2 acccounts foo@sever1 and bar@server2
<freemangordon> you want to dial ivo@server1 or sicelo@server2
<freemangordon> why should you make any choise? it is obvious which local account shall be used for each remote account
<freemangordon> now, I am not sure what is the situation if you have multiple accounts on same server
<freemangordon> but I can assure you that there *is* a dialog asking you for the local account you want to use
<freemangordon> I've seen that a couple of times when importing contacts n900->d4
<freemangordon> and when I wanted to start gtalk (which was functioning back then) talk to a friend of mine
<freemangordon> abook was asking me which account (local) to use
<Wizzup> freemangordon: no that is not clear to me
<freemangordon> also, remote accounts are 'roster' accounts and it is pretty much clear which local account they are tied to
<Wizzup> why would you prefer the same xmpp server
<Wizzup> there is no reason to do that at all
<freemangordon> why would you want another one?
<Wizzup> I'm not sure why you're flipping the question, but there's just no reason to stick with the same server
<Wizzup> Like, other than personal preference
<freemangordon> no, this is the same question
<Wizzup> There's no technical or billing reason or something
<freemangordon> \what is the use case?
<Wizzup> simple, you have multiple xmpp accounts that have a shared contact (they both have it), and you want to dial from a specific configured account, not the other
<Wizzup> could be that you're planning on deprecating the old account but keep it configured for now
<freemangordon> like, if we want to implement such a functionality (if it is missing), why shall we do it
<Wizzup> for the same reason that you want to be able to select a sip account when you dial a landline
<Wizzup> it shouldn't just pick a sip account
<Wizzup> in any case there is a workaround for this, go to the dialer, select your specific account, and then *manually* type in the contact name
<Wizzup> but it's silly
<freemangordon> no, wait
<freemangordon> I am almost sure abook adds action buttons for every combination of local vs remote account
<freemangordon> unfortunately I have no working accounts to test with
<Wizzup> I just tried it and it didn't, and in fact because I tried to dial a account that was also configured on the n900, it decided to hang up by itself :D
<Wizzup> but that is a separate concern
<Wizzup> I can make you infinite xmpp accounts if you wish :P
<freemangordon> I think it will make sense
<Wizzup> it = ?
<freemangordon> (make several accounts)
<freemangordon> but wait
<Wizzup> ok, let's look at this over the weekend maybe?
<freemangordon> those will be on the same server, right?
<freemangordon> yeah, over the weekend
<Wizzup> freemangordon: yes, same server
<Wizzup> but I can set up another one
<freemangordon> ok, lemme see if I got it right
<freemangordon> you want to be able to choose the 'from' account where dialing (or chatting) out, correct?
<freemangordon> I imagine that can be implemented as an action per local account
<freemangordon> if not already there
<freemangordon> ok, please, make me 2 test accounts on your server
<freemangordon> when you have time that is
<Wizzup> ok
<freemangordon> hmm, I already have one
<freemangordon> so one more is needed
<freemangordon> also, somehow that account shall become roster
<freemangordon> i.e. now I don;t see any accounts on the server
<freemangordon> or, you can give me your account
<Wizzup> hm?
<freemangordon> I don;t have your jabber account :)
<Wizzup> send over dm
<freemangordon> yeah
<freemangordon> ok, I am almost 99% sure what you requested is already here
<Wizzup> hm
<freemangordon> because when I tried to add your account, I am aked for th elocal account
<freemangordon> *asked
<freemangordon> anyway
<Wizzup> right, that is to make a contact
<Wizzup> but you can have my xmpp account as contact on more than one of your xmpp accounts
<freemangordon> just add the same remote account for the another local account
<Wizzup> yes
<freemangordon> *the other
<Wizzup> so that is what I have
<Wizzup> but then I don't have the ability (I think) to select which local account to use
<freemangordon> ok, isn't that what you wanted?
<Wizzup> no, that's the problem :)
<freemangordon> oh, maybe it is not visible
<Wizzup> it's not account adding contacts, it's about not being able to pick which local account to use for an action (call)
<freemangordon> you do it implicitly by selection the action
<freemangordon> each action is tied to local and remote account to be used
<Wizzup> you're looking at the new im in conversations I guess?
<Wizzup> where you see the accounts several times in this case?
<Wizzup> (the same remote accounts several times)
<freemangordon> no, I am looking at addressbook
<freemangordon> I don;t see them
<freemangordon> because I didn't add them
<Wizzup> well, so with the situation I described
<freemangordon> as I still don;t have second account to use
<Wizzup> I see some accounts twice
<Wizzup> with the same text/name
<Wizzup> remote accounts
<Wizzup> because different local accounts have it in their roster
<freemangordon> and you don't know which one is which?
<Wizzup> right
<freemangordon> ok, so it is not that the functionality is not there
<Wizzup> but also when doing a call from the dialer it won't let you pick, it just picks one, afaict
<Wizzup> but that I will have to triple check
<freemangordon> this is UI issue (local account not shown)
<freemangordon> so I guess I can prepend the local account with the remote one
<freemangordon> instead of just showing wizzup@xmpp.com it will show ivo@xmpp.com/wizzup@xmpp.com
<freemangordon> is that ok?
<freemangordon> or something similar UI wise
<Wizzup> right, something like that could work
<freemangordon> or, perhaps I can just put a separator with the account name
<freemangordon> ok, will decide on that
jack has joined #maemo-leste
jack is now known as boshtannik
<boshtannik> Hello everyone
<boshtannik> Have something changed in permissions to create networking interfaces during updates?
<sicelo> maybe provide more info
<boshtannik> on previous distro version on my n 900, I was able to freerly install yggdrasil client, and then i had openrc script added, which helped me to enable yggdrasil start on boot.
<boshtannik> Now it complains on that, socket file of that yggdrasil file is not created for some reason, Can not figure out where to search of the tail of that problem
<boshtannik> may be it's updated yggdrasil client, that fails internally, due to the code change
<boshtannik> I guess, i found other way to register that autostart service
elastic_dog has quit [Ping timeout: 246 seconds]
<boshtannik> here is the possible script for running service *i guess*
<boshtannik> is the openrc is used?
pere has joined #maemo-leste
elastic_dog has joined #maemo-leste
arno11 has joined #maemo-leste
boshtannik has quit [Quit: boshtannik]
<arno11> Wizzup: sicelo: i made a clone of my config on a u3 card: now qt5 apps open in 3-5 sec instead of 30 sec with a basic class10 and no tweaks.
<arno11> others apps around 1 sec with u3
<sicelo> i've just booted my N900. will update in a moment. not sure what goodies i might be missing, if any
<Wizzup> arno11: is this 16bit?
<arno11> yes
<arno11> + overclock + transitions
<arno11> and it's really fast
<sicelo> still upgrading. i have 6.1.48 kernel. that already has the overclockable dtb?
<arno11> nope apparently :(
<Wizzup> hm, it should in -devel
<Wizzup> arno11: so in 16bit qml does not work yet, rightg
<Wizzup> right* ?
<arno11> yep
<buZz> arno11: did you notice insane pricedrops for U3 cards? i bought 6x 64GB U3 microSD for ~3 euro a piece
<buZz> dubious brand, but legit flash , i fff/f3'd the cards
<arno11> i bought mine 25e...lol
<arno11> Wizzup: overclock not present in devel and i don't understand why
<buZz> arno11: dang :D
<Wizzup> arno11: weird, maybe check with uvos
<arno11> yep
<arno11> uvos: is it normal we can't already use boost freqs in -devel 6.1.48 ?
<arno11> it is still the old opp-table with 125-600 in dtb
<arno11> same in 6.1.9
<arno11> and boost folder is not present in /sys/devices/system/cpu/cpufreq so definitely means boost is not activated, otherwise it appears automatically
<arno11> buZz: wow a pint of beer is more expensive...
<buZz> exactly
<Wizzup> why not both, u3 in a pint of beer
<arno11> buy 2 pints, and get a u3 for free
<Wizzup> :D
<sicelo> arno11: while on your N900, please show me output of, `busctl call org.ofono / org.ofono.Manager GetModems`
akossh has joined #maemo-leste
<arno11> ok
<arno11> a(oa{sv}) 0
<sicelo> mmm, :-P
<sicelo> that can't be ...
<sicelo> run it when modem is ready ... e.g. in state to be able to receive a call
<arno11> oops sorry lol
<arno11> which part of the result you need ?
<sicelo> from "Interfaces" to the end
<arno11> Interfaces" as 16 "org.ofono.Phonebook" "org.ofono.SmartMessaging" "org.ofono.PushNotification" "org.ofono.MessageManager" "org.ofono.CellBroadcast" "org.ofono.RadioSettings" "org.ofono.ConnectionManager" "org.ofono.NetworkRegistration" "org.ofono.CallForwarding" "org.ofono.SupplementaryServices" "org.ofono.CallSettings" "org.ofono.CallBarring" "org.ofono.AllowedAccessPoints" "org.ofono.SimManager"
<arno11> "org.ofono.VoiceCallManager" "org.ofono.AudioSettings" "Features" as 7 "sms" "cbs" "rat" "gprs" "net" "ussd" "sim" "Type" s "hardware"
<sicelo> thanks
<arno11> no probs
uvos has joined #maemo-leste
<uvos> arno11: yes its normal, imerged the patch, but no kernel was ever relased with it
<uvos> arno11: currently im 99% there with 6.6 with just a cpufreq issue remaining, will be in this release
<arno11> ok cool
[TheBug] has quit [Changing host]
[TheBug] has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
attah has quit [Server closed connection]
attah has joined #maemo-leste
akossh has quit [Quit: Leaving.]
<ac_laptop> my n900 went off at about 17:50 and I don't know why
<ac_laptop> battery is still at 75%
<ac_laptop> I'm going to upload syslog
<ac_laptop> if anyone's reading
<ac_laptop> here it is
<ac_laptop> from boot to shutdown
<ac_laptop> is there any settings on the default setup that makes it shut down after a while ?
<Wizzup> it would be interesting to know the voltage of the battery at that point
<ac_laptop> Wizzup: is there a log file for the battery ?
<Wizzup> upower might have some data in it's history file
<Wizzup> not sure how easy it is to pull out
<Wizzup> I had a script for it...