| rafael2k | I'll debian dir directly from debian: https://salsa.debian.org/debian/crust-firmware | 00:00 |
|---|---|---|
| norayr | sicelo, Wizzup: it is much more useful than shazam. shazam doesn't work in background. you never know when shazam listens to your talks, and when not. | 01:39 |
| norayr | songrec on the contrary has a key to disable microphone | 01:40 |
| norayr | also has a check box to detect what is played from the phone's speaker. | 01:40 |
| sicelo | yes, i can see it's foss. i just wish to know how it talks to shazam servers - does apple explicitly provide an api, or this depends on undocumented behavior, which Apple could change anytime? ... the readme only explains how fingerprinting works | 02:14 |
| norayr | i guess it was written somewhere that there is an api. | 02:15 |
| norayr | and it can continiously recognize melodies. | 02:30 |
| norayr | you just leave it and then you have a list of songs. | 02:30 |
| norayr | and you can export it as csv. | 02:30 |
| norayr | (: | 02:30 |
| norayr | also the interface is reflowable, you use landscape mode, the bottom part comes to the right part | 02:31 |
| norayr | of the screen. | 02:31 |
| norayr | i guess it is some feature of gtk4, and we maybe don't have gtk4 in chimaera and that software may not have gtk3 source so i may not be able to package it. | 02:31 |
| norayr | also it is in flathub, i found it there. | 02:32 |
| norayr | and installed on pmos on pinephone. | 02:32 |
| norayr | it is very useful. | 02:32 |
| norayr | but i don't like flatpak's i like packages. | 02:32 |
| norayr | and even more i like gentoo ebuilds. (: | 02:32 |
| dsc_ | I forgot how to show the battery percentage | 08:05 |
| dsc_ | whats the command (or program) to see battery status? | 08:05 |
| sicelo | what kind of output does the command you want produce? | 12:55 |
| Wizzup | rafael2k: will do in a bit | 12:55 |
| sicelo | there's, of course, cat /sys/class/power_supply/battery/uevent | 12:55 |
| sicelo | and upower -d | 12:55 |
| Wizzup | rafael2k: in any case just to be clear, for crust to work, years ago, we had to pull in newer uboot | 12:55 |
| Wizzup | rafael2k: that's what I mentioned | 12:55 |
| Wizzup | freemangordon: btw looks like this is the maemo-launcher equivalent of sailfish: https://github.com/sailfishos/mapplauncherd | 13:10 |
| Wizzup | they have some qt5 booster | 13:11 |
| freemangordon | where? | 13:12 |
| rafael2k | Wizzup: no problem, we can update u-boot. tks! | 13:12 |
| Wizzup | freemangordon: https://github.com/sailfishos/mapplauncherd-qt/ | 13:13 |
| Wizzup | https://github.com/sailfishos/mapplauncherd-booster-qtcomponents | 13:13 |
| Wizzup | looks like they archived it now | 13:13 |
| rafael2k | so, we already have crust... | 13:16 |
| Wizzup | sicelo: in upstream-forks ? | 13:17 |
| Wizzup | brb 10 mins | 13:17 |
| rafael2k | : ) | 13:21 |
| sicelo | i think you meant to hilight rafael2k | 13:25 |
| norayr | uvos is not here. i want to tell him, i guess i need to tell him specifically that the volume up key on pp doesn't trigger the keyboard as it was before. | 13:31 |
| norayr | search key on droid triggers. | 13:31 |
| norayr | rafael2k: thank you for your work. i am waiting impatiently for the piggz camera on maemo. do you think you can package it? | 13:32 |
| norayr | once i built megapixels-legacy, now megapixels probably uses gtk4, which we probably don't have in chimaera, not sure. if gtk3, maybe we can build it. i like megapixels actually because i can customize it with my luts. | 13:33 |
| norayr | dsc_ i guess you are searching for upower -d | 13:33 |
| norayr | or you can just go to /sys/class/power and somewhere there you'll find some 'bat' files that contain the percentage. | 13:34 |
| buZz | its in /sys/class/power_supply/battery/capacity | 13:35 |
| buZz | but -only- if previously hit 100% since boot | 13:35 |
| buZz | thats such a drag imho | 13:35 |
| buZz | i generally just look at /sys/class/power_supply/battery/uevent , as its got voltage and discharge current too | 13:36 |
| Wizzup | rafael2k: so do you need me to package crust-firmware ? | 13:41 |
| Wizzup | rafael2k: sorry, do you need me to make a repo for you and add it to ci and such? | 13:41 |
| dsc_ | norayr: ty | 13:54 |
| dsc_ | & buZz | 13:54 |
| buZz | upower -d only updates once every 120 seconds :( | 13:55 |
| Wizzup | buZz: that is perfect for power management | 13:55 |
| buZz | right | 13:55 |
| Wizzup | you definitely would not want it any faster | 13:55 |
| Wizzup | it will be faster when on wall charger though I believe | 13:55 |
| buZz | but do you want to wait 2 minutes to see if charger is connected and charging? :D | 13:55 |
| buZz | it wont, its always 120 seconsd | 13:56 |
| norayr | dsc_, - https://github.com/norayr/home_sweet_home/blob/master/scripts/pinebook_pro/bat.sh - this is how i was getting information from pinebook. | 13:56 |
| norayr | when upower was not able to retrieve it. | 13:56 |
| buZz | yaeh its a shame the names of devices in /class/power_supply arent standardized :( | 13:56 |
| Wizzup | buZz: that is not how this works | 13:56 |
| norayr | but you need to find own files in /sys/class/power_supply | 13:57 |
| Wizzup | buZz: charger connection is a udev event in the kernel which triggers all kinds of things | 13:57 |
| Wizzup | buZz: so it won't detect that 120s later | 13:57 |
| buZz | upower -d wont? | 13:57 |
| Wizzup | it will see it -immediately- | 13:57 |
| Wizzup | well, it does on my upower. | 13:57 |
| Wizzup | the status applet which detects charging uses only upower for its info | 13:57 |
| Wizzup | iirc... | 13:57 |
| buZz | ah yeah, i ment the /org/freedesktop/UPower/devices/battery_battery | 13:58 |
| buZz | (lol @ name) | 13:58 |
| buZz | the /DisplayDevice likely updates more often then? | 13:58 |
| buZz | and /line_power_usb | 13:59 |
| buZz | -line- ? :D | 13:59 |
| Wizzup | I don't remember this exactly, there are upower docs online for this | 13:59 |
| Wizzup | but our status applet has clear code on how to read the battery on all suppported devices | 13:59 |
| Wizzup | https://github.com/maemo-leste/status-area-applet-battery/blob/master/batmon.c | 14:00 |
| buZz | why not access upower through dbus? | 14:02 |
| Wizzup | upower is only accessible through dbus | 14:03 |
| buZz | ah, is that gio.h ? | 14:04 |
| buZz | aha > Gio is a library providing useful classes for general purpose I/O, networking, IPC, settings, and other high level application functionality | 14:04 |
| Wizzup | buZz: no, there is a upower.h include there | 14:09 |
| buZz | isnt that only for the constants? | 14:09 |
| Wizzup | no | 14:10 |
| Wizzup | up_client_get_devices2 etc | 14:10 |
| buZz | oh up_client_get_devices2() | 14:10 |
| buZz | lol @ 2 | 14:10 |
| buZz | :D | 14:10 |
| buZz | and then with the device use g_ptr_array_index , which is gio.h i think? | 14:11 |
| Wizzup | that's what people do when they change the api :) | 14:11 |
| buZz | :P | 14:11 |
| buZz | current version of my batterymonitor is getting nice ; http://space.nurdspace.nl/~buzz/maemo/2023-01-13-044313_960x540_scrot.png | 14:17 |
| buZz | the purple is 'remainder of USB current' which is powering the phone during charging | 14:18 |
| buZz | red is discharge, green is charge | 14:18 |
| buZz | background green is batt voltage | 14:18 |
| buZz | (not using any historic data btw, just realtime) | 14:19 |
| buZz | i think the purple one is 'always higher than red' because of the voltage differences | 14:23 |
| buZz | i'm not really sure why 'USB voltage' is below 5V in class/power_supply/usb/uevent | 14:23 |
| buZz | but maybe the current needs to be calculated to match the battery voltage, or something | 14:24 |
| Wizzup | cool! | 14:32 |
| buZz | still need to figure out why its using >5% cpu while not updating | 14:32 |
| buZz | or why pyqtchart's 'sized to window' chart extends above Y=0 | 14:33 |
| buZz | :D | 14:33 |
| sicelo | because you're polling, maybe? | 14:33 |
| buZz | its not polling when not updating | 14:42 |
| buZz | maybe its running some eventloop thats not mine, normally these charts also allow panning/zooming, i disabled that but maybe the loop for it is still active | 14:43 |
| Wizzup | uvos: ping | 14:55 |
| uvos | Wizzup: yeah? | 19:12 |
| uvos | "1673712315 <norayr> i think forcing the vkb to appear by volume up is broken on pp." | 19:13 |
| uvos | yeah i know, but it works on mapphones and on vm so idk someone else who has a pp needs to debug this one | 19:13 |
| uvos | either h-d isent getting it here https://github.com/maemo-leste/hildon-desktop/blob/master/src/util/hd-shortcuts.c | 19:14 |
| uvos | or the shortcut is not configured for some reason | 19:15 |
| Wizzup | uvos: hi | 19:15 |
| Wizzup | I just packaged https://github.com/sailfishos/voicecall - which is a background daemon to interface with ofono and telepathy | 19:15 |
| Wizzup | I tested it, and it works for sip via telepathy | 19:15 |
| uvos | or the dbus singal isent reaching him here https://github.com/maemo-leste/hildon-input-method/blob/33cc6ec1cfe5a6a5c5c576edee586a5082befba4/src/hildon-im-main.c#L102 | 19:15 |
| uvos | so someone has to break in these locations/ watch dbus on pp | 19:16 |
| Wizzup | so my plan right now is to make a sphone module to interface with it | 19:16 |
| Wizzup | but I don't think sphone right now supports a notion of 'accounts' | 19:16 |
| Wizzup | we can have several sip accounts, for example | 19:16 |
| uvos | it dose not | 19:16 |
| Wizzup | the voicecall thing is kinda neat, it also does dtmf | 19:16 |
| uvos | you could register a backend for eatch accont, sphone dosent care what backend really means | 19:16 |
| uvos | so dose ofono btw | 19:16 |
| uvos | but it dosent work | 19:17 |
| uvos | on mapphones | 19:17 |
| Wizzup | well, they would be registered at runtime | 19:17 |
| Wizzup | well sip can do dtmf as well | 19:17 |
| uvos | yes | 19:17 |
| uvos | sphoen dosent care when a backend is registered | 19:17 |
| Wizzup | in any case that's my current plan | 19:17 |
| uvos | it will just add it to the dropdown | 19:17 |
| uvos | so sip - accountName | 19:17 |
| Wizzup | I was looking into using their code, but it seems well done enough that I don't really want to re-do it | 19:17 |
| uvos | is a valid thing to add to the dropdown | 19:17 |
| Wizzup | ok | 19:17 |
| uvos | by just calling for a new backend | 19:17 |
| Wizzup | can I also remove them at runtime? | 19:17 |
| uvos | yes | 19:17 |
| Wizzup | ok | 19:17 |
| uvos | rn it wont update the dropdown untill you respawn the dialer window | 19:18 |
| uvos | but thas a trivial fix | 19:18 |
| uvos | otherwise should work fine | 19:18 |
| rafael2k | Wizzup: no need for crust firmware - we already have it - suspend is working great! | 19:21 |
| rafael2k | norayr: piggz camera is does not support libcamera... he is working on it | 19:22 |
| Wizzup | rafael2k: ok, so maybe we need some way that when people lock the device that it suspends | 19:23 |
| Wizzup | uvos: ok, any way, that's the current plan | 19:23 |
| uvos | Wizzup: ok | 19:23 |
| Wizzup | I need to untangle some of their code, but it seems to work already | 19:23 |
| rafael2k | norayr: Megapixels gtk3 is here: https://github.com/rafael2k/megapixels/tree/gtk3 it compiles without problem, but it is way too old | 19:23 |
| Wizzup | it also has some mce and audio code, but I don't plan to sue it currently | 19:23 |
| uvos | so registering "backends" dynamicly is imo fine | 19:23 |
| uvos | but you can ofc also come up with some better sheme | 19:23 |
| Wizzup | for now I just want to be able to dial and answer :D | 19:24 |
| uvos | /explicit support for muliple accounds per backend | 19:24 |
| Wizzup | once that works such a refactor is doable | 19:24 |
| rafael2k | Wizzup: yes, just call suspend from somewhere when the screen gets locked | 19:24 |
| uvos | Wizzup: its not really mutch of a refactor | 19:24 |
| Wizzup | rafael2k: so how would this work if for example music is playing? | 19:24 |
| Wizzup | uvos: I mean refactor the voicecall module | 19:24 |
| uvos | in the just add some list account structs to the backend descriptor | 19:24 |
| rafael2k | Wizzup: we need to treat all the cases... suspend shuts down the ARM cpu | 19:25 |
| uvos | *some list of account structs | 19:25 |
| uvos | and then have the dialer display another dropdown if there is more than one | 19:25 |
| uvos | Wizzup: ok | 19:25 |
| Wizzup | rafael2k: sorry, what do you mean exactly with all the cases? | 19:25 |
| uvos | Wizzup: rafael2k: so suspend | 19:25 |
| uvos | mce module, ez | 19:26 |
| rafael2k | Wizzup: if we don't want to suspend when playing a music... for example, we need to explicit add "exceptions" or whatever we call it | 19:26 |
| uvos | and tiny settings applet to set if it shal suspend on lock | 19:26 |
| rafael2k | uvos yes! | 19:26 |
| uvos | rafael2k: would keep it simple first | 19:26 |
| rafael2k | I totally agree | 19:26 |
| uvos | rafael2k: but mce could listen on pa if there is something playing | 19:26 |
| Wizzup | rafael2k: and we need a system for things to register this, wakelocks or whatever android calls it | 19:27 |
| Wizzup | https://developer.android.com/training/scheduling/wakelock | 19:27 |
| Wizzup | maybe android does not use it anymore | 19:28 |
| uvos | it dose | 19:28 |
| uvos | but its use is strongly discouraged | 19:28 |
| uvos | what there being no wakelock means on devices vaies | 19:29 |
| uvos | some will suspend, on others (like d4) nothing special happens | 19:29 |
| rafael2k | Wizzup: we can also set which wakeup-devices we wanna use, I always use this page as reference: https://xnux.eu/devices/feature/system-suspend-a64.html | 19:29 |
| rafael2k | s/wakeup-devices/wakeup-triggers | 19:30 |
| rafael2k | we can wakeup on alarmtimer* | 19:31 |
| rafael2k | which will be nice to use at some for the alarm clock | 19:32 |
| rafael2k | this SCP processor which keeps running the ARM CPU is halted is pretty interesting indeed | 19:33 |
| Wizzup | rafael2k: what I mean is preventing sleep when say mpv is playing | 19:34 |
| Wizzup | or when a file is downloading | 19:35 |
| rafael2k | we can definitely do "wake locks" by using the alarmtimer wakeup device and "waking up" the device, for example, to check for new incoming messages (from internet) for eg | 19:35 |
| Wizzup | and yes we also need to set up what wakes it up | 19:35 |
| Wizzup | rafael2k: wake locks keep the device awake no matter what iiuc | 19:35 |
| rafael2k | ah, ok | 19:35 |
| rafael2k | this is easy to implement | 19:35 |
| rafael2k | it should be just a flag to mce as far as I understand | 19:35 |
| uvos | sure | 19:36 |
| uvos | imo just add a dbus if to flag mce awake | 19:37 |
| uvos | and a tiny wrapper script | 19:37 |
| Wizzup | there is also the actual kernel wake locks in mainline afaik | 19:37 |
| uvos | that the user can then put infront of relevant applications | 19:37 |
| rafael2k | I like this | 19:38 |
| Wizzup | maybe we can have an issue with a writeup | 19:40 |
| Wizzup | in any case just suspending on lock or screen off won't work well, as you can lock during calls even | 19:40 |
| freemangordon | ве алреадъ хаже либплаъбацк | 19:40 |
| freemangordon | oops | 19:40 |
| freemangordon | we already have libplayback | 19:40 |
| freemangordon | which does exactly what you're discussing | 19:41 |
| freemangordon | and not only | 19:41 |
| freemangordon | https://github.com/maemo-leste/libplayback | 19:41 |
| rafael2k | правда! | 19:42 |
| rafael2k | : ) | 19:42 |
| freemangordon | hehe | 19:42 |
| rafael2k | :P | 19:42 |
| rafael2k | any software already using libplayback? | 19:45 |
| uvos | libplayback is not really relevant here | 19:49 |
| rafael2k | added more using libcamera "cam" to capture to DNG: https://leste.maemo.org/PinePhone#How_to_take_a_picture | 19:49 |
| bencoh | neat | 19:56 |
| bencoh | rafael2k: ufraw might be a nice addition to the list btw | 19:56 |
| bencoh | in case you want an alternative to dcraw/qcam | 19:57 |
| rafael2k | bencoh: did not know it. cool! | 20:01 |
| rafael2k | I'm annoyed that Megapixel sets some white-balance related registers so the image looks fine, and I'm capturing I get greenish pictures clearly with no white-balance setting | 20:02 |
| rafael2k | btw, I'm using latest 5.15 kernel in the PP, as the new 6.1 in Chimaera I still did not manage to finalize the patchset for the cameras | 20:03 |
| rafael2k | dummy question: gcc `pkg-config --libs gconf-2.0 hildon-1 gtk+-2.0 libosso gdk-2.0 gconf-2.0 glib-2.0` -lm | 20:03 |
| rafael2k | is this enough to link a simple hildon app? | 20:03 |
| Wizzup | looks like source files or object files are missing | 20:04 |
| Wizzup | but maybe that was not the question :D | 20:04 |
| rafael2k | I'm getting unresolved symbols... undefined reference to `gtk_init_check' | 20:04 |
| rafael2k | undefined reference to `hildon_program_get_instance' ... | 20:04 |
| rafael2k | no no | 20:04 |
| rafael2k | I just omitted it | 20:04 |
| Wizzup | it matters where you put the libs | 20:04 |
| Wizzup | what is the whole command? | 20:04 |
| rafael2k | just for fun: https://github.com/rafael2k/maemo-suspend | 20:05 |
| bencoh | right, the linker is order-sensitive | 20:06 |
| bencoh | and the default linking search order changed over time, to make it easy :] | 20:06 |
| rafael2k | ehehehe | 20:06 |
| rafael2k | which app should I look for a working reference? | 20:07 |
| bencoh | hmm, any hildon app from the maemo repositories I'd say | 20:07 |
| rafael2k | ok | 20:07 |
| bencoh | maybe we should add a suspend button to the powerkey menu btw :) | 20:07 |
| rafael2k | where is the source of this? | 20:08 |
| rafael2k | indeed | 20:09 |
| Wizzup | the powerkey menu? | 20:09 |
| Wizzup | https://github.com/maemo-leste/osso-systemui-powerkeymenu/ | 20:10 |
| rafael2k | yes | 20:10 |
| rafael2k | my single button suspend app worked, tks | 20:23 |
| rafael2k | : ) | 20:23 |
| freemangordon | rafael2k: you can add a dbus call to power key menu | 21:18 |
| freemangordon | no need for a separate application, assuming there is already some daemon that can suspend the device | 21:19 |
| rafael2k | freemangordon: agreed indeed! | 21:19 |
| rafael2k | lets see if it is all ready in mce first | 21:19 |
| freemangordon | I doubt | 21:20 |
| freemangordon | maybe upower? | 21:20 |
| rafael2k | ehehehe | 21:20 |
| rafael2k | that is why I just wrote this stuff, until we have it properly done | 21:20 |
| rafael2k | dont think we need upower daemon, could be implemented just in mce afaiu | 21:21 |
| freemangordon | we already have upower and mce uses it :) | 21:22 |
| rafael2k | need to go, time for multiki with the baby | 21:22 |
| freemangordon | anyway, my point was that maybe upower already implements dbus interface that can be used to suspend the device | 21:22 |
| rafael2k | : ) | 21:22 |
| freemangordon | :) | 21:22 |
| rafael2k | I'll take a look in upower tomorrow! | 21:23 |
| Wizzup | freemangordon: nah upower doesn't do that | 21:23 |
| Wizzup | logind might | 21:23 |
| freemangordon | ok | 21:25 |
| freemangordon | FYI https://github.com/maemo-leste/osso-systemui-powerkeymenu/blob/master/systemui.xml | 21:26 |
| sicelo | `dbus-send --system --type=method_call --print-reply --dest=com.nokia.mce "/com/nokia/mce/request" com.nokia.mce.request.req_shutdown` no idea if this does work in leste, but i guess it should | 22:25 |
| sicelo | ah, suspend ... :p | 22:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
