<uvos>
Note that there is no “thumb2” option. If the target processor is new enough, Thumb-2 will be used automatically.
<uvos>
hmm
<uvos>
so -march
<uvos>
something
<uvos>
not sure what
<uvos>
some thumb1 only proc i gues
<Wizzup>
sounds like we probably don't want to do that though
<uvos>
yeah
<Wizzup>
so one other problem I am trying to tackle is that gcc complains about some builds on the CI only
<Wizzup>
because the underlying cpu reports armv8
<Wizzup>
even though the instruction set is armv7
<Wizzup>
but I can't make it armv7 in qemu without losing KVM
<Wizzup>
(repor armv7)
<Wizzup>
so passing -march=armv7-a+neon-fp16 (or something) for armhf might solve that
<uvos>
why would that make gcc complain?
<Wizzup>
neon code
<Wizzup>
it detects armv8 cpu and decides that this code won't work there
<Wizzup>
even though we want it to build for armv7
<Wizzup>
it seems like at least from my search
<uvos>
ok
<Wizzup>
iirc n900 doesn't have vfpv4
<Wizzup>
in any case, we have an easy test bed to toy with this in -experimental for now
<uvos>
dosent armv8 have neon?
<Wizzup>
sure
<Wizzup>
but slightly different I guess
<uvos>
not sure why it would complain
<uvos>
ok
<uvos>
yeah no idea
<Wizzup>
ok, so CONFIG += plugin in qmake disables making .la files
<Wizzup>
*sigh*
<Wizzup>
uvos: is this a problem?
<Wizzup>
sphone: contacts-evolution: can currently only fill contacts of ofono calls
<Wizzup>
that is followed by:
<Wizzup>
sphone: sphone-mce: dbus call to mce faied with GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "req_vibrator_pattern_deactivate" with signature "s" on interface "com.nokia.mce.request" doesn't exist
<Wizzup>
oh, hum:
<Wizzup>
sphone: No backend for gui_dialer_show
<Wizzup>
ah:
<Wizzup>
sphone: Failed to load module ui-dialer-gtk: /home/user/sphone/build/src/modules/libui-dialer-gtk.so: cannot open shared object file: No such file or directory; skipping
<Wizzup>
ah it doesn't look in the gui/gtk2 path
<Wizzup>
well I guess the dialer launched
<Wizzup>
but my vm screen is now black
<Wizzup>
:D
<Wizzup>
(rotation)
pere has quit [Ping timeout: 260 seconds]
<Wizzup>
well I can get sphone to show when I call through tp and hang up
<Wizzup>
enough for tonight :)
uvos has quit [Ping timeout: 260 seconds]
Daanct12 has joined #maemo-leste
xmn has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #maemo-leste
Daanct12 has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 272 seconds]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
rafael2k has joined #maemo-leste
rafael2k has quit [Read error: Connection reset by peer]
rafael2k has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #maemo-leste
pere has joined #maemo-leste
<freemangordon>
uvos__: there is absolutely no difference in registry pressure ARM vs thumb2
<freemangordon>
the only thing that differs is instructions size (32 ARM vs 16 thumb2 bits) and slightly higher thumb2 decoding time
<freemangordon>
which is compensated by better code cache usage
<freemangordon>
as with thumb2 you have twice as much instructions per I cache line
<freemangordon>
in theory that is ofc :)
<freemangordon>
and yes, we want thumb2, not thumb1
<freemangordon>
Wizzup: hmm, 3986 vs 4022
<freemangordon>
something is wrong here
<freemangordon>
we should have ~ 30% down
<freemangordon>
and yes, we want -O2, not -Os
Daanct12 has quit [Remote host closed the connection]
<freemangordon>
lemme install and compare binary sizes
uvos has joined #maemo-leste
<freemangordon>
Wizzup: I think I know what happens - because build VM does not support thumb2, gcc has no option but to use thumb1, otherwise it won;t be able to run the tests
<freemangordon>
It might be even ignoring -mthumb at all and the slight difference in sizes comes from -mfpu=neon
<freemangordon>
ok, libglib .so has exactly the same size
<Wizzup>
/usr/lib/gcc/arm-linux-gnueabihf/10/include/arm_neon.h: In function 'int32x4_t vcvtnq_s32_f32(float32x4_t)':
<Wizzup>
/usr/lib/gcc/arm-linux-gnueabihf/10/include/arm_neon.h:1762:10: error: this builtin is not supported for this target 1762 | return (float32x4_t)__builtin_neon_vrintnv4sf (__a);
<Wizzup>
that in particular
<Wizzup>
anyway, that was just a guess
<Wizzup>
I will need to try it to be sure
<freemangordon>
and maybe add -mtune=cortex-a8
<Wizzup>
but basically marian-lite builds fine on d4
<Wizzup>
but not on ci
<freemangordon>
I see
<freemangordon>
yeah, test it
<dsc_>
< Wizzup> this is about build systems thinking we have a v8 cpu <== build systems think this because of gcc's compiler definitions
<Wizzup>
but those come from -march= no?
<dsc_>
unsure
<freemangordon>
you have built-in defaults
<freemangordon>
afaik
<dsc_>
yep
rafael2k has joined #maemo-leste
<freemangordon>
so maybe we want -march=marmv7-a -mtune=cortex-a8
<freemangordon>
for the other I doubt it matters that much for daily usage
<freemangordon>
if you dig crypto currencies maybe yes :)
<Wizzup>
I think really the hope was/is that it would either help with size or make things magically faster, i.e. scrolling in gtk2 or something, if it had some fast path :p
<freemangordon>
sicelo: so, please, install libicd-network-ofono from either chimaera or beowulf-devel (depending on what your device is on), gather new traces and provide that
<freemangordon>
please, also, capture dbus-monitor (if possible bothe session and system bus) logs as well that match those icd2 logs
<freemangordon>
SuperMarioSF: you may do as well ^^^
<dsc_>
note that list is half-arsed and does not claim to be complete :P
<Wizzup>
right, but just for everyone wondering, we don't use this anymore
<Wizzup>
no runtime detection
<Wizzup>
at least afaik
<dsc_>
yes, for Maemo Translate (and its dependencies) we just set `-mfpu=neon`
<dsc_>
but, only on arm 32bit (armv7)
<dsc_>
because AARCH64 implies NEON
<Wizzup>
right
<freemangordon>
so, to conclude and move on: do we agree on "-march=marmv7-a -mtune=cortex-a8 -mfpu=neon"?
<dsc_>
for the build machine?
<freemangordon>
yes
<freemangordon>
for 32bits arm
<dsc_>
looks good
<freemangordon>
that way we'll squeeze as much as possible from N900
<freemangordon>
with close to optimal for other devices
<freemangordon>
Wizzup: if you are fine with ^^^, please set-up that on chimaera (not experimental) and maybe rebuild a couple of packages
<dsc_>
im a bit surprised that only now the build machine has these specific flags for 32bit, this means compilations previously may not have been using neon optimally or whatever
<freemangordon>
we didn't check how it is on beowulf
<freemangordon>
but I would bet it is the same
<Wizzup>
freemangordon: ok, I'm waiting for the gtk test with -marm to finish
<Wizzup>
just for completion
<freemangordon>
ok
<Wizzup>
dsc_: for sure it wasn't using neon before, yes
alex1216 has quit [Ping timeout: 265 seconds]
<Wizzup>
this is probably also true for all debian pkgs
<freemangordon>
but only 'our' builds
<dsc_>
right, the ones from devuan were built with god knows what
<freemangordon>
no, I would guess vanilla deian packages are compiled with neon
<freemangordon>
*debian
<Wizzup>
freemangordon: then it won't work on some other devices
<Wizzup>
Programs usually take advantage of NEON thanks to hand-crafted assembly routines. GCC can automatically vectorize code and generate NEON instructions, however this tends to have limited success. It would seem sensible NOT to require NEON in a new port since some modern Armv7 ?SoCs such as Marvell Dove and NVidia Tegra2 don't implement it.
<Wizzup>
so no, probably not ;)
<freemangordon>
on chimaera it is requirement
<freemangordon>
I see why would beowul be different
<dsc_>
Wizzup: what do you mean 'we dont signal it'
<dsc_>
gcc signals that its armv7
<dsc_>
and some header files act on that
<dsc_>
see also `echo | gcc -dM -E - | grep -i arm`
<Wizzup>
what I am saying is that the current debian build system, and ours, do not signal neon support
<Wizzup>
so if somehing is compiled with neon it's because their build system does something special, e.g. compile both neon and non-neon paths and switch at runtime
<Wizzup>
which is probably what glibc does
<freemangordon>
wtf? where are gtk neon patches?
<Wizzup>
freemangordon: that was the next question :D
<norayr>
whatever dorian.pro has, it is not going to be picked up without debian/rules right?
<norayr>
ah no.
<norayr>
those are different things. rules has maemo qt something, probably, and my problem is how to make those maemo5 sections in .pro or .pri to be picked up.
<norayr>
they aren't. i have to move let's say 'opengl' to the regular QT += section for it to be picked up.
<Wizzup>
norayr: hence the -spec maemo
<Wizzup>
there is the maemo spec, which defines maemo5, and then you can do QT += maemo5
<Wizzup>
iirc
<norayr>
yeah, i just tried using your rules file, which is for debhelper, i guess, and now i have the errors that maemo orientation functions don't work. this is good probably.
<norayr>
and probably that is why in easylist my replacement functions didn't work.
<Wizzup>
which functions?
<freemangordon>
Wizzup: no need to pass anything to qmake
<freemangordon>
QT += maemo5 should be enough
<freemangordon>
along with build-dep
Twiggy has joined #maemo-leste
Twig has quit [Ping timeout: 265 seconds]
<Wizzup>
freemangordon: sure but -spec maemo is required to have maemo5 be defined in case you want to make maemo optional
Twiggy has quit [Ping timeout: 256 seconds]
<freemangordon>
what means 'optional' in this context?
<freemangordon>
BTW, shall I pick voicecall, in terms we discussed?
<freemangordon>
are you happy with it already?
<Wizzup>
freemangordon: I'm hoping to finish a proof of concept sphone module tonight, latest tomorrow
<Wizzup>
then it might make sense to send that in
<freemangordon>
ok
<Wizzup>
for us it won't matter at that point, of coures it's nice if they accept is
<norayr>
do you think i can/should change 'import Qt 4.8' with 'import QtQuick 2.3' in qml files?
<Wizzup>
sorry, I don't know how to fix qml
<Wizzup>
if you can fix it, you will also know how to fix openmediaplayer
<norayr>
good, before it was saying 'module Qt is not installed'. now it is saying different errors.
<norayr>
qrc:/qml/qflickr/QuickFlickrMain.qml:35:5: Type MainMenu unavailable
<norayr>
it is at runtime.
<norayr>
maybe i am not even asking, i am recording for public.
<Wizzup>
what module did you install to get rid of that error
<Wizzup>
and where did you see the error
arno11 has joined #maemo-leste
<Wizzup>
uvos: I got organicmaps to build on maemo
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
apart from qt style issues, it looks quite nice
<Wizzup>
I just downloaded an offline map, 50 MB
<Wizzup>
and it knows all the spots
mp107 has joined #maemo-leste
Twiggy has quit [Ping timeout: 265 seconds]
Twiggy has joined #maemo-leste
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 252 seconds]
hexagonwin has quit [Remote host closed the connection]
rafael2k_ has quit [Ping timeout: 260 seconds]
<Wizzup>
uvos: when does sphone actually detect that call is active?
<Wizzup>
uvos: I deal with the answer trigger the same as ofono, but it doesn't seem to pick it up
<Wizzup>
uvos: does the call->state need to be updated in the same function call?
<Wizzup>
it's nice to be able to use conversations for sms, with telepathy-ring going through sphone
<Wizzup>
:)
<Wizzup>
hopefully tomorrow night I have something stable-ish
alex1216 has quit [Ping timeout: 246 seconds]
akossh has quit [Quit: Leaving.]
rafael2k_ has joined #maemo-leste
Twiggy has quit [Remote host closed the connection]
uvos has joined #maemo-leste
<uvos>
as the bachend you own the call object
<uvos>
after adding the call via the call new pipe, if the call object cahnges in any way you must inform the rest of sphone via the state changed pipe
<uvos>
your also not supposed to just uncoditionally act on every call that comes down some pipe
<uvos>
only the ones targeted at a backend id you hold
<uvos>
the call test module is a easyer place to look at
<uvos>
since its mutch simpler
<uvos>
also remeber that any nummber of calls can be active at a time in sphone, and that they can be from different backends too
<uvos>
and dont use qDebug or any function other than the sphone_module_log macro
<uvos>
oh and you own the data
<uvos>
execute_datapipe never ever transfers owership
<uvos>
data is allways owend by the caller
<uvos>
and you should not need extern "C" around sphone headers anymore