| sicelo | arno11 we'll need to do something about proximity sensing for calls | 09:39 |
|---|---|---|
| uvos__ | sicelo: dose it not work on n900? | 09:59 |
| uvos__ | ah its on the evdev interface and not iio so not supported | 10:00 |
| uvos__ | do i remember that right? | 10:00 |
| sicelo | yes. when support for the interface was removed in leste, it didn't matter, because we had no calls. | 12:04 |
| sicelo | now it matters. can we have it restored? | 12:05 |
| uvos__ | well we could write a mce module that implements reading prox from evdev | 12:06 |
| uvos__ | but evdev is a depricated interface for this usecase | 12:07 |
| uvos__ | so adjusting the driver would be better | 12:07 |
| uvos__ | the driver was trivial iirc? its just a gpio or something? | 12:07 |
| sicelo | evdev is definitely not deprecated for this | 12:09 |
| uvos__ | writeing a mce module would also be the wrong thing to do | 12:10 |
| sicelo | there's no driver for the proximity, since it's just a switch | 12:10 |
| uvos__ | since the abstraction is hanndled by iio-sensor-proxy | 12:10 |
| uvos__ | sicelo: sensors on evdev are deprecated | 12:11 |
| uvos__ | the prox is a sensor | 12:11 |
| uvos__ | no matter how its implemented | 12:11 |
| uvos__ | imo | 12:11 |
| sicelo | it's fine to havean opinion opinion about it. doesn't work in this case though | 12:11 |
| uvos__ | so how is it a "switch" | 12:12 |
| sicelo | iio prefers standalone sensors, with drivers, as you correctly said | 12:12 |
| uvos__ | its just a gpio key then? | 12:12 |
| uvos__ | or is it on the kbd matrix | 12:12 |
| sicelo | anyway, ill | 12:12 |
| sicelo | it's gpio key yes | 12:13 |
| uvos__ | ok | 12:13 |
| uvos__ | then its not really a key | 12:13 |
| uvos__ | its a gpio | 12:13 |
| uvos__ | and we can trival write a iio driver | 12:13 |
| sicelo | ok. | 12:14 |
| uvos__ | so those are the options: write a iio driver for the gpio | 12:14 |
| uvos__ | or write a evdev module for iio-sensor-proxy | 12:14 |
| uvos__ | both are not very hard, iio-s-p allready has a evdev module for accelerometers that we can reference/cut down | 12:15 |
| Wizzup | can we make the kernel module do iio ? | 12:31 |
| Wizzup | yeah what uvos said | 12:31 |
| sicelo | you can't change this proximity from evdev on kernel side. it's just how it is, and definitely not deprecated by anyone | 12:43 |
| 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 | 12:43 |
| Wizzup | What I mean is that the kernel seems to want to move this into a single subsystem, right? | 12:43 |
| Wizzup | Or, why would they have some in evdev and some in iio? | 12:44 |
| sicelo | that's for 'sensors' ... not binary switches | 12:44 |
| Wizzup | isn't the proximity sensor a sensor, just exposed as binary switch through evdev? | 12:45 |
| Wizzup | or is the actual sensor not exposed on the hw interface? | 12:45 |
| sicelo | no, it's a binary switch | 12:45 |
| Wizzup | hah, wow | 12:45 |
| sicelo | yeah, hence evdev. I'm away from laptop . .. would show you the actual part. | 12:48 |
| uvos__ | its still a sensor | 12:51 |
| uvos__ | its just a 1 bit proximitry sensor | 12:51 |
| uvos__ | that dosent make it not a sensor | 12:51 |
| uvos__ | and yes we can absolutly change it on the kernel side | 12:54 |
| uvos__ | doing so is almost trival | 12:54 |
| uvos__ | take the ping-gpio iio proximitry sensor driver | 12:55 |
| uvos__ | rip out the time of flight code | 12:55 |
| uvos__ | done | 12:55 |
| sicelo | cool waiting for your patch | 12:56 |
| uvos__ | its just a gpio | 13:18 |
| uvos__ | sure ill do it | 13:18 |
| sicelo | i think now i see how it could be done kernel side | 14:52 |
| uvos__ | great | 15:13 |
| uvos__ | but dont worry about it ill do it | 15:13 |
| 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 | 16:30 |
| sicelo | and of course, that means have to pull lock slider before i can pick the call as well | 16:31 |
| sicelo | also, when call terminates, at least from remote end, the 'in-call' screen remains for a noticeable while | 16:34 |
| Wizzup | sicelo: yes, it does remain, that is on purpose | 16:37 |
| Wizzup | what it should do is render a notification bar (the tiny one) saying the call was hung up | 16:37 |
| sicelo | I'm curious - what's the purpose behind it? | 16:38 |
| Wizzup | to do exactly what fremantle does | 16:38 |
| Wizzup | show the UI for a bit after the call is done | 16:38 |
| 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. | 16:38 |
| Wizzup | before I basically felt like the UI crashed | 16:38 |
| Wizzup | that's how quickly it disappeared | 16:39 |
| sicelo | Wizzup: ok... it seems a bit too long to me though | 16:39 |
| sicelo | anyway, notification will be fine | 16:39 |
| sicelo | does the touchscreen issue happen for you? | 16:40 |
| Wizzup | rarely, but sometimes @ ts | 16:46 |
| 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)? | 16:46 |
| sicelo | note to self - must cleanup and post ofono patch for review by upstream :-) | 16:47 |
| freemangordon | sicelo: I would bet there is already iio-gpio driver | 16:49 |
| freemangordon | lemme check | 16:49 |
| 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 ? | 16:51 |
| freemangordon | uvos__: actually, are we sure this is a sensor? because proximity sensor is supposed to measur the distance | 16:53 |
| freemangordon | what type of sensor would that be then? | 16:53 |
| uvos__ | freemangordon: its a proximity sensor that only tells you if the object is closer than x cm or father than x centimeters | 16:55 |
| uvos__ | android phones have this setup often | 16:55 |
| uvos__ | and they do use iio here too | 16:55 |
| freemangordon | I understand what you say | 16:55 |
| 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 | 16:55 |
| 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 | 16:56 |
| freemangordon | the point is - do we know how close it switches and does proximity iio iface allows us to report state only | 16:56 |
| uvos__ | the latter, absolutly | 16:56 |
| freemangordon | ok | 16:57 |
| sicelo | 1 = near | 16:57 |
| * freemangordon checks | 16:57 | |
| uvos__ | the former, the datasheet presumably has referance values | 16:57 |
| sicelo | it's about 3cm, iirc | 16:58 |
| 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") | 16:58 |
| sicelo | mmm, why not just 0 & 1? | 16:59 |
| freemangordon | becasue it is proximity | 17:00 |
| freemangordon | :) | 17:00 |
| sicelo | then in dts, have near-level =1 | 17:00 |
| sicelo | I'm not sure we should report bogus values | 17:01 |
| uvos__ | so actually what the d4 dose | 17:01 |
| uvos__ | is it dosent report a real distance at all | 17:01 |
| freemangordon | sicelo: what is the name of the evdev driver? | 17:01 |
| sicelo | there isn't:-) | 17:01 |
| uvos__ | it reports 0 for "cant see anything" and 255 for "0 cm" | 17:02 |
| freemangordon | ah | 17:02 |
| uvos__ | and iio-sensor-proxy scales this based on udev data | 17:02 |
| sicelo | freemangordon: just EV_SW | 17:02 |
| freemangordon | right | 17:02 |
| freemangordon | so this sensor is not on i2c bus? | 17:02 |
| sicelo | nope. | 17:02 |
| uvos__ | its just a gpio | 17:02 |
| freemangordon | ok | 17:02 |
| freemangordon | ok | 17:02 |
| freemangordon | I think we shall create a general-purpose driver | 17:03 |
| uvos__ | yes | 17:03 |
| uvos__ | as i say just rip the time of flight stuff out of the ping driver | 17:03 |
| sicelo | uvos__: you mean the sensor only ever reports 0 and 255? weird | 17:03 |
| uvos__ | writes itself essentally | 17:03 |
| uvos__ | sicelo: no it reports 0-255 | 17:03 |
| sicelo | ok. that sounds ok then | 17:03 |
| uvos__ | but we dont have scale in dts | 17:04 |
| uvos__ | so we dont get real values on d4 | 17:04 |
| freemangordon | ok, but that's not what we have here | 17:04 |
| uvos__ | (should improve this) | 17:04 |
| freemangordon | so on d4 you have a real sensor | 17:04 |
| uvos__ | freemangordon: sure but 0-255 is arbitrary | 17:04 |
| uvos__ | freemangordon: we can do 0-1 too | 17:04 |
| freemangordon | albeit uncalibrated/poorly supported | 17:04 |
| freemangordon | we don;t have the same on n900 | 17:05 |
| uvos__ | the d4 has 8 bits and n900 has 1 bit | 17:05 |
| uvos__ | its the same otherwise | 17:05 |
| freemangordon | heh | 17:05 |
| freemangordon | I think if you try to upstream that they will say this is not a sensor | 17:05 |
| uvos__ | i doubt | 17:05 |
| sicelo | yes it's tricky :-) | 17:05 |
| freemangordon | sicelo: maybe post a question to LKML | 17:06 |
| freemangordon | to iio maintainers | 17:06 |
| freemangordon | to see what is their stance | 17:06 |
| sicelo | sure. | 17:06 |
| freemangordon | once we know what we shall do, either me or uvos will write the appropriate driver | 17:06 |
| freemangordon | if needed | 17:07 |
| freemangordon | because my gut feeling tells me they will say "this is SW_FRONT_PROXIMITY" | 17:08 |
| sicelo | yes, https://www.spinics.net/lists/linux-iio/msg04555.html suggests so | 17:08 |
| freemangordon | and nonestly, to me this seems right | 17:08 |
| sicelo | but when i read it earlier, i thought ... maybe things have changed, that was 2012 after all | 17:08 |
| uvos__ | this was before iio was really established | 17:09 |
| freemangordon | but wait, we still have that defined in dts | 17:09 |
| 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 | 17:09 |
| uvos__ | ofc we do currently its exposed on evdev | 17:10 |
| uvos__ | sicelo: no issue, or new driver can report to both | 17:10 |
| uvos__ | sicelo: some accelerometer drivers do this to | 17:10 |
| freemangordon | uvos__: I think if they wanted to change it to iio, they would have removed SW_FRONT_PROXIMITY" | 17:10 |
| uvos__ | to ease migration from evdev to iio | 17:10 |
| uvos__ | freemangordon: no they also dident remove th evdev accelerometer drivers either | 17:10 |
| sicelo | they s | 17:11 |
| freemangordon | ok, lets just ask... | 17:11 |
| uvos__ | sicelo: ? | 17:11 |
| sicelo | they won't remove those drivers. they provide a lot of stuff that's not accounted for in iio | 17:11 |
| sicelo | sorry typos ... terrible android vkb | 17:11 |
| uvos__ | right, it makes no sense to remove working drivers | 17:11 |
| uvos__ | but newer drivers are universally iio | 17:11 |
| sicelo | lok | 17:12 |
| * sicelo gives up with typing on the phone :-p | 17:12 | |
| freemangordon | "shall we create a new "maybe general purpose iio-gpio driver that moves n900 proximity sensor from evdev/SW_FRONT_PROXIMITY to iio" | 17:12 |
| freemangordon | what do you think? | 17:13 |
| uvos__ | freemangordon: sure | 17:13 |
| sicelo | +1 | 17:13 |
| freemangordon | ok, sicelo, please, when you find a device you can type on, send a question to iio lkml/iio maintainers | 17:13 |
| sicelo | ok. will do so | 17:13 |
| freemangordon | thanks | 17:13 |
| dsc_ | freemangordon: i'm done moving and ready for abook stuff if need be | 18:08 |
| Wizzup | freemangordon: the ask being how to integrate osso-abook dialog to pick a contact in a qt app | 18:19 |
| Wizzup | (I think) | 18:19 |
| freemangordon | maybe have a look how it is done for mafw | 18:19 |
| freemangordon | it should be the same | 18:19 |
| Wizzup | freemangordon: in omp? | 18:21 |
| freemangordon | mhm | 18:22 |
| Wizzup | what mafw UI elements/dialogs are integrated/raised? | 18:23 |
| Wizzup | I see a bunch of g_object stuff | 18:23 |
| Wizzup | the string gtk doesn't really occur apart from in the .pro file and a single documentation line | 18:24 |
| freemangordon | hmm, right | 18:24 |
| Wizzup | iirc you said before to look at how the qt5 theme/style does things | 18:24 |
| freemangordon | ok, don;t have time today | 18:24 |
| freemangordon | will try to make example program tomorrow | 18:25 |
| Wizzup | cool, ty | 18:26 |
| freemangordon | see https://github.com/maemo-leste/qtstyleplugins/blob/master/src/plugins/platformthemes/maemo5/qmaemo5dialoghelpers.cpp in the meanwhile | 18:26 |
| Wizzup | qtstyleplugins/src/plugins/styles/maemo5/maemo5/qmaemo5datetimepickselector.cpp has some example | 18:26 |
| Wizzup | that is helpful, is that class accessible to other programs? | 18:26 |
| freemangordon | no | 18:27 |
| Wizzup | ok | 18:27 |
| freemangordon | but we can export it | 18:27 |
| freemangordon | qmaemo5datetimepickselector.cpp does more or less the same | 18:28 |
| freemangordon | but, iirc, for account selection, you need to run a dialog and to connect to response signal | 18:29 |
| * freemangordon checks | 18:29 | |
| Wizzup | we'd probably also want to provide additional context, like what specific TP account we might want contacts for | 18:30 |
| Wizzup | (I think something like that should be possible?) | 18:30 |
| freemangordon | https://github.com/maemo-leste/osso-abook/blob/master/lib/test-contact-chooser.c | 18:30 |
| freemangordon | please... do not do that app-centric | 18:31 |
| freemangordon | lets keep the spirit of maemo | 18:31 |
| Wizzup | this is literally what maemo does | 18:31 |
| freemangordon | you choose the contect, and there you choose what to do with it | 18:31 |
| freemangordon | no | 18:31 |
| Wizzup | go to dialer, select xmpp | 18:32 |
| Wizzup | and try to pick a context that has a regular phone number | 18:32 |
| Wizzup | contact | 18:32 |
| Wizzup | brb | 18:33 |
| freemangordon | Wizzup: go to conversations and select "new im" | 18:33 |
| freemangordon | you are presented with a list of contacts you can start chat with | 18:34 |
| freemangordon | nowhere there where in dialer you can select xmpp? | 18:34 |
| freemangordon | sorry..typos | 18:35 |
| freemangordon | where in dialer you can select xmpp? | 18:35 |
| sicelo | freemangordon: i think what he means is ... in Phone, you can select SIP | 18:35 |
| freemangordon | yes, but that's not chat | 18:35 |
| sicelo | you could select XMPP too, but i think the Fremantle plugin didn't support calls | 18:35 |
| freemangordon | conversations is about messaging | 18:35 |
| freemangordon | it does | 18:35 |
| freemangordon | iirc | 18:35 |
| sicelo | s/could/technically could/ | 18:35 |
| freemangordon | gtalk was xmpp back then | 18:36 |
| freemangordon | and bot voice and video calls were working | 18:36 |
| sicelo | you couldn't call on gtalk | 18:36 |
| freemangordon | argh | 18:36 |
| sicelo | there was a separate application for it | 18:36 |
| freemangordon | that used to work | 18:36 |
| freemangordon | no | 18:36 |
| freemangordon | you were dialing from the phone dialer | 18:36 |
| Wizzup | freemangordon: yes | 18:36 |
| freemangordon | for gtals and skype | 18:36 |
| Wizzup | conversations does it thay way | 18:36 |
| Wizzup | and we can keep that | 18:36 |
| Wizzup | np | 18:37 |
| sicelo | mmm, maybe i remember wrong then (for xmpp) | 18:37 |
| freemangordon | yes, you remember wrong | 18:37 |
| Wizzup | xmpp calls still work fwiw | 18:37 |
| Wizzup | video calls too | 18:37 |
| freemangordon | Wizzup: what is the point in showing a contact you can't start IM to? from copversations that is | 18:37 |
| 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 | 18:38 |
| Wizzup | freemangordon: I agree that's not good, I got confused | 18:38 |
| freemangordon | WTYM "does not let me decide"? | 18:38 |
| freemangordon | you already did | 18:38 |
| Wizzup | hah the dialer is stuck dialing on fremantle! | 18:39 |
| freemangordon | by pressing the button with the remote account | 18:39 |
| Wizzup | freemangordon: so if you have say 5 accounts set up | 18:39 |
| Wizzup | and several accounts share a context | 18:39 |
| Wizzup | contact | 18:39 |
| Wizzup | I don't think it lets you select the account you want to call the shared contact from | 18:39 |
| freemangordon | you choose the remote account | 18:39 |
| freemangordon | and this is linked with the local one | 18:39 |
| Wizzup | that's the problem | 18:39 |
| Wizzup | the same probllem will occur with multiple sims | 18:39 |
| freemangordon | how's that? | 18:40 |
| freemangordon | leave sims aside for now | 18:40 |
| Wizzup | freemangordon: I can't really describe is better than above, can you re-read and let me know if it's not clear? | 18:40 |
| Wizzup | actually I can make it more clear... | 18:40 |
| 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 | 18:40 |
| freemangordon | you have more than one account on same server/service? | 18:40 |
| Wizzup | if I want to call merlijn@jabber.org (or call) | 18:41 |
| freemangordon | ah, so both are @jabber.org | 18:41 |
| Wizzup | how do I say I want to use foo@ or bar@ | 18:41 |
| Wizzup | I don't think the server matters | 18:41 |
| freemangordon | it does | 18:41 |
| Wizzup | I just think there's no way in general | 18:41 |
| Wizzup | hmm | 18:41 |
| freemangordon | lemme describe | 18:41 |
| freemangordon | you have 2 acccounts foo@sever1 and bar@server2 | 18:41 |
| freemangordon | you want to dial ivo@server1 or sicelo@server2 | 18:42 |
| freemangordon | why should you make any choise? it is obvious which local account shall be used for each remote account | 18:42 |
| freemangordon | now, I am not sure what is the situation if you have multiple accounts on same server | 18:43 |
| freemangordon | but I can assure you that there *is* a dialog asking you for the local account you want to use | 18:43 |
| freemangordon | I've seen that a couple of times when importing contacts n900->d4 | 18:44 |
| freemangordon | and when I wanted to start gtalk (which was functioning back then) talk to a friend of mine | 18:44 |
| freemangordon | abook was asking me which account (local) to use | 18:45 |
| Wizzup | freemangordon: no that is not clear to me | 18:45 |
| freemangordon | also, remote accounts are 'roster' accounts and it is pretty much clear which local account they are tied to | 18:46 |
| Wizzup | why would you prefer the same xmpp server | 18:46 |
| Wizzup | there is no reason to do that at all | 18:46 |
| freemangordon | why would you want another one? | 18:46 |
| Wizzup | I'm not sure why you're flipping the question, but there's just no reason to stick with the same server | 18:46 |
| Wizzup | Like, other than personal preference | 18:47 |
| freemangordon | no, this is the same question | 18:47 |
| Wizzup | There's no technical or billing reason or something | 18:47 |
| freemangordon | \what is the use case? | 18:47 |
| 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 | 18:47 |
| Wizzup | could be that you're planning on deprecating the old account but keep it configured for now | 18:47 |
| freemangordon | like, if we want to implement such a functionality (if it is missing), why shall we do it | 18:48 |
| Wizzup | for the same reason that you want to be able to select a sip account when you dial a landline | 18:48 |
| Wizzup | it shouldn't just pick a sip account | 18:48 |
| 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 | 18:48 |
| Wizzup | but it's silly | 18:48 |
| freemangordon | no, wait | 18:49 |
| freemangordon | I am almost sure abook adds action buttons for every combination of local vs remote account | 18:49 |
| freemangordon | unfortunately I have no working accounts to test with | 18:49 |
| 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 | 18:50 |
| Wizzup | but that is a separate concern | 18:50 |
| Wizzup | I can make you infinite xmpp accounts if you wish :P | 18:50 |
| freemangordon | I think it will make sense | 18:51 |
| Wizzup | it = ? | 18:51 |
| freemangordon | (make several accounts) | 18:51 |
| freemangordon | but wait | 18:51 |
| Wizzup | ok, let's look at this over the weekend maybe? | 18:51 |
| freemangordon | those will be on the same server, right? | 18:51 |
| freemangordon | yeah, over the weekend | 18:52 |
| Wizzup | freemangordon: yes, same server | 18:52 |
| Wizzup | but I can set up another one | 18:52 |
| freemangordon | ok, lemme see if I got it right | 18:52 |
| freemangordon | you want to be able to choose the 'from' account where dialing (or chatting) out, correct? | 18:53 |
| freemangordon | I imagine that can be implemented as an action per local account | 18:54 |
| freemangordon | if not already there | 18:54 |
| freemangordon | ok, please, make me 2 test accounts on your server | 18:54 |
| freemangordon | when you have time that is | 18:54 |
| Wizzup | ok | 18:55 |
| freemangordon | hmm, I already have one | 18:55 |
| freemangordon | so one more is needed | 18:56 |
| freemangordon | also, somehow that account shall become roster | 18:56 |
| freemangordon | i.e. now I don;t see any accounts on the server | 18:56 |
| freemangordon | or, you can give me your account | 18:57 |
| Wizzup | hm? | 18:58 |
| freemangordon | I don;t have your jabber account :) | 18:58 |
| Wizzup | send over dm | 18:58 |
| freemangordon | yeah | 19:00 |
| freemangordon | ok, I am almost 99% sure what you requested is already here | 19:00 |
| Wizzup | hm | 19:00 |
| freemangordon | because when I tried to add your account, I am aked for th elocal account | 19:00 |
| freemangordon | *asked | 19:00 |
| freemangordon | anyway | 19:01 |
| Wizzup | right, that is to make a contact | 19:01 |
| Wizzup | but you can have my xmpp account as contact on more than one of your xmpp accounts | 19:01 |
| freemangordon | just add the same remote account for the another local account | 19:01 |
| Wizzup | yes | 19:02 |
| freemangordon | *the other | 19:02 |
| Wizzup | so that is what I have | 19:02 |
| Wizzup | but then I don't have the ability (I think) to select which local account to use | 19:02 |
| freemangordon | ok, isn't that what you wanted? | 19:02 |
| Wizzup | no, that's the problem :) | 19:02 |
| freemangordon | oh, maybe it is not visible | 19:02 |
| Wizzup | it's not account adding contacts, it's about not being able to pick which local account to use for an action (call) | 19:02 |
| freemangordon | you do it implicitly by selection the action | 19:03 |
| freemangordon | each action is tied to local and remote account to be used | 19:03 |
| Wizzup | you're looking at the new im in conversations I guess? | 19:03 |
| Wizzup | where you see the accounts several times in this case? | 19:03 |
| Wizzup | (the same remote accounts several times) | 19:03 |
| freemangordon | no, I am looking at addressbook | 19:03 |
| freemangordon | I don;t see them | 19:04 |
| freemangordon | because I didn't add them | 19:04 |
| Wizzup | well, so with the situation I described | 19:04 |
| freemangordon | as I still don;t have second account to use | 19:04 |
| Wizzup | I see some accounts twice | 19:04 |
| Wizzup | with the same text/name | 19:04 |
| Wizzup | remote accounts | 19:04 |
| Wizzup | because different local accounts have it in their roster | 19:04 |
| freemangordon | and you don't know which one is which? | 19:04 |
| Wizzup | right | 19:04 |
| freemangordon | ok, so it is not that the functionality is not there | 19:05 |
| Wizzup | but also when doing a call from the dialer it won't let you pick, it just picks one, afaict | 19:05 |
| Wizzup | but that I will have to triple check | 19:05 |
| freemangordon | this is UI issue (local account not shown) | 19:05 |
| freemangordon | so I guess I can prepend the local account with the remote one | 19:06 |
| freemangordon | instead of just showing wizzup@xmpp.com it will show ivo@xmpp.com/wizzup@xmpp.com | 19:07 |
| freemangordon | is that ok? | 19:07 |
| freemangordon | or something similar UI wise | 19:07 |
| Wizzup | right, something like that could work | 19:08 |
| freemangordon | or, perhaps I can just put a separator with the account name | 19:08 |
| freemangordon | ok, will decide on that | 19:09 |
| boshtannik | Hello everyone | 19:38 |
| boshtannik | Have something changed in permissions to create networking interfaces during updates? | 19:38 |
| sicelo | maybe provide more info | 19:39 |
| 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. | 19:39 |
| 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 | 19:39 |
| boshtannik | may be it's updated yggdrasil client, that fails internally, due to the code change | 19:40 |
| boshtannik | I guess, i found other way to register that autostart service | 19:43 |
| boshtannik | here is the possible script for running service *i guess* | 19:50 |
| boshtannik | is the openrc is used? | 19:50 |
| 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. | 20:22 |
| arno11 | others apps around 1 sec with u3 | 20:23 |
| sicelo | i've just booted my N900. will update in a moment. not sure what goodies i might be missing, if any | 20:24 |
| Wizzup | arno11: is this 16bit? | 20:40 |
| arno11 | yes | 20:41 |
| arno11 | + overclock + transitions | 20:41 |
| arno11 | and it's really fast | 20:42 |
| sicelo | still upgrading. i have 6.1.48 kernel. that already has the overclockable dtb? | 20:45 |
| arno11 | nope apparently :( | 20:45 |
| Wizzup | hm, it should in -devel | 20:51 |
| Wizzup | arno11: so in 16bit qml does not work yet, rightg | 20:52 |
| Wizzup | right* ? | 20:52 |
| arno11 | yep | 20:52 |
| buZz | arno11: did you notice insane pricedrops for U3 cards? i bought 6x 64GB U3 microSD for ~3 euro a piece | 20:52 |
| buZz | dubious brand, but legit flash , i fff/f3'd the cards | 20:52 |
| buZz | ah they made them a bit more expensive now ; https://storageisland.nl/sp064gbstxdu3v20ab-64gb-microsdxc-superior-pro-v30-class-10-r-w-up-to-100-80-mb-s/ | 20:53 |
| arno11 | i bought mine 25e...lol | 20:54 |
| arno11 | Wizzup: overclock not present in devel and i don't understand why | 20:54 |
| buZz | arno11: dang :D | 20:54 |
| Wizzup | arno11: weird, maybe check with uvos | 20:57 |
| arno11 | yep | 20:57 |
| arno11 | uvos: is it normal we can't already use boost freqs in -devel 6.1.48 ? | 20:59 |
| arno11 | it is still the old opp-table with 125-600 in dtb | 21:01 |
| arno11 | same in 6.1.9 | 21:02 |
| arno11 | and boost folder is not present in /sys/devices/system/cpu/cpufreq so definitely means boost is not activated, otherwise it appears automatically | 21:05 |
| arno11 | buZz: wow a pint of beer is more expensive... | 21:11 |
| buZz | exactly | 21:12 |
| Wizzup | why not both, u3 in a pint of beer | 21:12 |
| arno11 | buy 2 pints, and get a u3 for free | 21:17 |
| Wizzup | :D | 21:21 |
| sicelo | arno11: while on your N900, please show me output of, `busctl call org.ofono / org.ofono.Manager GetModems` | 21:46 |
| arno11 | ok | 21:59 |
| arno11 | a(oa{sv}) 0 | 22:00 |
| sicelo | mmm, :-P | 22:01 |
| sicelo | that can't be ... | 22:01 |
| sicelo | run it when modem is ready ... e.g. in state to be able to receive a call | 22:03 |
| arno11 | oops sorry lol | 22:03 |
| arno11 | which part of the result you need ? | 22:07 |
| sicelo | from "Interfaces" to the end | 22:07 |
| 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" | 22:08 |
| arno11 | "org.ofono.VoiceCallManager" "org.ofono.AudioSettings" "Features" as 7 "sms" "cbs" "rat" "gprs" "net" "ussd" "sim" "Type" s "hardware" | 22:09 |
| sicelo | thanks | 22:09 |
| arno11 | no probs | 22:10 |
| uvos | arno11: yes its normal, imerged the patch, but no kernel was ever relased with it | 23:19 |
| uvos | arno11: currently im 99% there with 6.6 with just a cpufreq issue remaining, will be in this release | 23:19 |
| arno11 | ok cool | 23:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!