<rafael2k>
while not in pinhole yet, we can trigger the autofocus tru v4lctl
<rafael2k>
btw, support for the PPP is almost in good shape too
<rafael2k>
We'll need need some wiring up of control from libcamera, but the crew there is helping getting the needed controls wired up
<rafael2k>
the PPP has indeed a proper ISP
<rafael2k>
which is well supported by libcamera, through a specific pipeline configure (in the PP we just use the simple pipeline)
<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."
<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)?
<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
<rafael2k>
in the end. we could also ship with set already made an image for SD installation and another for eMMC
norayr has quit [Ping timeout: 246 seconds]
inky has joined #maemo-leste
ceene has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
akossh has joined #maemo-leste
inky has quit [Ping timeout: 252 seconds]
uvos has joined #maemo-leste
arno11 has joined #maemo-leste
<freemangordon>
sicelo: apn/username/password not being set issue should be fixed, please upgrade and confirm
<freemangordon>
the only remaining issue that's known to me is "always ask for password" tick not being obeyed
norayr has joined #maemo-leste
<Wizzup>
rafael2k: for pinephone?
<Wizzup>
(an image?)
<Wizzup>
I can do it in 4-5 hrs
<Wizzup>
freemangordon: I haven't figured out yet how to tell tp-ring not to do anon calls
<Wizzup>
there is a tp interface for it, but voicecalls from sfos does not seem to use it at all
<Wizzup>
maybe there is a tp ring config option that I missed or something
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
ceene has quit [Read error: No route to host]
ceene has joined #maemo-leste
<Wizzup>
freemangordon: I asked in #sailfish
<Wizzup>
sorry, #sailfishos
<sicelo>
great idea
<Wizzup>
hm, I think I might have figured it out
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
<Wizzup>
no, probably not, this needs to be addressed in voicecall-manager I think
<freemangordon>
Wizzup: where is #sailfishos ?
<Wizzup>
oftc
<freemangordon>
bencoh: did you manage to build ff?
<sicelo>
looks like it's fast getting to the WONTFIX state
<Wizzup>
freemangordon: that won't help I think
<uvos>
yeah looks like they are just fine with perf colapsing by 10 :(
<uvos>
*10x
pere has joined #maemo-leste
nela has joined #maemo-leste
<bencoh>
freemangordon: I haven't tried since yesterday's failure yet
<freemangordon>
uvos: yeah :(
<bencoh>
freemangordon: "We believe it might be related to the $subject" we already know that it's not gl-related, right?
<Wizzup>
still they must fix gles
<bencoh>
yup
<bencoh>
agreed
<bencoh>
hmm so, regarding building ff, what should we try? add some swap, or add memory to the VM?
<Wizzup>
bencoh: do you need more ram?
<bencoh>
I dunno, but killed gcc/g++ usually means that, lemme check dmesg
<Wizzup>
maybe reduce the parallel jobs
<Wizzup>
I can add a bit more ram too, but the system is at 26G/30G
<Wizzup>
(the host)
<Wizzup>
I extended the ram of the build machines to accomodate our webengine
<bencoh>
cc1plus invoked oom-killer:
<bencoh>
ah, I see
<bencoh>
let's try ....
<Wizzup>
bencoh: so I can add mor ram and reduce what we have on the build machines, just lmk
<bencoh>
let's see first if it works
<Wizzup>
ok
* uvos
laughs having 80gb to compile android
uvos has quit [Remote host closed the connection]
Guest224 has joined #maemo-leste
<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
<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.
<Guest224>
is there way to switch to 16 bpp to speed up screen handling?
<Guest224>
I mean screen analog world...not real physical world :)
<Guest224>
ofcourse..fastest screen handling is what screen wants in low level..any information what N900, Droid4 or Pinephone wants?
gliffy has joined #maemo-leste
xmn has joined #maemo-leste
<Guest224>
if 16 color (4 bpp) grayscale speeds up then, it's enough for me :most of time :)
<sicelo>
did it help?
uvos has joined #maemo-leste
<uvos>
Guest224: the main thing is that 16bit color support is broken in lots of places on linux
<uvos>
Guest224: also modern pannels that have true color depth in excess of 18 bit are absoulty not uncommon anymore
<uvos>
Guest224: ofc me mainly focus on old and low end phones atm but still
<Guest224>
uvos: ok...in another though, all supported Leste devices support external display, what they can put there is another question :)
<Guest224>
putting N900 to CRT-TV would be nice ;D
<bencoh>
iirc external display is already somewhat supported on leste/droid4, but there is no UI integration yet
<bencoh>
regarding n900 I dunno if it's supported in current kernel versions
<uvos>
i think on n900 someone reported it broken
<uvos>
on mapphones it works fine
<uvos>
just xrandr set the outptu
<uvos>
t
<bencoh>
uvos: does hildon handle two screens properly, or is it mirror-only?
<uvos>
the n900 implementation is also pretty wierd
<uvos>
since its not a real crtc
<uvos>
bencoh: no you have to configure there to be only one display
<uvos>
ie mirror or deactivate the internal pannel
<bencoh>
ah, sad
<Guest224>
hmm..deactive internal panel actually sounds good if get more screen resolutions to external display.
<uvos>
sure d4 can drive 1080p and performance is fine at this size too
<bencoh>
d4 can even drive 1080p+internal panel
<bencoh>
just not side-by-side, only one above the other
<uvos>
well the hw can do side-by-side too
<bencoh>
(unless that changed in the past few years)
<bencoh>
uvos: last time I tried (years ago) it didn't work and reported something exceeding some limitation
<bencoh>
but top/bottom screens worked
<sicelo>
Guest224: yes tv-out is working in mainline
<bencoh>
I think side-by-side means having an overall surface of more than 2048x2048 (1920+960)
<uvos>
bencoh: hmm i think it worked for me before, but thats with i3 so maybe its texure size
<uvos>
wich i3 dosent need
<uvos>
but hildon would
<bencoh>
I used wmii
<bencoh>
(back then)
lexik has quit [Ping timeout: 260 seconds]
lexik has joined #maemo-leste
<Guest224>
is disk-images at /images/pinephone/20230122/ chimaera? or is there only devel chimaera?
<Guest224>
is hildon-connectivity-mobile included in images yet?
<bencoh>
LLVM ERROR: out of memory
<bencoh>
Allocation failed
<bencoh>
Wizzup: with -j1
<bencoh>
(real 109m13.943s)
uvos has quit [Ping timeout: 260 seconds]
ceene has quit [Ping timeout: 260 seconds]
<Wizzup>
bencoh: ok nwill fi
<Wizzup>
ok will fix later today
<bencoh>
:)
<bencoh>
we could also add swap as fmg suggested
<bencoh>
looks like the error occurs during the last stages
uvos has joined #maemo-leste
<Wizzup>
no swap pls :p
Guest224 has quit [Quit: Client closed]
<bencoh>
okay :)
* freemangordon
still wonders what is wrong with swap :p
<uvos>
in general swap has gotten mutch less usefull
<uvos>
due to the relatvie speed of io/ram/cpu
<uvos>
but yeah, if it wont work otherwise, why not swap
uvos has quit [Ping timeout: 260 seconds]
<freemangordon>
well, swap is the only thing that allows me to compile mesa on d4
<bencoh>
the crossbuilder works with mesa btw
<rafael2k>
Wizzup, for pinephone, an .img chimaera to distribute
mardy has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 264 seconds]
<rafael2k>
I plan this week to have front camera enabled
<Wizzup>
rafael2k: ok, I will try, I have some things I need to care of first, but I will try to build another img
<rafael2k>
no rush then, lemme finish the kernel for chimaera then
<rafael2k>
support for both cameras better than just one
<rafael2k>
:P
<Wizzup>
something came up today, I might not have a lot more time today
<rafael2k>
Can I just use that one you made?
<rafael2k>
people can just apt-get update/upgrade
<Wizzup>
sure, that can work
<rafael2k>
(I mean, distribute)
<rafael2k>
Could you remind me the link of it?
<Wizzup>
it's on maedevu images
<Wizzup>
sorry, back later
Twig has joined #maemo-leste
gliffy has quit [Quit: Leaving]
k1r1t0 has quit [Read error: Connection reset by peer]
<sicelo>
USSD should be handled by the phone application imo
<Wizzup>
rafael2k: what protocol does this talk over
<rafael2k>
AT
<Wizzup>
hmm
<Wizzup>
I am not sure if ofono likes it if others are reading its fd
<Wizzup>
maybe it's fine
<rafael2k>
we need to read from ofono
<bencoh>
I played with libgammu for a while with my razr :)
<rafael2k>
no no, we'll need to convert
<rafael2k>
the point is that all the UUSD use cases are there, this saves time
Twig has joined #maemo-leste
<rafael2k>
read/write from/to ofono
<Wizzup>
ok
<rafael2k>
I dunno, may be uvos can have an idea what would be best
<Wizzup>
best regarding what?
<bencoh>
completely unrelated, but wondering ... are we supposed to handle wifi networks (ssid) with multiple bssid well?
<Wizzup>
no idea tbh
<bencoh>
I dunno if that's the reason I'm having troubles here, but I suspect it is
<bencoh>
I dunno how to debug that though
<bencoh>
icd(?) has a tendancy to clear wpa_supplicant's config if I set it through wpa_cli
<sicelo>
yes, expected :p
<sicelo>
at least i think it is
<Wizzup>
what does ssid with multiple bssid's mean
<bencoh>
yeah, probably :> but still, how are we supposed to debug?
<Wizzup>
that you have several APs with the same ap name?
<bencoh>
Wizzup: exactly
<Wizzup>
this should just work, we don't pin the bssid in the config
<Wizzup>
so it will just pick whichever wpa supplicant prefers
<Wizzup>
I think
<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)
<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
<bencoh>
gonna try removing the network and adding it from scratch
<Wizzup>
bencoh: that is weird, if you file a bug I can take a look at the code later
<bencoh>
also wpa_supplicant seems slightly wonky, at some pointed it showed in scan_results a wifi network discovered this morning in the bus
<Wizzup>
it should remove expired entries eventually
<bencoh>
yeah, it removed it, but it popped back in at some point, for some reason
<bencoh>
okay, so it just connected properly after removing the network from the connections list
<Wizzup>
weird, I don't -think- we store bssid, but again, will have to check
<bencoh>
do you want me to check that?
<Wizzup>
sure, if you want to
<Wizzup>
I have some personal things occupying me tonight so I won't be able to do much
<bencoh>
freemangordon: in what way aren't they sane?
<bencoh>
real 104m50.788s - Success! \o/
<bencoh>
-rw-r--r-- 1 bencoh bencoh 9.5M Jan 25 23:18 ../firefox-esr-dbgsym_102.7.0esr-1~deb11u1_armhf.deb
<bencoh>
9.5M sounds .... tiny
<bencoh>
and looks like my build gave a very similar results ... now I see what you meant
<bencoh>
now ... I need a way to do a partial build if we want to patch that thing ...
<Wizzup>
dpkg-buildpackage -b -uc -nc ?
<bencoh>
yeah, but it doesn't always work .... we'll see
<bencoh>
yeah, I add a static int variable in glxtest.cpp and tried dpkg-buildpackage -b -uc -nc but it didn't do much, apart from checking the previously built package