Wizzup | on top of that I also only hear the d4 if the pavucontrol output device is speakerphone | 00:00 |
---|---|---|
Wizzup | if it's earpiece or headphone I can't hear it | 00:00 |
uvos | the mic only woring in some modes is familiar | 00:00 |
Wizzup | oh, and I had to switch the "left" item to mic1 or mic2 | 00:00 |
Wizzup | right | 00:01 |
Wizzup | "left" in the alsamixer F4 capture devices | 00:01 |
uvos | it has the same problem as the output amps | 00:01 |
uvos | just in a different place | 00:01 |
Wizzup | right | 00:01 |
Wizzup | I thought maybe it was CPCAP_REG_TXMP | 00:01 |
Wizzup | but it doesn't look like it | 00:01 |
Wizzup | but it looks like in calls the "left" value in alsamixer also isn't set to what it'd expect | 00:03 |
uvos | there was one more bit you had to set | 00:07 |
uvos | apearntly i lost the register dumps i had from android | 00:07 |
uvos | at least i cant find it right now | 00:07 |
Wizzup | ok | 00:09 |
Wizzup | I'm planning to make a local build of sphone that just runs some sh scripts that sets up the registers | 00:09 |
uvos | [23:25] <Wizzup> (sphone:4270): hildon-1-CRITICAL **: 23:24:29.107: Tried to initialized Hildon more than once. | 00:09 |
uvos | this is harmless | 00:09 |
Wizzup | ok | 00:10 |
uvos | Wizzup: https://github.com/maemo-leste/libhildon/blob/47cf0dc1c34e8d931f6644f5324d7ebb1effe763/hildon/hildon-main.c#L102 | 00:11 |
uvos | this is silly use of CRITICAL | 00:12 |
uvos | we should probubly demote it | 00:12 |
uvos | sphone calls the function more than once becasue that way it dosent have to keep track of what module loaded when and if one that requires libhildon allready loaded | 00:13 |
uvos | Wizzup: sphone can run sh scripts out of the box btw | 00:13 |
uvos | Wizzup: see this module https://github.com/maemo-leste/sphone/blob/master/src/modules/external-exec.c | 00:14 |
Wizzup | ok, but on what events? | 00:16 |
Wizzup | like if I press 'speaker' or something, there's no event, right? | 00:16 |
uvos | no i was expecting you just wanting to hack a working setup for one route into it | 00:16 |
uvos | that you could do on CallAwnserd | 00:16 |
Wizzup | right | 00:17 |
Wizzup | that can also be done with dbus-scripts, but yes, sphone itself might be easier | 00:17 |
Wizzup | well I would probably just go for the earpiece route, but that first requires working input in that mode | 00:17 |
Wizzup | in speakerphone mode I get nasty noise cancelling issues | 00:17 |
Wizzup | so that's not useful for day-to-day stuff | 00:17 |
uvos | the speakerphone headphone etc buttons in sphone actually do nothing at all btw | 00:18 |
uvos | https://github.com/maemo-leste/sphone/blob/897e852d3eab9ef0cf1aba23ff3975ee1b0f2221/src/modules/route-pulseaudio.c#L189 | 00:18 |
uvos | i never implemented it since it cant be tested | 00:18 |
Wizzup | why not? | 00:20 |
Wizzup | with register hacks it can right? | 00:20 |
uvos | sure i mean via pulse | 00:20 |
uvos | the module is called route-pulseaudio not route-registerhacks | 00:20 |
Wizzup | :p | 00:20 |
uvos | anyhow you get https://github.com/maemo-leste/sphone/blob/master/src/modapi/types.h#L36 | 00:20 |
uvos | in there | 00:20 |
uvos | (this function) | 00:20 |
Wizzup | right | 00:22 |
Wizzup | is it possible to have more than out route plugin? | 00:22 |
uvos | yes | 00:22 |
Wizzup | like what if I actually made a route-registerhack :) | 00:22 |
Wizzup | can we use them both at once? | 00:22 |
uvos | sure | 00:22 |
uvos | yes | 00:22 |
Wizzup | (well preferrably pa first) | 00:22 |
Wizzup | it almost seems worth it to me | 00:22 |
Wizzup | (for now) | 00:23 |
uvos | eh | 00:23 |
Wizzup | well there's many things that are in flight / work in progress, but if with some simple work we can make the d4 actually make calls reliably, I think that's pretty big | 00:23 |
Wizzup | of course it's not a ready solution in that sense | 00:24 |
Wizzup | but if it allows me to toy around with making calls, I think that's pretty neat | 00:24 |
Wizzup | like, I would switch my main device over if the following worked: (1) stable ofono (2) audio in calls (3) telepathy conversations with sms working | 00:25 |
uvos | you dont have to write a multi page motivation statment to me, just do it if you like | 00:25 |
uvos | i just would not do so myself, since i dont condone sutch terrible hackery | 00:25 |
uvos | and yeah sure would be neat | 00:26 |
Wizzup | I think having something this in place is more likely to lead to more interest in making a proper fix | 00:28 |
Wizzup | (including from myself) | 00:29 |
Wizzup | brb | 00:29 |
lel | IMbackK closed a pull request: https://github.com/maemo-leste/salutem/pull/2 (Many typos in uvos' name, and some more layouting for the README) | 00:32 |
lel | IMbackK closed a pull request: https://github.com/maemo-leste/salutem/pull/1 (Salutem.html had some typos) | 00:32 |
Wizzup | uvos__: so for the route module in sphone, I think apart from ringing/in-call/no-call modes, does it also need the specify what to output on? | 10:52 |
uvos__ | theres 2 datapipes, one for the call routing state (depending on if the backend sets the needs_route flag) | 10:54 |
uvos__ | and one that specifies the output sphone wants to use | 10:54 |
uvos__ | you just register on one or both in your route module | 10:54 |
Wizzup | ok | 10:54 |
uvos__ | in this case only the latter | 10:55 |
uvos__ | since the former you can just have the pa route module do | 10:55 |
uvos__ | if you are going to write something thats supposed to be loaded with the pa route module | 10:55 |
Wizzup | oh I see, pulse doesn't do the audio router trigger atm | 10:55 |
uvos__ | right | 10:55 |
Wizzup | so should I just try to implement that? | 10:56 |
uvos__ | would be good (for the pinephone) since it would work there | 10:56 |
Wizzup | it also helps on the d4 if I'd write the hypothetic reg hack | 10:56 |
uvos__ | anyhow your hack module needs to set its provides to something other than route | 10:56 |
Wizzup | hm | 10:56 |
uvos__ | Wizzup: dont add the hack to the pa route module | 10:56 |
Wizzup | uvos__: I am not | 10:56 |
uvos__ | but having the pa route module set the pa output would be good | 10:56 |
uvos__ | (and would work on pp, probubly) | 10:57 |
uvos__ | anyhow | 10:57 |
uvos__ | so any number of moudles can register on any datapipe at the same time | 10:57 |
uvos__ | but sphone will only load one module that provides route | 10:57 |
Wizzup | so I can add a 'post route' that just registers the same data pipe? (and hope it executes after pa?) | 10:57 |
Wizzup | right | 10:57 |
uvos__ | (in the module struct) | 10:57 |
uvos__ | so you just have to name it something else | 10:57 |
uvos__ | like provides: route-mapphone-hack | 10:57 |
uvos__ | or so | 10:58 |
uvos__ | then sphone will happily load both | 10:58 |
Wizzup | ok | 10:59 |
Wizzup | uvos__: does sphone_audio_route_t lack a earpiece mode? | 11:04 |
Wizzup | or is that 'handset' ? | 11:04 |
uvos__ | its handset | 11:07 |
uvos__ | the route is expected to also set the correct mic | 11:07 |
uvos__ | ofc | 11:07 |
uvos__ | so internal mic+earpiece is handset | 11:08 |
uvos__ | btw | 11:09 |
uvos__ | you should at least check the call mode | 11:09 |
uvos__ | and not do anything on _NO_ROUTE modes | 11:09 |
uvos__ | since those would be ip calls etc that work fine with no hacks | 11:09 |
Wizzup | right @ ip calls | 11:19 |
Wizzup | SPHONE_CALL_WATING should that be WAITING? | 11:41 |
Wizzup | in any case I have a module that works atm | 11:41 |
Wizzup | well, -should work- | 11:42 |
Wizzup | the mic in anything but speakerphone is still a problem of course | 11:42 |
Wizzup | uvos__: ok if I push to a work in progress branch @ sphone? | 11:55 |
uvos__ | sure go ahead | 11:57 |
Wizzup | ok | 12:06 |
Wizzup | -Werror not being on has bitten me a few times now :p | 12:21 |
Wizzup | btw: recent contacts takes ~8s or so to load for me | 12:28 |
Wizzup | uvos__: btw, I'm up for trying to boot some android thing to dump registers to figure out what's missing, can it be done from stock or do you need to build your own kernel? (I mean I'd rather not, but I'd like to earpiece to work.) | 12:43 |
Wizzup | ok the pa side will need a bit more work, I'll get it done though | 13:04 |
Wizzup | fwiw the ui has no way to switch to headphones atm | 13:04 |
Wizzup | I suppose the idea is that it would be automatic | 13:04 |
Wizzup | freemangordon: so current conversations with tp works for one account decently, but testing what happens if accounts go offline/online is harder | 13:45 |
Wizzup | freemangordon: I suppose presence-ui is useful for that | 13:45 |
uvos__ | Wizzup: sphone looks up every phone number in recents in eds | 14:17 |
uvos__ | if the phonebook is even vaguely large a single lookup really slow for some reason | 14:17 |
uvos__ | it seams way slower than it should be, but sphone could also be less dumb and only lookup the number once per number it encounters instead of once per entry | 14:18 |
uvos__ | if its overly bothersome you can unload the contacts-evolution module | 14:19 |
uvos__ | (and sacrifice sphone showing contact names) | 14:19 |
uvos__ | or you can optimize it :P | 14:19 |
Wizzup | uvos__: I would think rtcom el has support for this | 17:11 |
uvos__ | sure you could just use the name thats in el, but then it would not follow the name of the contact if its changed or added | 17:23 |
uvos__ | i think sphone uses the name in el as a fallback, or maybe not i dont quite remember if i just wanted to implement that or if i have allready | 17:24 |
Wizzup | I just know the rtcom example has the full names and everything from osso-abook | 17:39 |
norayr | anyone tried if pinephone keyboard works under leste? | 20:55 |
norayr | other, important question: do you bootstrap devuan for each supported architecture? how? can i bootstcap it for armv5 (or what was on nokia n810) | 20:56 |
humpelstilzchen[ | norayr: my keyboard works | 21:00 |
norayr | yay | 21:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!