| Wizzup | crimes against maemanity | 00:01 |
|---|---|---|
| Wizzup | freemangordon: nice job on the him fixes, ty | 00:14 |
| Wizzup | we should build it tomorrow for stable | 00:15 |
| Wizzup | uvos: do you have some charge mode screenshots or videos, or shall I try to make some photo? | 00:47 |
| Wizzup | rafael2k: lmk when the pr is ready :p | 00:47 |
| Wizzup | going to sleep soon | 00:48 |
| rafael2k | Wizzup: ok! | 05:03 |
| rafael2k | kernel compilation still going... I'd like to test before doing the PR | 05:04 |
| rafael2k | but both git repos are ready (mobian-5.15 mirror and pine64-kernel fork) | 05:11 |
| rafael2k | btw, should I remove debian dir in mobian-5.15 like I did first time, or can I keep it? | 05:12 |
| rafael2k | this you can already fetch: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 | 05:37 |
| rafael2k | (to https://github.com/maemo-leste/pine64-kernel/tree/mobian-5.15) | 05:38 |
| rafael2k | I did not delete mobian debian/ dir from upstream, lemme know if you prefer that I delete it | 05:39 |
| lel | rafael2k opened a pull request: https://github.com/maemo-leste/pine64-kernel/pull/3 (New PP kernel release, with important keyboard patches) | 07:32 |
| rafael2k | Wizzup: done (just please rebase mobian-5.15 to latest update https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 before compiling ) | 07:35 |
| sicelo | freemangordon, Wizzup - so it seems ofono has complete support for emergency calling, in various scenarios, including sim not present - https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/emergency-call-handling.txt | 08:36 |
| freemangordon | sicelo: I am missing the context | 08:38 |
| sicelo | none specifically. i just recall the issue of emergency calls has come up here a couple of times | 08:39 |
| freemangordon | yeah | 08:55 |
| rafael2k | /etc/pulse/default.pa -> set "set-default-sink 1 | 08:58 |
| rafael2k | " | 08:58 |
| rafael2k | to get audio output in pp with the correct output | 08:58 |
| rafael2k | Wizzup: if you end up finding a way to have our pulse audio custom configs... apart of "load-module module-switch-on-port-available" in system.pa, it would be nice to have this "set-default-sink 1" in default.pa | 09:01 |
| rafael2k | and as far as I can check with v4l tools, /dev/media0 is the video decoder hardware, and /dev/media1 is the camera, which all seem to work | 09:19 |
| humpelstilzchen[ | But can you get a picture out of it? https://wiki.postmarketos.org/wiki/PINE64_Don%27t_be_evil_devkit_(pine64-dontbeevil)#Cameras | 09:26 |
| rafael2k | humpelstilzchen[: yes!! | 09:28 |
| rafael2k | just managed to take my first picture in maemo! | 09:28 |
| rafael2k | : ) | 09:28 |
| humpelstilzchen[ | interesting, I could not | 09:28 |
| rafael2k | nothing different in kernel - it all works out-of-the-box (just the auto-focus functionality needs the firmware blob) | 09:29 |
| rafael2k | [ 6933.582634] ov5640 3-004c: firmware upload success | 09:30 |
| rafael2k | we need this in our repo too: ov5640_af.bin | 09:30 |
| rafael2k | what did you use? | 09:30 |
| rafael2k | I used megapixels in a mobian chroot'ed env | 09:31 |
| rafael2k | just to test if kernel is ok, and indeed, it is | 09:32 |
| rafael2k | : ) | 09:32 |
| humpelstilzchen[ | ah ok. | 09:32 |
| humpelstilzchen[ | I tried manually with media-ctl commands | 09:33 |
| rafael2k | ah, lots of crazy and specific ioctl()'s for pp hardware... | 09:35 |
| humpelstilzchen[ | also | 09:35 |
| humpelstilzchen[ | [ 183.854684] ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded | 09:35 |
| humpelstilzchen[ | [ 186.733527] ov5640 3-004c: firmware upload success | 09:35 |
| humpelstilzchen[ | -rw-r--r-- 1 user user 4077 Feb 3 22:06 /lib/firmware/ov5640_af.bin | 09:35 |
| rafael2k | I would just copy the "lower level" management of Megapixels and write a simple camera UI for maemo | 09:35 |
| rafael2k | hopefully compatible with any camera hardware, and not only with pp hardware | 09:36 |
| rafael2k | cool! | 09:36 |
| rafael2k | (I'm not sure if there is already any maemonized camera app... hopefully there is) | 09:42 |
| sicelo | There is. | 09:44 |
| rafael2k | good! can you give any hint about its name? | 09:46 |
| rafael2k | : ) | 09:47 |
| rafael2k | (of course I remember taking pics in the N900...) | 09:49 |
| humpelstilzchen[ | Maybe you can make Blessn900 work in PP | 09:49 |
| rafael2k | BlessN900!! | 09:49 |
| rafael2k | I used to use that in the past life!! | 09:49 |
| sicelo | https://github.com/community-cssu/camera-ui | 09:49 |
| rafael2k | 404 | 09:50 |
| freemangordon | 404?!? | 09:50 |
| freemangordon | WTF? | 09:50 |
| sicelo | Um, maybe because I manually typed it. I have it open on pc | 09:51 |
| freemangordon | https://github.com/community-ssu | 09:51 |
| sicelo | Ah, https://github.com/community-ssu/camera-ui | 09:51 |
| rafael2k | https://github.com/community-ssu/camera-ui | 09:51 |
| freemangordon | this uses Nokia lib, has to be ported to something else | 09:52 |
| rafael2k | cool! | 09:52 |
| freemangordon | gst part has to be ported too | 09:52 |
| rafael2k | libgdigicam ? | 09:55 |
| rafael2k | this is the proprietary part? | 09:55 |
| freemangordon | yeah | 09:56 |
| freemangordon | but it is just a wrapper to omap3camd, more or less | 09:56 |
| rafael2k | wow, location-daemon is here! | 09:56 |
| freemangordon | sure | 09:56 |
| rafael2k | : ) | 09:56 |
| freemangordon | and omap3camd is where all Nokia image/video processing happens | 09:57 |
| rafael2k | right, these camera low level things we can easilly borrow from current camera apps | 09:58 |
| freemangordon | mhm | 09:58 |
| freemangordon | UI should be usable though | 09:58 |
| rafael2k | I'm trying to compile it here | 09:59 |
| rafael2k | Unmet build dependencies: libgdigicam-dev libgdigicam-gst-camerabin-dev libhal-dev libnavigation-dev sharing-dialog-dev gstreamer0.10-plugins-camera-dev libgstreamer-plugins-base0.10-dev | 10:03 |
| rafael2k | not bad | 10:03 |
| rafael2k | gstreamer port to 1.0 is not rocket science | 10:03 |
| rafael2k | the rest it seems the low level camera bits and some other bits regarding libnavigation-dev sharing-dialog-dev | 10:04 |
| rafael2k | we even have the camera sounds already installed! /usr/share/sounds/camera_snd_title_3.wav | 10:06 |
| rafael2k | eheheheh | 10:06 |
| rafael2k | lots of gstreamer work indeed... which will be core of the work I think | 10:09 |
| rafael2k | the sound of the camera shutter is working /usr/share/sounds/camera_snd_title_1.wav | 10:14 |
| rafael2k | :P | 10:14 |
| sicelo | :-) | 10:33 |
| freemangordon | rafael2k: yeag, gst part should be easy | 10:38 |
| freemangordon | *yeah | 10:38 |
| freemangordon | hmm, why libnavigation-dev is missing? | 10:38 |
| freemangordon | mayeb one more piece to RE | 10:38 |
| freemangordon | hmm | 10:39 |
| freemangordon | yeah, this either has to be REed or upstream replacement found | 10:42 |
| freemangordon | though I doubt there is one | 10:43 |
| freemangordon | rafael2k: http://repository.maemo.org/pool/fremantle/nokia-binaries/4bc37c7c77ebe90177c050b805a8dc79/nokia-binaries/libn/libnavigation/ | 10:43 |
| freemangordon | check headers in the -dev package | 10:43 |
| freemangordon | I don;t think there is anything FOSS that implements such functionality | 10:44 |
| freemangordon | we already have nm-nav-provider, so REing that wrapper lib should not be a big issue | 10:46 |
| freemangordon | this https://github.com/community-ssu/nokiamaps-navigation-provider | 10:46 |
| bencoh | freemangordon: if anything, I'd have a look at fcamera | 11:26 |
| bencoh | (regarding camera) | 11:27 |
| bencoh | well actually it depends on what you want to use it for, I dunno if it would be suitable for live camera streaming or video recording | 11:28 |
| rafael2k | freemangordon: tks!! | 11:28 |
| bencoh | does omap3camd levarage the ISP for debayering? | 11:28 |
| bencoh | leverage* | 11:28 |
| bencoh | (ie demosaicing) | 11:29 |
| freemangordon | I think so | 11:29 |
| freemangordon | all post-processing happens in omap3camd and IIRC part of it is HW accelerated through ISP | 11:32 |
| sicelo | Is ISP open/documented? | 11:35 |
| freemangordon | yes | 11:35 |
| freemangordon | bencoh: I see no debayer module, so I guess we get RGB from cameras | 11:35 |
| freemangordon | or it is done implicitly | 11:36 |
| sicelo | There was a libcamera talk at FOSDEM, and Laurent wished he could support omap SoCs there | 11:36 |
| freemangordon | ISP is already supported in kernel | 11:36 |
| freemangordon | not sure to what extend though | 11:36 |
| Wizzup | bencoh: yeah fcamera is great | 11:37 |
| freemangordon | also, n900 is very tricky in terms of cameras | 11:37 |
| freemangordon | as front/back switch is done through gpio | 11:37 |
| freemangordon | last time I checked this was not handled properly in the kernel | 11:38 |
| sicelo | I think fcamera was using very custom stuff, including kernel modules. Hence Pavel sort of gave up on it for his N900 camera poc | 11:38 |
| rafael2k | cedrus hw acceleration seems to be working with VA libva-v4l2-request in PP, at least up to what I could test with H.264 | 11:38 |
| freemangordon | yes, it was using custom kernel modules | 11:38 |
| freemangordon | Wizzup: were you able to come up with some idea on how to use xkb data? like, we can live without nokia etc kbd models | 11:40 |
| freemangordon | as we already have that in /etc/default/keyboard | 11:40 |
| freemangordon | but, I am not able to grok how to get the available layouts based on keyboard model | 11:40 |
| freemangordon | maybe I am missing something, dunno | 11:41 |
| Wizzup | freemangordon: no, didn't really think about it much more, do you mean base or base.xml file? | 11:45 |
| Wizzup | I think I was kind of able to parse the base file in my head, where the repeating lines are additional layouts | 11:46 |
| Wizzup | but we can just add stuff to base.xml as far as I can concerned | 11:46 |
| Wizzup | we already fork xkb-data anyway | 11:46 |
| freemangordon | base.xml is not the same as base, in terms of data/logic | 11:47 |
| freemangordon | but ok, I will see what I can come up with | 11:47 |
| _uvos_ | please use libcamera. the pp camera and the n900 camera should be usable though libcamera with the mainline kernel in basic fashion (at least filters and sensor color grading will be needed for n900 to get resonable pictures) | 12:42 |
| Wizzup | agreed | 12:42 |
| _uvos_ | also mapphone cameras will need libcamera too | 12:43 |
| rafael2k | Wizzup: any problem with the pp kernel PR, lemme know | 12:46 |
| _uvos_ | btw there was a driver for omap4 video decoding in linux mainline staging, and there is a foss ti lib to use it | 12:46 |
| _uvos_ | so should be possible to get that going for hw encode | 12:47 |
| humpelstilzchen[ | not remoteproc I hope? | 12:47 |
| rafael2k | libcamera++ | 12:47 |
| rafael2k | there is even a gst plugin! | 12:48 |
| rafael2k | but we'll need newer meson version, and prolly other newer stuff | 12:50 |
| Wizzup | rafael2k: no problem, just busy this morning, will get on it in a few hours | 13:08 |
| sicelo | IIRC, libcamera doesn't support omap* camera subsystem yet. Someone will have to add it | 13:21 |
| _uvos_ | omap iss should work fine in libcamera via mcc/v4l to get raw data | 13:30 |
| _uvos_ | so the omap side is there | 13:30 |
| _uvos_ | you need support for dealing with particularits of the datastrem ofc | 13:31 |
| _uvos_ | per sensor chip | 13:31 |
| _uvos_ | ie debayer/ color grading, binning what have you | 13:31 |
| _uvos_ | and for sane performance you need to use ducati/ whatever omap 3 hw block is | 13:33 |
| bencoh | freemangordon: no, we get bayer from camera | 15:18 |
| bencoh | freemangordon: fcamera saves raw by default (it allows saving a processed version as well, but that's custom processing) | 15:19 |
| bencoh | as for video on droid4, iirc it's based on remoteproc, yes | 15:20 |
| bencoh | or the TI remoteproc equivalent from back then (2012) | 15:21 |
| bencoh | is libcamera really "good" btw? or is it bloated like the android camera subsystem? | 15:23 |
| bencoh | https://libcamera.org/faq.html hmm ... | 15:25 |
| Wizzup | uvos: bionic battery really lasts for a long time | 15:44 |
| freemangordon | Wizzup: could it be related to the latest reverts? | 16:53 |
| Wizzup | freemangordon: not just that, but also | 17:00 |
| Wizzup | bionic I think in general idles a bit better somehow | 17:00 |
| Wizzup | it's surprising how well the bionic works | 17:00 |
| bencoh | Wizzup: should we drop the droid4 and start working on a bionic hw keyboard? :] | 18:16 |
| Wizzup | bencoh: I think working on a virtual keyboard that can be shown while the app is resized and visible (not blurred) would be helpful | 18:17 |
| Wizzup | including support for ctrl etc | 18:17 |
| bencoh | oh, talking about keyboards, ibus has support for emojis (with a clickable window). I wonder if integrating the hildon keyboard in some ibus plugin would give better results | 18:18 |
| Wizzup | uvos probably has some ideas on this too, there is the at-spi stuff | 18:19 |
| bencoh | like, ibus works with any kind of application, be it gtk/qt, or plain X11 (through xmodifiers) | 18:19 |
| Wizzup | buZz: just built navit 0.5.6 on maemo | 18:45 |
| Wizzup | seems to work | 18:45 |
| dsc_ | Wizzup: perhaps the app does not have to be resized for virtual keyboard to show up | 18:47 |
| dsc_ | android behavior is to overlay the keyboard as-is | 18:48 |
| Wizzup | dsc_: well, if you have a terminal and you're typing at the bottom, how does it work? | 18:48 |
| dsc_ | some applications you'd want to resize (terminal apps), some application may choose to provide their own keyboard (terminal apps?), some applications dont want to resize (browers) | 18:52 |
| dsc_ | if you want to follow android behavior, that is | 18:53 |
| dsc_ | im just looking at what my phone currently does :P | 18:53 |
| Wizzup | mhm | 18:55 |
| Wizzup | buZz: do you know how specify a vehicle for navit? | 18:59 |
| buZz | eh no , i barely know what navit is :P | 19:01 |
| buZz | i found attempts of myself to get it running on a zipit z2 back in 2019 | 19:01 |
| buZz | but seemingly i never did | 19:01 |
| buZz | Wizzup: maybe the http://wiki.navit-project.org/index.php/Maemo can be extended / updated / pointed to leste :P | 19:04 |
| Wizzup | they removed support recently, but it's not in any release yet | 19:06 |
| buZz | yeah but for leste we could revive it by supporting nearnative i guess? the layouts are some kinda xslt | 19:06 |
| Wizzup | the latest release is 0.5.6 which supports maemo | 19:06 |
| buZz | alright, i'm doing my tomtom messingaround on git master | 19:07 |
| Wizzup | idk what nearnative is, but I think making it work before they removed support is a start | 19:07 |
| bencoh | :) | 19:07 |
| buZz | well, its in devuan | 19:07 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/605 (Import/package navit) | 19:08 |
| buZz | yeah i'm just saying, maybe there's no need for real maemo support if the plain x one already kinda works | 19:08 |
| bencoh | oh, 0.5.6 is quite recent too | 19:08 |
| Wizzup | yes | 19:08 |
| Wizzup | I just built it, it seems to work, but the config is complicated | 19:08 |
| Wizzup | not going to mess too much more with it right now, but if someone feels like it | 19:08 |
| rafael2k | https://modrana.org is not good? | 19:08 |
| Wizzup | just having liblocation-dev installed is enough for cmake to add maemo support | 19:08 |
| Wizzup | rafael2k: I think both are good :) | 19:09 |
| buZz | modrana has no working planning afaik | 19:09 |
| rafael2k | humm | 19:09 |
| bencoh | planning? | 19:09 |
| buZz | yeah planning of routes | 19:09 |
| rafael2k | what is this, btw? | 19:09 |
| buZz | there is http://wiki.maemo.org/ModRana_offline_routing_guide but getting that stuff working for me was impossibru | 19:10 |
| rafael2k | do we have it packaged? | 19:10 |
| bencoh | buZz: oh, really? | 19:10 |
| buZz | i'd love to see someone pull it off :P | 19:10 |
| bencoh | offline routing works well for marble, and iirc they use the same routing engine | 19:10 |
| Wizzup | buZz: well if you have some time maybe you can try it with leste, we're close to supporting various tablets as well, so could be nice for in-car nav somehow :p | 19:10 |
| bencoh | (aka monav) | 19:10 |
| bencoh | (which reminds me I should probably update my monav routing database with the data from modrana) | 19:11 |
| * Wizzup never used routing on n900 | 19:11 | |
| buZz | bencoh: hmm yeah it does use the same engine it seems, not sure what went wrong | 19:11 |
| bencoh | it's pretty neat | 19:11 |
| bencoh | oh, modrana stopped updating its monav routing database repository :( | 19:12 |
| bencoh | it's stuck in 2015 | 19:12 |
| bencoh | and monva.openstreetmap.de is dead | 19:12 |
| rafael2k | Wizzup: I used to use sigic | 19:12 |
| rafael2k | sygic | 19:12 |
| buZz | the navit guys seem kinda active anyway, so it felt like a nice route towards my non-maemo related goal of recycling old tomtoms :P | 19:13 |
| rafael2k | I would use my pp with maemo to play music and may be at the same time do some gps assisted routing : )) | 19:13 |
| buZz | does the pinephone have a fm transmitter? :P | 19:14 |
| rafael2k | dont make me cry | 19:14 |
| rafael2k | :( | 19:14 |
| buZz | ah no :( | 19:14 |
| rafael2k | :P | 19:14 |
| buZz | some tomtoms do have one :) | 19:14 |
| rafael2k | how i miss it | 19:14 |
| rafael2k | thaaat is cool | 19:14 |
| buZz | not quite sure those work for what i want | 19:14 |
| rafael2k | could even transmit some afsk data to the nearest buddies... eheheheh | 19:15 |
| rafael2k | when I have my sabbatical year I'll do a cover for the pp just like the lora one, but with a true generic radio, with i/q in and out | 19:16 |
| rafael2k | <- trying to compile libcamera to see if it works with pp | 19:21 |
| rafael2k | this libcamerasrc element for gstreamer would be really useful if it works... we could have camera ui much easily ported and much more generic (instead of hardcoding tons of specific ioctl()'s for each supported device) | 19:29 |
| buZz | rafael2k: hahaha, hackrf pp cover? :D | 19:30 |
| rafael2k | exactly | 19:30 |
| buZz | 10w PA with seperate battery | 19:30 |
| buZz | :D | 19:30 |
| rafael2k | certainly I will borrow some ideas from the pp keyboard, just not the catching fire part | 19:31 |
| rafael2k | big battery and powerful PA | 19:31 |
| buZz | its catching fire? :P | 19:33 |
| rafael2k | mine did | 19:33 |
| rafael2k | :/ | 19:33 |
| buZz | howso? | 19:33 |
| buZz | overeager usb-c pd? :P | 19:33 |
| rafael2k | like 2 minutes after being the charger, smoked | 19:33 |
| buZz | '120W? yessirrr' | 19:33 |
| rafael2k | :PP | 19:34 |
| buZz | does it still work? :) | 19:34 |
| rafael2k | sure, I use as weight for the papers in the table now | 19:34 |
| rafael2k | (pine64 is sending me a new mainboard to change myself... lets see) | 19:35 |
| buZz | ah sweet :) | 19:43 |
| rafael2k | I see in libcamera some specific support for "pipelines", like ipu3, raspberrypi, rkisp1, simple, uvcvideo and vimc, and some enable "IPA" modules, whatever it is, but I doubt specific pp (or N900) support will be perfect out-of-the-box | 19:43 |
| rafael2k | but at least the infrastructure to add proper support for specific hardware is that, which is nice | 19:44 |
| rafael2k | (it is still compiling, btw, including the QT app) | 19:44 |
| rafael2k | (i'm compiling in bullseye chroot for the sake of lazyness... if it works fine, we backport it to beowulf) | 19:47 |
| sicelo | i think pp should have the best support actually ... because that's the "main" device throughout all FOSS projects nowadays | 19:55 |
| sicelo | (support in libcamera, that is) | 19:55 |
| rafael2k | https://pastebin.com/a4UMccYB | 20:53 |
| rafael2k | nope, no support for gc2145 or ov5640 | 20:54 |
| rafael2k | See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information <- | 20:54 |
| rafael2k | we need specific pipeline support | 20:54 |
| uvos | tmlind: so your misterious 1 or 0 that is sent with the gps time isent what atenna to use right? | 20:59 |
| uvos | i wonder if bionic locks fast with the time patch | 20:59 |
| uvos | Wizzup: do we have this in leste? | 20:59 |
| Wizzup | uvos: it's pretty fast imo | 21:01 |
| Wizzup | do we have what in leste | 21:01 |
| Wizzup | ? | 21:01 |
| uvos | tmlinds patch to upload the time to qcom modem | 21:02 |
| uvos | its very mutch not fast | 21:02 |
| uvos | have you tried the gps on android :P | 21:02 |
| rafael2k | https://iboxshare.com/kbingham/libcamera/issues/28 | 21:03 |
| rafael2k | ok, we need more patches to our kernel ^ | 21:03 |
| rafael2k | it seems someone just sent to megi for 5.17 | 21:04 |
| rafael2k | I can backport the patches to our 5.15 | 21:04 |
| rafael2k | so then we can have libcamera working | 21:04 |
| rafael2k | right now, libcamera _does not_ work | 21:04 |
| uvos | did anyone say it did? | 21:05 |
| uvos | rafael2k: nice work anyhow :) | 21:06 |
| rafael2k | Update: They have already been pulled in the 5.17 kernel branch ^ | 21:06 |
| rafael2k | after spending some time with libcamera... the problem is not there, but defunct kernel support indeed... | 21:06 |
| rafael2k | : ) | 21:06 |
| uvos | rafael2k: ok | 21:06 |
| rafael2k | and this is kind of very recent, one week ago | 21:07 |
| uvos | Wizzup: could you awnser the question? i keep on forgeting what branch of https://github.com/maemo-leste/droid4-linux is the active one | 21:08 |
| rafael2k | megapixels is pretty hacky stuff, all hardcoded, but current state (not 5.17 of some days ago) did not have proper v4l functions to handle probing the camera parameters and so on | 21:08 |
| uvos | rafael2k: ok great | 21:08 |
| uvos | maybe its easiest to get some camera ui with libcamera going on rpi first | 21:09 |
| rafael2k | good... so we can proceed with the idea of pluging camera-ui to gst-libcamera... I plan to do the kernel worklifting soon | 21:09 |
| uvos | or uvc | 21:09 |
| rafael2k | sure, that can go in parallel | 21:09 |
| rafael2k | gst-libcamera + libcamera itself | 21:09 |
| uvos | ok | 21:10 |
| rafael2k | I'll check what might be better, backport the patches, or just go to 5.17... | 21:13 |
| rafael2k | camera is a nice feature indeed | 21:14 |
| uvos | just go up | 21:14 |
| rafael2k | : )) | 21:14 |
| rafael2k | I like that idea too | 21:14 |
| Wizzup | uvos: I was in a work meeting, sorry | 21:18 |
| Wizzup | uvos: this is the current branch, and yes it needs cleaning up and we should use a diff branch name https://github.com/maemo-leste/droid4-linux/commits/wip/n900/maemo-5.15-cleaned-up | 21:18 |
| uvos | Wizzup: no worrys :) i just thought you forgot to awnser | 21:18 |
| Wizzup | uvos: my pretty fast remark was regarding your lock question | 21:18 |
| Wizzup | uvos: ooooh | 21:18 |
| Wizzup | uvos: I thought of lock _screen_ | 21:19 |
| Wizzup | lol | 21:19 |
| uvos | oh | 21:19 |
| uvos | haha | 21:19 |
| uvos | :P | 21:19 |
| uvos | Wizzup: right ok so we dont have tmlinds patch | 21:20 |
| uvos | Wizzup: ok ill have to build it then to try it on bionic | 21:20 |
| Wizzup | I can add it | 21:20 |
| uvos | ok thanks! | 21:21 |
| rafael2k | Wizzup: please don't forget the no-keyboard-burn kernel for pp | 21:22 |
| rafael2k | : )) | 21:22 |
| uvos | rafael2k: vat? what happend there? link? | 21:23 |
| rafael2k | uvos: see my PR to pine64-kernel | 21:23 |
| Wizzup | rafael2k: not forgetting, been busy | 21:24 |
| rafael2k | there are some scare new pp keyboard patches that landed a couple of days ago to make the keyboard behave better... like limiting power and stuff like that | 21:24 |
| rafael2k | no rush... | 21:24 |
| rafael2k | it was my fault prolly, but having better software support always make hardware smoke more difficult | 21:25 |
| Wizzup | let me finish dinner and then I'll do it | 21:29 |
| * dsc_ looks at the clock | 21:30 | |
| rafael2k | here is wine time already... just put my daugher to sleep : ) | 21:33 |
| uvos | rafael2k: so sphone dosent work wrt profile switch anymore? | 21:34 |
| uvos | could you paste pactl list? | 21:34 |
| uvos | on pp | 21:34 |
| uvos | ofc | 21:34 |
| rafael2k | uvos: good, lemme test again now I set the default pa device | 21:34 |
| Wizzup | dsc_: second dinner, had some leftovers :) | 21:34 |
| uvos | id better not tell anyone when i had dinner then.... | 21:34 |
| uvos | rafael2k: also sphone log | 21:35 |
| uvos | rafael2k: killall sphone ; sphone -v | 21:36 |
| rafael2k | uvos: not working | 21:36 |
| rafael2k | ok | 21:36 |
| uvos | it still works on mapphone | 21:37 |
| rafael2k | sphone: route-pulseaudio: failure: set ucm profile to Voice Call No such entity | 21:37 |
| rafael2k | sphone: route-pulseaudio: failure: set ucm profile to HiFi No such entity | 21:37 |
| uvos | pactl list | 21:38 |
| rafael2k | https://pastebin.com/shLP7tsD | 21:39 |
| uvos | yeah ok | 21:41 |
| uvos | pa_context_set_card_profile_by_index fails becasue the first soundcard dosent have the profile | 21:42 |
| rafael2k | there are 2 cards now.. | 21:42 |
| uvos | i gues we should be ok with it failing | 21:42 |
| rafael2k | the problem is not sphone | 21:43 |
| rafael2k | I'm not sure if I should set the default in alsa ou pa | 21:43 |
| uvos | sure it is, it tries to set the profile for every card | 21:43 |
| uvos | and it bails if one fails | 21:43 |
| rafael2k | hummmm | 21:43 |
| rafael2k | with new kernel we have more alsa devices indeed | 21:46 |
| rafael2k | more stuff receiving drivers | 21:47 |
| uvos | right its just a silly bug in sphone | 21:47 |
| uvos | it would break on mapphones too | 21:47 |
| uvos | if the hdmi driver wasent broken | 21:47 |
| rafael2k | : )) | 21:47 |
| rafael2k | btw, with my new PR, hdmi audio output should be fixed (hopefully, and I did not test) | 21:48 |
| rafael2k | (cortesy to moblian patchset, not really me) | 21:49 |
| rafael2k | I wonder if I will be able to squeeze a 5G quectel in this pp... but for now I could not find any 5G networks here anyway... | 21:53 |
| rafael2k | afai, I'll be able to do it | 21:53 |
| rafael2k | dont really understand why ppp did not came with a 5G modem, considering quectel already launched it | 21:54 |
| uvos | 5g at long wavelengths is mostly pointless | 21:55 |
| rafael2k | nobody use this | 21:55 |
| rafael2k | I mean | 21:55 |
| rafael2k | everybody use this currectly | 21:55 |
| rafael2k | :P | 21:55 |
| rafael2k | (all the deployments I mean) | 21:55 |
| uvos | righ | 21:56 |
| rafael2k | the uplink is much better | 21:56 |
| uvos | t | 21:56 |
| Wizzup | rafael2k: wait did you merge in my branch somehow | 21:56 |
| uvos | and mostly its pointless | 21:56 |
| rafael2k | Wizzup: how? | 21:56 |
| Wizzup | maybe 'tig' is showing it weirdly | 21:56 |
| rafael2k | well... we could argue all 3gpp are... | 21:56 |
| uvos | not really | 21:56 |
| rafael2k | Wizzup: are you talking about my PR? | 21:56 |
| Wizzup | rafael2k: looking at your branch | 21:57 |
| Wizzup | did you make a PR? | 21:57 |
| rafael2k | massive mimo, better modulation, 3gpp goes step by step | 21:57 |
| rafael2k | Wizzup: yes | 21:57 |
| rafael2k | here: | 21:57 |
| rafael2k | https://github.com/maemo-leste/pine64-kernel/pull/3 | 21:57 |
| rafael2k | then you need to pull kernel yourself to mobian-5.15 | 21:58 |
| rafael2k | as I dunno how to do it from my fork | 21:58 |
| rafael2k | https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 | 21:58 |
| rafael2k | uvos: so NR is not pointless... | 21:59 |
| uvos | rafael2k: the difference was that lte was allready pretty mutch at the shannon limit | 21:59 |
| rafael2k | uvos: I like GSM | 21:59 |
| rafael2k | uvos: considering siso | 21:59 |
| rafael2k | shannon does not consider multiple inputs and outputs | 22:00 |
| rafael2k | and indeed are many channels being used together | 22:00 |
| rafael2k | *as | 22:00 |
| uvos | sure | 22:00 |
| rafael2k | so 5G is not pointless | 22:00 |
| rafael2k | :P | 22:00 |
| uvos | but in practiacal deployments that dosent help you really | 22:00 |
| rafael2k | indeed | 22:00 |
| rafael2k | I agree | 22:00 |
| rafael2k | but the uplink got a bit improved, I must say | 22:01 |
| Wizzup | rafael2k: right so that PR updates the debian branch and patches | 22:01 |
| Wizzup | and then I just need to override the branch and make a new tag | 22:01 |
| rafael2k | Wizzup: that PR is just for beowulf-devel | 22:02 |
| rafael2k | Wizzup: then you need the git magic to have the latest mobian-5.15 (which I forked) to mobian-5.15 branch | 22:02 |
| Wizzup | ok, and you removed the patches from that branch right | 22:03 |
| rafael2k | uvos: it does not help me, it helps the chip makers and patent owners | 22:03 |
| rafael2k | Wizzup: ah, no no, I did not delete the debian/ dir | 22:04 |
| uvos | particulary it helps chip makers get grants from goverments :P | 22:04 |
| uvos | but... lets not get into this | 22:04 |
| rafael2k | Wizzup: should I? | 22:04 |
| rafael2k | uvos: yeap, totally... and 5G in high frequencies has some usage that nobody discoved what to do with it, no real deployment yet | 22:05 |
| rafael2k | Wizzup: I did not delete the debian/ dir (from mobian) here: https://github.com/rafael2k/sunxi64-linux/ | 22:06 |
| uvos | yeah no argument there high frequency 5g has nich practical uses in high density areas imo | 22:06 |
| rafael2k | Wizzup: (mobian-5.15 branch) | 22:07 |
| rafael2k | uvos: but people says it causes cancer and controls your brain... :P | 22:07 |
| uvos | lets not engage with sutch people :P | 22:08 |
| rafael2k | uvos: hNodeB above 20 GHz provide very small coverage cells... suscetible to rain fading and so on | 22:09 |
| rafael2k | :P | 22:09 |
| rafael2k | better not | 22:09 |
| rafael2k | I work with HF radio and GSM... it is enough for my head already | 22:10 |
| rafael2k | I like high power transmitters, I feel better when it is higher than 100 kW | 22:12 |
| rafael2k | my body reacts well : ) | 22:13 |
| Wizzup | rafael2k: let me just check, maybe git diff confuses me | 22:14 |
| rafael2k | Wizzup: ok | 22:15 |
| Wizzup | git diff from my mobian-5.15 and yours give me this https://dpaste.com/5L3S2R3SV.txt | 22:15 |
| Wizzup | argh colour output | 22:15 |
| Wizzup | https://dpaste.com/FC4E5XM77.txt | 22:16 |
| rafael2k | just a sec | 22:17 |
| Wizzup | that is 1456273b2f82b5e85324411fb189a57273d772b0 (your HEAD) and 3f0d484ed6b51c664045bd737e647e8e03277570 (current repo head / maemo-kernel-5.15.0tag) | 22:17 |
| rafael2k | hum | 22:18 |
| rafael2k | could you just rebase using "upstream"? I dunno what is wrong | 22:18 |
| Wizzup | sure, but you have a merge commit merging in the old branch/tag | 22:18 |
| rafael2k | https://gitlab.com/mobian1/devices/sunxi64-linux/ | 22:18 |
| Wizzup | so somewhere you git 'git merge' and it used --no-ff instead of the nice --ff-only | 22:18 |
| Wizzup | ah ok, just take upstream and then merge your maemo/beowulf-devel branch? | 22:19 |
| rafael2k | shit, yes, I probably fucked up | 22:19 |
| rafael2k | upstream to mobian-5.15 | 22:19 |
| rafael2k | andd my PR just for maemo/beowulf-devel | 22:19 |
| Wizzup | ok, will do | 22:20 |
| rafael2k | just checked upstream - all good - no new chane | 22:20 |
| Wizzup | so that is: | 22:20 |
| Wizzup | 8a2c78110ed923d0002d571b2606f39c485c08b8 | 22:20 |
| Wizzup | d/changelog: Release version 5.15.21 | 22:20 |
| rafael2k | yes! | 22:20 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/pine64-kernel/pull/3 (New PP kernel release, with important keyboard patches) | 22:21 |
| Wizzup | https://phoenix.maemo.org/job/pine64-kernel-source/71/ | 22:24 |
| rafael2k | I like this spinner | 22:28 |
| uvos | orbital mechanics | 22:28 |
| rafael2k | :PPPP | 22:29 |
| Wizzup | lol yeah | 22:31 |
| buZz | Wizzup: 'how to change vehicle in navit' > tap screen > settings > change vehicle , at least on my devuan x86 install ;) | 22:35 |
| buZz | it supports horse :D | 22:35 |
| buZz | ah time for daily matrix.org spamruns | 22:35 |
| Wizzup | buZz: I think you need to specify it on start | 22:37 |
| Wizzup | at least the way I understand | 22:37 |
| buZz | hmm, not sure? it does appear that gpsd gets linked to a specific vehicle profile in navit.xml | 22:39 |
| buZz | <!-- Vehicle with GPS enabled for gpsd on unix --> | 22:39 |
| Wizzup | right, we don't use gpsd | 22:42 |
| Wizzup | we use liblocation | 22:42 |
| Wizzup | something like this: | 22:43 |
| Wizzup | <vehicle name="Local GPS" profilename="car" enabled="yes" active="1" source="maemo"> | 22:43 |
| Wizzup | (and more) | 22:43 |
| buZz | alrighty | 22:43 |
| rafael2k | is liblocation integrated with gpds somehow already? | 22:45 |
| uvos | it uses gpsd | 22:45 |
| rafael2k | gpsd seems to be working fine here | 22:45 |
| rafael2k | ah, ok | 22:45 |
| uvos | yes gpsd works fine | 22:45 |
| Wizzup | liblocation is a lib that does some extra stuff but the data comes from gpsd ultimately, but there is some dbus stuff as well | 22:45 |
| uvos | really we should port it to geoclue instead | 22:46 |
| Wizzup | (the gpsd dbus stuff isn't that great) | 22:46 |
| uvos | note that liblocation is just a dumb proxy for gpsd atm | 22:46 |
| Wizzup | it does do more stuff than just being a proxy | 22:46 |
| rafael2k | liblocation seems ok to me, I remember its API from long time ago when I played with it with the N900 | 22:46 |
| Wizzup | it contains some ui elements, a status applet, and other stuff | 22:46 |
| Wizzup | and it will stop gpsd when it's not required, etc | 22:46 |
| Wizzup | I don't know much about geoclue so cannot comment | 22:47 |
| uvos | geoclue dose all of this + has working network location sources and sensor fusion | 22:47 |
| rafael2k | so better stick with liblocation :P | 22:48 |
| uvos | sure ui elemetns etc, i mean liblocation and the location deamon do little besides proxy gpsd atm | 22:48 |
| uvos | ofc the ui and sutch uses it | 22:48 |
| Wizzup | uvos: yes, we need to look into geoclue to some degree | 22:48 |
| rafael2k | right | 22:48 |
| Wizzup | it probably won't help us with low level integration though | 22:49 |
| uvos | wdym? | 22:50 |
| uvos | low level integration | 22:50 |
| uvos | mostly we can ditch location deamon, and port liblocation to geoclue to be just a legacy shim | 22:50 |
| uvos | and then have the ui bits use geoclue directly | 22:51 |
| uvos | then all the desktop/phos/plamo applications will just work | 22:51 |
| Wizzup | I don't have the energy to go into this now, I think we discussed this at length, and we need a way to be able to just turn off gps and prevent apps from using gps when users doesn't want it on | 22:52 |
| Wizzup | and yes, geoclue probably has a place in all of this | 22:52 |
| uvos | right geoclue provdes this | 22:52 |
| uvos | :) | 22:52 |
| uvos | preventing apps from using gps requries more ofc | 22:52 |
| uvos | rn the permissions are wrong even | 22:52 |
| rafael2k | Wizzup: should we put kernel minor version in changelog? https://github.com/maemo-leste/pine64-kernel/commit/044a2099d787d6d40f4c49fabf9162edddce4965 | 22:54 |
| rafael2k | Wizzup: looking at other updates, it was always bla.la.0-{1,2,3}... | 22:55 |
| rafael2k | I mean.. it does not matter tbh, just cosmetics... | 22:58 |
| rafael2k | btw, looking at libcamera, to have really proper support, we need to create a pipeline there, in order, for example, to use hardware acceleration together with the frames captures | 23:01 |
| rafael2k | *captured | 23:01 |
| Wizzup | rafael2k: I put the minor version in there | 23:01 |
| rafael2k | Wizzup: I like | 23:01 |
| Wizzup | rafael2k: I think we should, but I've been sloppy about some of it | 23:01 |
| rafael2k | Wizzup: cool, I agree, next PR I'll do this too | 23:04 |
| Wizzup | uvos: sounds good, but let's not do it now | 23:04 |
| uvos | Wizzup: ok | 23:04 |
| Wizzup | hmm getting some drm errors on bionic | 23:25 |
| Wizzup | https://dpaste.com/7ZVLDPUXS.txt | 23:26 |
| Wizzup | yeah X is back in that loop now with the mode set failing | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!