| uvos | i recommend allways carrying a RTG arround to power your leste device | 00:16 |
|---|---|---|
| maxwelld | > sure I can, but that's not what I want | 00:18 |
| maxwelld | though i really really really love using old devices with modern software, and that's what i myself do, i am afraid i need to understand that we cannot keep using old devices always. | 00:18 |
| maxwelld | leste needs to work well on newer devices. | 00:18 |
| uvos | sure, but afaik the droid 4 and its siblings are still really the most modern devices that have its level the 2 factors i find most important in a linux phone: 1. hardware enablement in the mainline kernel 2. working high quality power management | 00:20 |
| uvos | unfortinatly its a bit hard to keep up with the state of every other deivce, but afaik still nothing matches the mapphones. | 00:21 |
| uvos | also hardware keyboard is nice, but i could maybe do without | 00:22 |
| Wizzup | lol @ RTG | 01:31 |
| Wizzup | I had to look that up | 01:31 |
| sicelo | power mgmt is good on the qualcomm sdm845 devices, and the hardware support is stellar too (due to many people working on it) | 07:02 |
| sicelo | s/people/people and companies (such as linaro)/ | 07:02 |
| freemangordon | uvos: could you remind me which patches you want me to review? | 07:52 |
| uvos | freemangordon: https://github.com/maemo-leste/hildon-desktop/pull/22 | 10:59 |
| uvos | https://github.com/maemo-leste/libhildonmime/pull/5 | 10:59 |
| uvos | https://github.com/maemo-leste/osso-xterm/pull/4 | 10:59 |
| uvos | https://github.com/maemo-leste/osso-abook/pull/2https://github.com/maemo-leste/osso-abook/pull/2 | 11:00 |
| uvos | *https://github.com/maemo-leste/osso-abook/pull/2 | 11:00 |
| Wizzup | uvos: if I retry with this third e960 that I have, and somehow make sure I safely remove the clips, I will still need some kind of hotglue or otherwise to make this work sensibly, right? I can't just tape around it a bit. | 11:09 |
| uvos | the bms? | 11:09 |
| uvos | to hold it against the battery? | 11:10 |
| uvos | you want to use some well speced tape | 11:10 |
| uvos | kapton tape is the mehtod of choice | 11:10 |
| uvos | wrap the bms with kaption, then tape around the end of the battery to keep the bms in | 11:10 |
| Wizzup | bms is the pcb? | 11:11 |
| uvos | yes | 11:11 |
| Wizzup | ok | 11:11 |
| Wizzup | I think I should just do this in a few weeks when I get back and suffer through the weakest battery for a while longer :) | 11:12 |
| Wizzup | at least I have a bionic with a factory extended battery | 11:12 |
| uvos | above the final kapton tape you can use some firber reenforced tape for some regiditiy | 11:12 |
| uvos | thats how the stackup is in a comertial battery | 11:12 |
| Wizzup | ok | 11:12 |
| uvos | for some reason (well different chemistry) the bionic extended batteries have survieved mutch better than eb41/hw4x | 11:29 |
| uvos | mine has almost rated capacity | 11:29 |
| tmlind | uvos: i recall bionic batteries eeprom limits max charge voltage to 4.2 so that explains | 11:32 |
| tmlind | narrowed down the tc358765 myster register bit enabling lcd output last night btw, bit 5 for VPCTRL must be set for tc358765 while tc358775 only supports video event mode and bit 5 is reserved | 11:36 |
| uvos | thats true but not the reason really, the bionic extended battery is a standard li-nmc afair, while the eb41/hw4x is a hvlipo. The cathode alloying materials to increase the galvanic potential generally have mutch poorer lifespan, regarless of how you charge them | 11:44 |
| uvos | this is why also the new old stock eb41 battiers that have never been charged are so degraded | 11:44 |
| tmlind | uvos: ok, maybe also check the android cpcap charger voltage reg values between hw4x and extended battery just in case :) we know for sure that eb41 with android always connected to a charger will only last some months | 11:46 |
| uvos | its reduced | 11:46 |
| uvos | the charge enpoint voltage for bw8x (bionic extended) is 4.2 you can check with a dmm | 11:47 |
| uvos | so the cpcap regs are clearly also set correctly by android here | 11:47 |
| tmlind | ok | 11:47 |
| tmlind | android charged eb41 at 4.35 or whatever the voltage was | 11:47 |
| uvos | yes | 11:47 |
| uvos | again this battery has a different cathod material | 11:48 |
| uvos | so this is "ok" | 11:48 |
| uvos | but they have poor lifespan in genreal | 11:48 |
| uvos | *general | 11:48 |
| tmlind | it's not ok for a usable lifespan, it will bloat after a few months if left connected :) | 11:48 |
| tmlind | no idea how much short higher voltages wear it down though as discussed numerous times earlier | 11:49 |
| uvos | not mutch, the main thing that wares it down is just calendaric ageing, something those hvlipos are terrible at | 11:50 |
| uvos | anyhow unfortinatly any new phone battery you buy now will also be hvlipo for the most part | 11:50 |
| uvos | idealy soldered and glued into the deive | 11:51 |
| tmlind | somebody would have to run a test on a pile of batteries before i'd switch to higher charge voltages | 11:51 |
| uvos | yay obsolescence :P | 11:51 |
| tmlind | obsolete but still usable :) | 11:52 |
| * tmlind bbl | 11:52 | |
| uvos | tmlind: ttyl | 11:57 |
| uvos | really excited about mz617 support :) | 11:58 |
| Wizzup | yes yes :) | 12:31 |
| Wizzup | uvos: iirc the eu is forcing batteries to be replacable | 12:32 |
| maxwelld | will mz617 be able to show youtube videos in more than 144p? (: | 12:39 |
| Wizzup | I am never sure if these smileys are passive aggressive or not :D | 12:42 |
| Wizzup | but yeah, I'm sure it'll be able to play yt-dlp'd videos at native res | 12:42 |
| maxwelld | oh oh oh. | 12:42 |
| maxwelld | thank you for saying that. | 12:43 |
| maxwelld | with the smile i mean don't take it critically. | 12:43 |
| maxwelld | i would like to have a maemo tablet, if it is able to show online videos - that would be its main function. | 12:43 |
| Wizzup | yeah, we all want it :D | 12:45 |
| Wizzup | I have a bunch of mz617's to send to people too for dev | 12:45 |
| maxwelld | good. | 12:45 |
| uvos | d4 can bearly do 480p | 12:55 |
| uvos | so mz617 wille be able to do that too | 12:55 |
| uvos | (sw decodeing, with hardware presentation) | 12:55 |
| uvos | we cant do hw decodeing on omap4 atm | 12:55 |
| Wizzup | if I know ahead of time I just convert it to the right res with ffmpeg | 12:55 |
| uvos | but all the code is availble for this | 12:55 |
| uvos | as is the required propriatary firmware | 12:56 |
| uvos | but its going to be a pain to use as they never supported a real api like vaapi | 12:56 |
| uvos | but only some propriatary ti crap that no one uses | 12:56 |
| Wizzup | yeah, it's not important atm imo | 12:56 |
| uvos | would be nice to use the fsp | 12:57 |
| uvos | *dsp | 12:57 |
| uvos | another funn thing to do, that i will probubly never come around to is to use one of the the cortex m4 procs for various tasks | 12:57 |
| uvos | they can access almost anything the cortex a9 can | 12:58 |
| uvos | so you could have one decode mp3s and send the audio to cpcap for essentaly zero power usage audio playback | 12:58 |
| uvos | stuff like that | 12:58 |
| Wizzup | yeah | 13:50 |
| tmlind | heh i remember the 100 hour mp3 playback spec.. | 14:17 |
| freemangordon | uvos: why do we nned that https://github.com/maemo-leste/libhildonmime/pull/5/commits/ee26b3c71d8da584fc4c1f5a65f902655e8d5730 ? I mean - it will fallback to xdg-open without anyways, no? | 16:09 |
| freemangordon | *need | 16:09 |
| uvos | freemangordon: i use it in a later pr | 16:17 |
| uvos | but mainly its just compleating the api | 16:17 |
| uvos | as noted by the commit message, an application can choose any osso service | 16:17 |
| uvos | but it cant choose xdg | 16:17 |
| freemangordon | yes, I saw that later PR | 16:17 |
| freemangordon | but just don;t see what we gain if explicitly requesting xdg-open | 16:17 |
| uvos | so in the case that we have any number osso serivces and a xdg action the client cant choose the xdg one but can choose any of the osso services | 16:18 |
| uvos | freemangordon: in this specific case, abook itself registers as a osso service to handle tel:// | 16:18 |
| freemangordon | ahaaa | 16:18 |
| uvos | freemangordon: we must ofc avoid abook simply calling itself here | 16:19 |
| freemangordon | now I see | 16:19 |
| freemangordon | so, this is just a workaround | 16:19 |
| uvos | well the use - sortof | 16:19 |
| uvos | the the pr itself is just compleating the api really | 16:19 |
| uvos | but let my justify why this is fine: | 16:20 |
| freemangordon | ok, so we expect maemo phone app to either register in TP on with xdg | 16:20 |
| freemangordon | *or with | 16:20 |
| uvos | in abook this is a fallback path anyhow, any osso aligned dialer is going to be using tp | 16:20 |
| uvos | any non osso aligned dialer is not going to use a osso serivce | 16:20 |
| uvos | so its either tp or xdg-open anyhow | 16:20 |
| freemangordon | I understand that | 16:21 |
| freemangordon | it is just that the implementation looks hacky to me :) . gimme some time to chew it. | 16:21 |
| uvos | i gues what would be even better would be the ability for abook to tell hildonmime: dont use this action to handle this request | 16:22 |
| freemangordon | mhm | 16:22 |
| freemangordon | I was thinking about that | 16:22 |
| uvos | atm the api only allows the oposit: use this action to hanlde this request | 16:22 |
| uvos | anyhow imo https://github.com/maemo-leste/libhildonmime/pull/5/commits/ee26b3c71d8da584fc4c1f5a65f902655e8d5730 is requried regardless | 16:22 |
| uvos | the api should allow the caller to specify it wants xgd | 16:23 |
| freemangordon | well, the caller should not care about the method | 16:29 |
| uvos | well then you might as well remove the whole HildonURIAction parameter | 16:30 |
| freemangordon | uvos: not really | 16:31 |
| freemangordon | also, I think osso-abook can achieve the same without requesting xdg-only opening | 16:32 |
| freemangordon | there is already hildon_uri_get_actions_by_uri() | 16:32 |
| uvos | sure and we should extend that to also return a xdg HildonURIAction when thats whats available | 16:33 |
| uvos | but either keep the parameter as is and merge the pr to allow the HildonURIAction parameter to url_open also specify xdg-open, or remove the callers ability to specify what it wants in url_open | 16:33 |
| uvos | anything else makes no sense | 16:33 |
| uvos | really | 16:33 |
| freemangordon | ok, gimme some time to see if I can come up with a better API | 16:35 |
| freemangordon | uvos: ok, I will merge that PR, but osso-abook should simply call libhildonmime to open the uri without requesting xdg method. I am tempted to introduce hildon_uri_open_filtered() and call it a day | 16:43 |
| freemangordon | also, unless I am missing something, if there is no xdg dialer, osso-abook will call itself with the current code, no? | 16:46 |
| uvos | yes, thats slightly jarring, but harmless, it just moves to the contact again | 16:51 |
| uvos | hildon_uri_open_filtered would be a fine option too | 16:52 |
| freemangordon | well, what I am saying is that osso-abook should somehow tell libhildonmime to not call it. thus hildon_uri_open_filtered() | 16:53 |
| freemangordon | mhm | 16:53 |
| freemangordon | uvos: hmm you should not try uri_xdg_open() twice | 16:56 |
| uvos | i dont, | 16:56 |
| uvos | where do i? | 16:56 |
| uvos | if xdg-open is specified fails, and osso-serivce also fails then i gues it tires it twice | 16:57 |
| uvos | not a big deal or? | 16:57 |
| uvos | doing anything else would make the code more complex i think | 16:58 |
| freemangordon | just add some bool | 16:58 |
| freemangordon | not a biggie, but buggy :) | 16:58 |
| uvos | sure i can add that if you want | 16:59 |
| freemangordon | also, the comment here is misleading https://github.com/maemo-leste/libhildonmime/pull/5/commits/ee26b3c71d8da584fc4c1f5a65f902655e8d5730#diff-7463e73a36f095b4fbd13fafbfc2283ebdfe0bfef19ea8c9c44a5da945c806f9R66 | 16:59 |
| freemangordon | because it sound like DBUS is not attempted | 16:59 |
| freemangordon | which is not true | 16:59 |
| uvos | should be prefered i gues | 16:59 |
| uvos | "should be prefered" i gues | 16:59 |
| freemangordon | yes, or "tried first" | 16:59 |
| freemangordon | please fix those 2 and I'll merge | 17:00 |
| freemangordon | hmm | 17:01 |
| freemangordon | actually... | 17:01 |
| freemangordon | do we want DBUS at all in case of HILDON_URI_ACTION_XDG? | 17:01 |
| uvos | well if no xdg handler can be found better to have something handle it instead of dropping it (usually silently) | 17:02 |
| uvos | or? | 17:02 |
| freemangordon | Return: %TRUE if successfull or %FALSE. | 17:03 |
| uvos | sure | 17:03 |
| freemangordon | maybe let the application handle that | 17:03 |
| freemangordon | like, what to do if XDG fails | 17:03 |
| freemangordon | dunno... | 17:03 |
| uvos | donno either | 17:03 |
| uvos | so one think i was thinking here | 17:04 |
| uvos | is that later we can have the default for etach mime also be "xdg" as a special value | 17:04 |
| uvos | so it sets this | 17:04 |
| uvos | and then tries xdg first | 17:04 |
| uvos | but ofc in this case it must fall back to whatever is avaialble if xdg cant serve | 17:04 |
| freemangordon | Ah, I see | 17:04 |
| freemangordon | ok, lets leave it as it is then | 17:05 |
| freemangordon | just fix those 2 issues | 17:05 |
| freemangordon | and I'll try to come up with fix for osso-abook, maybe implementing hildon_uri_open_filtered() | 17:06 |
| uvos | ok | 17:11 |
| freemangordon | uvos: sorry, wait, don't waste time. I'll touch libhildonmime anyways, will fix those | 17:28 |
| uvos | too late | 17:29 |
| uvos | i just updated the pr | 17:29 |
| freemangordon | oh, I just merged :) | 17:29 |
| uvos | oh no | 17:30 |
| uvos | what version did you get :P | 17:30 |
| freemangordon | lemme pull | 17:30 |
| freemangordon | the old one :( | 17:31 |
| freemangordon | sec | 17:31 |
| uvos | eh just git reset and merge my fork | 17:32 |
| freemangordon | right | 17:32 |
| freemangordon | uvos: ugh, why did you delete gtk-doc.make? | 17:34 |
| uvos | ah crap, dpkg-buildpackge dose that on eatch compile | 17:35 |
| freemangordon | ok, I'll fix the original PR | 17:36 |
| uvos | ok | 17:36 |
| freemangordon | don;t waste any more time on that | 17:36 |
| uvos | o | 17:36 |
| uvos | k | 17:36 |
| uvos | note the original pr had an additional issue i fixed | 17:36 |
| freemangordon | what it is? | 17:36 |
| uvos | https://github.com/IMbackK/libhildonmime/blob/d0616faf627009049bbb2c050535dee4899b70c5/libhildonmime/hildon-uri.c#L2409 | 17:37 |
| uvos | this goto was missing | 17:37 |
| uvos | causing a unnessecary warning here https://github.com/IMbackK/libhildonmime/blob/d0616faf627009049bbb2c050535dee4899b70c5/libhildonmime/hildon-uri.c#L2417 | 17:37 |
| uvos | when a osso-service was not found but xdg-open was able to hanlde the request | 17:38 |
| freemangordon | ok | 17:39 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!