Wizzup | uvos: https://github.com/maemo-leste/sphone/pull/4 | 01:54 |
---|---|---|
freemangordon | sicelo: https://github.com/maemo-leste/libicd-network-ofono/blob/master/src/link.c#L125 :) | 08:05 |
rafael2k | morning | 08:05 |
freemangordon | morning! | 08:05 |
rafael2k | Wizzup, could you spin a Maemo-Leste Chimaera with harbour-pinhole in order piggz can more easily test our stack? | 08:06 |
rafael2k | доброе утро! | 08:06 |
freemangordon | добро утро | 08:07 |
rafael2k | 🤘 | 08:08 |
rafael2k | I built a kernel with latest ov5640 upstream, and now the system with power on correctly the ov5640 | 08:08 |
rafael2k | so the system is kind of ready for testing camera app on the PP, all in the repo | 08:09 |
rafael2k | and it is cool to play with the autofocus! | 08:10 |
rafael2k | https://leste.maemo.org/PinePhone#How_to_take_a_picture | 08:13 |
rafael2k | while not in pinhole yet, we can trigger the autofocus tru v4lctl | 08:13 |
rafael2k | btw, support for the PPP is almost in good shape too | 08:14 |
rafael2k | We'll need need some wiring up of control from libcamera, but the crew there is helping getting the needed controls wired up | 08:14 |
rafael2k | the PPP has indeed a proper ISP | 08:15 |
rafael2k | which is well supported by libcamera, through a specific pipeline configure (in the PP we just use the simple pipeline) | 08:16 |
rafael2k | btw, I read a about "eMMC Installation" "Warning, this no longer works in latest images since boot.txt was removed. Please update this section." | 08:19 |
rafael2k | can we just add in our u-boot package (copyed directly from our debian dir) a nice boot.txt sample, with commented our example how to multiboot and so on (I multiboot with Mobian on the eMMC)? | 08:20 |
rafael2k | at the same time, default u-boot for SD and a sample u-boot boot.txt for eMMC, and a "mkboot.sh" or something that runs mkimage -A arm -O linux -T script -C none -a 0 -e 0 -d boot.txt boot.scr | 08:21 |
rafael2k | in the end. we could also ship with set already made an image for SD installation and another for eMMC | 08:22 |
freemangordon | sicelo: apn/username/password not being set issue should be fixed, please upgrade and confirm | 11:23 |
freemangordon | the only remaining issue that's known to me is "always ask for password" tick not being obeyed | 11:23 |
Wizzup | rafael2k: for pinephone? | 11:30 |
Wizzup | (an image?) | 11:30 |
Wizzup | I can do it in 4-5 hrs | 11:30 |
Wizzup | freemangordon: I haven't figured out yet how to tell tp-ring not to do anon calls | 12:21 |
Wizzup | there is a tp interface for it, but voicecalls from sfos does not seem to use it at all | 12:21 |
Wizzup | maybe there is a tp ring config option that I missed or something | 12:21 |
Wizzup | freemangordon: I asked in #sailfish | 12:34 |
Wizzup | sorry, #sailfishos | 12:34 |
sicelo | great idea | 12:37 |
Wizzup | hm, I think I might have figured it out | 12:38 |
Wizzup | no, probably not, this needs to be addressed in voicecall-manager I think | 12:43 |
freemangordon | Wizzup: where is #sailfishos ? | 12:58 |
Wizzup | oftc | 12:58 |
freemangordon | bencoh: did you manage to build ff? | 13:04 |
* freemangordon is tempted to post a video with chromium playing YT video as a reply to https://bugzilla.mozilla.org/show_bug.cgi?id=1812016 | 13:07 | |
freemangordon | on the same 'low-end' | 13:07 |
sicelo | looks like it's fast getting to the WONTFIX state | 13:22 |
Wizzup | freemangordon: that won't help I think | 13:23 |
uvos | yeah looks like they are just fine with perf colapsing by 10 :( | 13:27 |
uvos | *10x | 13:27 |
bencoh | freemangordon: I haven't tried since yesterday's failure yet | 13:50 |
freemangordon | uvos: yeah :( | 13:57 |
bencoh | freemangordon: "We believe it might be related to the $subject" we already know that it's not gl-related, right? | 13:58 |
Wizzup | still they must fix gles | 13:59 |
bencoh | yup | 13:59 |
bencoh | agreed | 13:59 |
bencoh | hmm so, regarding building ff, what should we try? add some swap, or add memory to the VM? | 14:00 |
Wizzup | bencoh: do you need more ram? | 14:07 |
bencoh | I dunno, but killed gcc/g++ usually means that, lemme check dmesg | 14:07 |
Wizzup | maybe reduce the parallel jobs | 14:08 |
Wizzup | I can add a bit more ram too, but the system is at 26G/30G | 14:08 |
Wizzup | (the host) | 14:08 |
Wizzup | I extended the ram of the build machines to accomodate our webengine | 14:08 |
bencoh | cc1plus invoked oom-killer: | 14:09 |
bencoh | ah, I see | 14:09 |
bencoh | let's try .... | 14:09 |
Wizzup | bencoh: so I can add mor ram and reduce what we have on the build machines, just lmk | 14:12 |
bencoh | let's see first if it works | 14:12 |
Wizzup | ok | 14:13 |
* uvos laughs having 80gb to compile android | 14:58 | |
Guest224 | when I reading this channel log I found: 2023-01-22_14:46 <freemangordon> unfortunately it is normal. various reasons, one of the it runs from SD card. The other one is that Leste runs on 24 bpp while fremantle runs on 16bpp | 15:12 |
Guest224 | Why Leste run at 24 bpp, what mobile screen show more than 18 bpp? And many times real analog world color accurasity is less than 16 bpp. | 15:14 |
Guest224 | is there way to switch to 16 bpp to speed up screen handling? | 15:15 |
Guest224 | I mean screen analog world...not real physical world :) | 15:16 |
Guest224 | ofcourse..fastest screen handling is what screen wants in low level..any information what N900, Droid4 or Pinephone wants? | 15:20 |
Guest224 | if 16 color (4 bpp) grayscale speeds up then, it's enough for me :most of time :) | 15:27 |
sicelo | did it help? | 15:28 |
uvos | Guest224: the main thing is that 16bit color support is broken in lots of places on linux | 15:31 |
uvos | Guest224: also modern pannels that have true color depth in excess of 18 bit are absoulty not uncommon anymore | 15:32 |
uvos | Guest224: ofc me mainly focus on old and low end phones atm but still | 15:32 |
Guest224 | uvos: ok...in another though, all supported Leste devices support external display, what they can put there is another question :) | 15:36 |
Guest224 | putting N900 to CRT-TV would be nice ;D | 15:37 |
bencoh | iirc external display is already somewhat supported on leste/droid4, but there is no UI integration yet | 15:38 |
bencoh | regarding n900 I dunno if it's supported in current kernel versions | 15:38 |
uvos | i think on n900 someone reported it broken | 15:39 |
uvos | on mapphones it works fine | 15:39 |
uvos | just xrandr set the outptu | 15:39 |
uvos | t | 15:39 |
bencoh | uvos: does hildon handle two screens properly, or is it mirror-only? | 15:39 |
uvos | the n900 implementation is also pretty wierd | 15:39 |
uvos | since its not a real crtc | 15:39 |
uvos | bencoh: no you have to configure there to be only one display | 15:40 |
uvos | ie mirror or deactivate the internal pannel | 15:40 |
bencoh | ah, sad | 15:40 |
Guest224 | hmm..deactive internal panel actually sounds good if get more screen resolutions to external display. | 15:41 |
uvos | sure d4 can drive 1080p and performance is fine at this size too | 15:42 |
bencoh | d4 can even drive 1080p+internal panel | 15:42 |
bencoh | just not side-by-side, only one above the other | 15:42 |
uvos | well the hw can do side-by-side too | 15:42 |
bencoh | (unless that changed in the past few years) | 15:43 |
bencoh | uvos: last time I tried (years ago) it didn't work and reported something exceeding some limitation | 15:43 |
bencoh | but top/bottom screens worked | 15:43 |
sicelo | Guest224: yes tv-out is working in mainline | 15:44 |
bencoh | I think side-by-side means having an overall surface of more than 2048x2048 (1920+960) | 15:44 |
uvos | bencoh: hmm i think it worked for me before, but thats with i3 so maybe its texure size | 15:44 |
uvos | wich i3 dosent need | 15:44 |
uvos | but hildon would | 15:44 |
bencoh | I used wmii | 15:44 |
bencoh | (back then) | 15:44 |
Guest224 | is disk-images at /images/pinephone/20230122/ chimaera? or is there only devel chimaera? | 16:01 |
Guest224 | is hildon-connectivity-mobile included in images yet? | 16:05 |
bencoh | LLVM ERROR: out of memory | 16:08 |
bencoh | Allocation failed | 16:08 |
bencoh | Wizzup: with -j1 | 16:08 |
bencoh | (real 109m13.943s) | 16:08 |
Wizzup | bencoh: ok nwill fi | 16:17 |
Wizzup | ok will fix later today | 16:17 |
bencoh | :) | 16:18 |
bencoh | we could also add swap as fmg suggested | 16:18 |
bencoh | looks like the error occurs during the last stages | 16:18 |
Wizzup | no swap pls :p | 16:35 |
bencoh | okay :) | 16:46 |
* freemangordon still wonders what is wrong with swap :p | 16:47 | |
uvos | in general swap has gotten mutch less usefull | 16:54 |
uvos | due to the relatvie speed of io/ram/cpu | 16:54 |
uvos | but yeah, if it wont work otherwise, why not swap | 16:55 |
freemangordon | well, swap is the only thing that allows me to compile mesa on d4 | 17:10 |
bencoh | the crossbuilder works with mesa btw | 17:12 |
rafael2k | Wizzup, for pinephone, an .img chimaera to distribute | 17:20 |
rafael2k | I plan this week to have front camera enabled | 17:50 |
Wizzup | rafael2k: ok, I will try, I have some things I need to care of first, but I will try to build another img | 17:51 |
rafael2k | no rush then, lemme finish the kernel for chimaera then | 18:00 |
rafael2k | support for both cameras better than just one | 18:00 |
rafael2k | :P | 18:00 |
Wizzup | something came up today, I might not have a lot more time today | 18:01 |
rafael2k | Can I just use that one you made? | 18:02 |
rafael2k | people can just apt-get update/upgrade | 18:02 |
Wizzup | sure, that can work | 18:02 |
rafael2k | (I mean, distribute) | 18:02 |
rafael2k | Could you remind me the link of it? | 18:02 |
Wizzup | it's on maedevu images | 18:06 |
Wizzup | sorry, back later | 18:06 |
rafael2k | I wonder if this could help in order to have an USSD UI: https://github.com/mhogomchungu/ussd-gui | 18:50 |
sicelo | USSD should be handled by the phone application imo | 18:54 |
Wizzup | rafael2k: what protocol does this talk over | 18:55 |
rafael2k | AT | 18:55 |
Wizzup | hmm | 18:56 |
Wizzup | I am not sure if ofono likes it if others are reading its fd | 18:56 |
Wizzup | maybe it's fine | 18:56 |
rafael2k | we need to read from ofono | 18:56 |
bencoh | I played with libgammu for a while with my razr :) | 18:56 |
rafael2k | no no, we'll need to convert | 18:56 |
rafael2k | the point is that all the UUSD use cases are there, this saves time | 18:56 |
rafael2k | read/write from/to ofono | 18:57 |
Wizzup | ok | 18:57 |
rafael2k | I dunno, may be uvos can have an idea what would be best | 18:57 |
Wizzup | best regarding what? | 18:58 |
bencoh | completely unrelated, but wondering ... are we supposed to handle wifi networks (ssid) with multiple bssid well? | 19:00 |
Wizzup | no idea tbh | 19:00 |
bencoh | I dunno if that's the reason I'm having troubles here, but I suspect it is | 19:00 |
bencoh | I dunno how to debug that though | 19:01 |
bencoh | icd(?) has a tendancy to clear wpa_supplicant's config if I set it through wpa_cli | 19:01 |
sicelo | yes, expected :p | 19:01 |
sicelo | at least i think it is | 19:02 |
Wizzup | what does ssid with multiple bssid's mean | 19:02 |
bencoh | yeah, probably :> but still, how are we supposed to debug? | 19:02 |
Wizzup | that you have several APs with the same ap name? | 19:02 |
bencoh | Wizzup: exactly | 19:02 |
Wizzup | this should just work, we don't pin the bssid in the config | 19:02 |
Wizzup | so it will just pick whichever wpa supplicant prefers | 19:02 |
Wizzup | I think | 19:02 |
rafael2k | Wizzup, best with regards to have USSD at some point integrated, even if not so beautiful (not many people use, but those who use, really need it) | 19:03 |
bencoh | it remained connected for about an hour or so, and suddenly disconnected, and I wasn't able to reconnect since then, even after reboot | 19:03 |
bencoh | gonna try removing the network and adding it from scratch | 19:03 |
Wizzup | bencoh: that is weird, if you file a bug I can take a look at the code later | 19:03 |
bencoh | also wpa_supplicant seems slightly wonky, at some pointed it showed in scan_results a wifi network discovered this morning in the bus | 19:04 |
Wizzup | it should remove expired entries eventually | 19:04 |
bencoh | yeah, it removed it, but it popped back in at some point, for some reason | 19:05 |
bencoh | okay, so it just connected properly after removing the network from the connections list | 19:06 |
Wizzup | weird, I don't -think- we store bssid, but again, will have to check | 19:06 |
bencoh | do you want me to check that? | 19:06 |
Wizzup | sure, if you want to | 19:06 |
Wizzup | I have some personal things occupying me tonight so I won't be able to do much | 19:06 |
bencoh | https://github.com/maemo-leste/libicd-network-wpasupplicant ? | 19:07 |
Wizzup | yes | 19:07 |
bencoh | thanks :) | 19:07 |
sicelo | one thing that we do, which we probably shouldn't, is saving IP addresses in gconf for gprs (and possibly wifi?) | 19:09 |
Wizzup | I think we just use it as ipc | 19:10 |
Wizzup | to pass it on to the next module | 19:10 |
Wizzup | it's not a 'config' that much in that sense | 19:10 |
sicelo | ah, ok | 19:10 |
bencoh | apparently we include the mac_addr in the BssInfo at some point, not sure if it's stored or not yet | 19:12 |
bencoh | but supposedly we don't use mac_addr to match discovered networks against the configured networks | 19:13 |
Wizzup | btw, later I found that sailfish has some glib or qt bindings to wpasupplicant, found it three/four years later of course | 19:16 |
bencoh | :) | 19:17 |
Wizzup | bencoh: ram increased from 4GB to 14GB | 20:05 |
Wizzup | rafael2k: starting a new arm-sdk now | 20:09 |
Wizzup | for pp | 20:09 |
Wizzup | the image I mean | 20:09 |
bencoh | Wizzup: thanks a lot | 21:30 |
bencoh | let's see :) | 21:30 |
freemangordon | bencoh: please, when building, make sure there are debug symbols created. For some reason we don;t have sane dbgsym in debian repos http://debug.mirrors.debian.org/debian-debug/pool/main/f/firefox-esr/firefox-esr-dbgsym_102.7.0esr-1~deb11u1_armhf.deb | 23:02 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!