sixwheeledbeast has quit [Ping timeout: 246 seconds]
sicelo has quit [Ping timeout: 240 seconds]
sicelo has joined #maemo-leste
sicelo has joined #maemo-leste
elastic_dog has quit [Ping timeout: 252 seconds]
adm1sha has joined #maemo-leste
adm1sha has quit [Client Quit]
elastic_dog has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
freemangordon: i tried to change xorg bpp to 16 and h-d is definitely smoother, unfortunately many apps are not working properly (black screen with conversations, mplayer and others)
<arno11>
cpu usage in general is better
k1r1t0_N900 has quit [Ping timeout: 240 seconds]
k1r1t0_N900 has joined #maemo-leste
norly has quit [Server closed connection]
norly has joined #maemo-leste
<arno11>
(to use 16 bpp, i edited 99-omap.conf.leste and added Defaultdepth 16 in screen section, so maybe it isn't the correct way)
<arno11>
(xdpyinfo return 16 planes instead of 24)
<arno11>
(so it seems ok)
<freemangordon>
arno11: aor add -depth 16 to xorg startup script
<freemangordon>
*or
<freemangordon>
should be the same though
<freemangordon>
so, qt applications does not work on 16bpp?
<freemangordon>
that would be strange
<arno11>
yes most of them
<freemangordon>
I'll try to switch my VM to 16 bpp to see what's going on
<arno11>
ok
bencoh has quit [Changing host]
bencoh has joined #maemo-leste
<bencoh>
which vo do you use with mplayer?
<arno11>
xv
<arno11>
i tried with others, same result
pere has quit [Ping timeout: 252 seconds]
<arno11>
ah video is running but not displaying (cpu @100%)
<freemangordon>
maybe a bug ion omap DDX
<freemangordon>
16bpp does not work in virtualbox 6.0 :(
<arno11>
ah ok
<freemangordon>
lemme try on d4
<arno11>
ok
lel has quit [Ping timeout: 240 seconds]
lel has joined #maemo-leste
<freemangordon>
yeah:
<freemangordon>
PVRDRI2ObjectCacheInsert: DRI buffer format doesn't match drawable format
freemangordon has quit [Server closed connection]
freemangordon has joined #maemo-leste
<arno11>
ok, is it omap kernel stuff or something possible to solve easely ?
<freemangordon>
not kernel, but if it is easy to be solved... hard to say
<arno11>
ok
pere has joined #maemo-leste
<freemangordon>
btw mpv works on 16bpp
<freemangordon>
with gpu vo
<arno11>
ah ok cool but weird it works and not mplayer
<freemangordon>
xv seems to have issues
<freemangordon>
lemme try something
<arno11>
ok
<freemangordon>
ok, maybe I have a fix for that
<arno11>
cool :)
<arno11>
(i tried to monitor picodrive and return XVideo error as well)
<freemangordon>
xv does not support 16bpp currently
<arno11>
ok
<arno11>
brb (switching device)
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
<freemangordon>
arno11: please upgrade, reboot and try again
<freemangordon>
gst glimagesink is still broken, but that's a bug in gst
<arno11>
ok let's go
norayr has quit [Server closed connection]
<freemangordon>
bbl
arno11 has left #maemo-leste [#maemo-leste]
Juest has quit [Server closed connection]
Juest has joined #maemo-leste
norayr has joined #maemo-leste
sch has quit [Ping timeout: 245 seconds]
mrkrisprolls has quit [Ping timeout: 246 seconds]
sch has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
ac_laptop has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<ac_laptop>
Hello people, Maemo-leste is great but I don't think I will use it as my main OS yet, it seems the battery is draining out pretty fast, I need to make further tests but so far it looks like it lasts less than a day. And when I'll use a U3 microSD it will probably be even worse. So I'll probably stick with regular Maemo, I just need to find a way to keep a few programs
<ac_laptop>
not-completely-out-of-date
<Wizzup>
many people have tried to do this on regular fremantle and have failed time and time again :)
<Wizzup>
but yes, power management isn't up to fremantle levels yet
<ac_laptop>
Wizzup: even if power management was as good as in fremantle I suppose that the fact that the OS is on a mSD card is draining a lot of power
<Wizzup>
no, that's not the power draw for sure
Daanct12 has quit [Quit: WeeChat 4.1.1]
enyc has quit [Ping timeout: 260 seconds]
enyc has joined #maemo-leste
danielinux has quit [Server closed connection]
danielinux has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Client Quit]
Wizzup has quit [Server closed connection]
Wizzup has joined #maemo-leste
<maxwelld>
ac_laptop, i would say - try to port/package/build (if you are from the field) fremantle programs you use to leste.
<maxwelld>
also we have some software here that is not available on fremantle.
<maxwelld>
plus up to date contemporary debian repos.
<ac_laptop>
maxwelld: it's the opposite way: leste suits my needs, it just drains to much battery. I guess I'll stick to fremantle on a daily and reboot to leste only when I have a very specific need. Or I'll carry a secondary battery with me all the time, we'll see.
<ac_laptop>
on a daily basis*
<Wizzup>
if you have sw skills there are things you can do to improve pm btw
<Wizzup>
it's mostly just some drivers that are blocking idle
<maxwelld>
nokia had open sourced kernel patches no? and i guess we have those in our kernel?
<bencoh>
Wizzup: do we know which?
<bencoh>
maxwelld: nokia's kernel is opensource yeah
<maxwelld>
why then our kernel has worse pm?
<maxwelld>
some new features need special handling?
<bencoh>
usually it's the other way around
<bencoh>
some new kernel infra breaks the way the non-merged drivers worked, so they're not imported as-is, and/or even if they are they don't play nice with the rest of the system
<bencoh>
or they're just re-implemented and some pm details are missed
<bencoh>
and overall mainline kernels behave poorly when it comes to pm on many (most?) platforms, afaict
<Wizzup>
sicelo: did we ever figure out why the n900 would panic/reset in off mode? I think you were working on it
<Wizzup>
bencoh: but basically trying to hit RET would be a great improvement, we don't hit it on n900 yet
<Wizzup>
and then as soon as we do that we might see some drivers become unstable in RET, like the display driver / led driver
<Wizzup>
then we have to fix that
<Wizzup>
and then once we get ret stable, we can try to aim for off mode, which will then also make certain drivers behave unstable
<Wizzup>
we can hit OFF now without X11/leste loaded, but it will eventually reset, and we can hit RET in leste, but certain drivers misbehave
<bencoh>
I bet part of the components would lose their reg values after hitting OFF
<bencoh>
it might be a similar issue with RET btw
<Wizzup>
yes
<Wizzup>
it sounds like you've fix it in no time ;)
<Wizzup>
you'd fix it*
<Wizzup>
I only say yes because I've seen something like that happen I think
pere has quit [Ping timeout: 268 seconds]
<bencoh>
Wizzup: nah, I mentioned it because I've seen it happen (and worked around it) on other platforms, that's all
<Wizzup>
I don't know how to work around it :)
<bencoh>
well, on some platforms, the trick is to save the regs value before hitting the deep idle/sleep state, and restore it after all
<bencoh>
along with taking care of special cases
aat596_3 has quit [Server closed connection]
aat596_3 has joined #maemo-leste
ahmed_sam has joined #maemo-leste
ahmed_sam has quit [Read error: Connection reset by peer]
sch has quit [Ping timeout: 268 seconds]
sch has joined #maemo-leste
arno11 has joined #maemo-leste
fab_ has joined #maemo-leste
Pali has joined #maemo-leste
<arno11>
ac_laptop: On leste with oveclock (125Mhz removed), battery is empty in around 10h in use. Not sure Fremantle does a lot better with similar softwares.
<arno11>
of course i'm not talking about idle :)
k1r1t0 has quit [Ping timeout: 260 seconds]
<freemangordon>
arno11: did you try the new omap DDX?
<arno11>
freemangordon: yes it works ! thx
<freemangordon>
cool
<arno11>
no more issue with xv
<arno11>
:)
<freemangordon>
anything else that does not seem working?
<arno11>
yes conversations
<freemangordon>
besides glimagesink in gst
<freemangordon>
hmm
<freemangordon>
those should not have any issues
<arno11>
still black screen in 16 bits
<arno11>
weird
<ac_laptop>
I've tried to use leste while the N900 was charging and there was a message about the battery usage rate being faster than the battery charge rate
<freemangordon>
dsc_: any idea what could be the issue?
<arno11>
ac_laptop: yes it happens sometimes but no real issue
<ac_laptop>
also when in charge the battery icon goes to 100% (or nearly 100%, I can't tell) and I never get the green LED indicating full charge, is it normal or do I just not wait long enough ?
<arno11>
maybe your battery is not calibrates enough ?
<arno11>
*calibrated
<arno11>
freemangordon: seems everything else working :)
<freemangordon>
good
<freemangordon>
how's the performance?
<arno11>
let's say 30% better with stock freqs
<arno11>
and really good with overclock
<freemangordon>
not bad
<dsc_>
arno11: conversations yields a black screen?
<freemangordon>
dsc_: do you use QGrachicsScene etc?
<ac_laptop>
The thing is, if I switch regularly between fremantle and leste, does it mess up battery calibration ?
<dsc_>
freemangordon: no but I can imagine QtQuick does various graphics related things
<dsc_>
I'm not following, arno has latest conversations on d4 and there is only a black screen?
<sicelo>
ac_laptop: no. the fuel gauge keeps the calibration info (unless you allow it to get reset by keeping battery out for long enough)
<ac_laptop>
sicelo: ok
<arno11>
dsc: black screen on n900 and apparently on d4 according to fmg
<freemangordon>
dsc_: this is when we switch xorg depth to 16 bpp
<freemangordon>
QtQuick is qml, no?
<dsc_>
yes
<freemangordon>
lemme try to start it without GL
<dsc_>
btw im not even sure if it actually uses GPU drivers or a software renderer
<dsc_>
but this is unrelated
<ac_laptop>
also there is this thing you're probably aware of : when I shutdown from leste, Xorg crashes, then an error message displays with the screen not backlit, and then the device shuts down after a minute or two
<freemangordon>
it should use GPU and yes, I think it is related
<dsc_>
I think you can confirm that with `QT_LOGGING_RULES=qt.qpa.gl=true QSG_INFO=1`
<freemangordon>
dsc_: any idea where ""0x0 (0 DPI)"" message comes from?
<dsc_>
as for color space, there is `QT_QPA_EGLFS_DEPTH` but thats eglfs stuff
<freemangordon>
but somehow seems screen size is 0x0 :)
<freemangordon>
hmm, it outputs the same in VM, so I guess htis is harmless
<ac_laptop>
ok I switched to fremantle and plugged the charger and the LED went green very quickly so two possibilities: either the device was charged to 100% but leste wouldn't light the LED green, or leste was stuck at 99% charge for some reason
<sicelo>
fremantle doesn't wait for 100%, while kernel does :-)
<freemangordon>
dsc_: anything else I could check?
<dsc_>
freemangordon: I included those variables in mainwindow just for debugging purposes, I do not use them throughout the program
<dsc_>
i'm not sure what could cause this specific issue
<freemangordon>
something with the rendering
<freemangordon>
dsc_: why do you need to parse system theme?
<freemangordon>
like, qt already does that
<Wizzup>
qml does not
<dsc_>
QPalette does not offer enough colors
<dsc_>
hildon theme config have more
<freemangordon>
Wizzup: it is not only about colors, but about sapwood engine
<dsc_>
I was having trouble working with the limited colors offered by qpallete
<freemangordon>
ok
<dsc_>
it did work though, but the QML needed a bit more
<dsc_>
so I parsed them directly
<Wizzup>
freemangordon: conversations starts ok for me
<Wizzup>
no black screen
<Wizzup>
on d4
<freemangordon>
Wizzup: 16 bpp ;)
<freemangordon>
xorg is started with -depth 16
<Wizzup>
on your d4?
<freemangordon>
mhm
<Wizzup>
aha
<tmlind>
i may have v6.6 patches rebased finally.. let's see, boot testing..
<freemangordon>
:)
<arno11>
freemangordon: i didn't notice that cpu usage seems to decrease a lot in 16bpp, really cool
<tmlind>
freemangordon: had to leave out your "WIP: Forward port of droid4 stock kernel changes to prevent tearing" patch, it conflicts with the xt912 lcd additions and i did not know of the current status of it
<freemangordon>
tmlind: ok, I will have a look at it when have to
<freemangordon>
dsc_: BTW, the same issue with LIBGL_ALWAYS_SOFTWARE=1
<tmlind>
freemangordon: ok thanks. if this pile works, then maybe uvos can merge in the remaining pending patches to the m-l kernel, i'll try to send out the basic dts and echi changes this coming weekend
<dsc_>
interesting enough today I am debugging mesa/eglfs Qt issues on some other hardware
<tmlind>
uvos: i think i got some initial follow_pte() change done, not sure if it needs more checks for the addresses
<freemangordon>
dsc_: failing with both mesa and pvr would mean it is some qt fault
<freemangordon>
hmm, lemme try another theme
<Wizzup>
what theme do you have?
<freemangordon>
sorry I meant 'style'
<freemangordon>
the same happens with windows and gtk2 theme
<dsc_>
this issue is a bit bizarre freemangordon
<dsc_>
Qt should support that depth fine
<freemangordon>
right
<freemangordon>
actually qt does
<freemangordon>
like "new message" opens proper window
<dsc_>
maybe because Qt was compiled against a different depth it cannot switch to another
<dsc_>
?
<dsc_>
would be weird, just thinking out loud
<freemangordon>
dsc_: looks like some qtquick issue
<freemangordon>
dsc_: is there some simple qtquick application I can use for testing?
<dsc_>
because the first one uses QML's ApplicationWindow{}, dont know if Hildon can do that
<dsc_>
should be fine though
<freemangordon>
dsc_: looks fine to me
<freemangordon>
a grey rectangle with some 'display' icon in it
<freemangordon>
so seems some issue in conversations
<freemangordon>
lemme try the other application as well
uvos has joined #maemo-leste
<uvos>
freemangordon: i would like to note that lots of things dont work in 16bit mode even on modern linux desktop
<freemangordon>
right, but qt should work
<freemangordon>
qt/qml
<dsc_>
ah interesting
<uvos>
freemangordon: on arch radeon: no rending engine works, qwebengine is just black, firefox is extreamly slow because it renders in 32bit and downconverts in software, chrome is black
<uvos>
qwebengine being just black is suspicous
<uvos>
since it uses the same rendering engine in the end as qml
<uvos>
know any qml desktop app i can install?
<uvos>
thats likely in the repos
<dsc_>
freemangordon: however, do try that second one, because that one creates a QML widget *inside* a QtWidgets window
<dsc_>
just for testing
<dsc_>
and conversations also does this
<freemangordon>
yes, that one has issue
<freemangordon>
uvos: qtwebbrowser works though
<uvos>
hmm ok wierd
peetah has quit [Server closed connection]
<freemangordon>
dsc_: so embedding qml in qwidget seems buggy
peetah has joined #maemo-leste
<uvos>
liri calculator also works in 16bit
<uvos>
(qml)
<bencoh>
they do all render in the same way though?
<freemangordon>
uvos: pure qml works fine
__20h__ has quit [Server closed connection]
<freemangordon>
it seems there is issue when you embed qml in qwidget
__20h__ has joined #maemo-leste
<freemangordon>
lemme check in qt bugtracker
<uvos>
mean while in 8bit mode the only thing i have found that works is sphone (gtk2)
<uvos>
(im just messing around i know)
<bencoh>
:D
<freemangordon>
heh
<uvos>
openbox also works in 8bit
<uvos>
freemangordon: yeah ill fix that (licence)
<bencoh>
silly question, does xdpyinfo reports a different scanline_pad when reducing xorg depth?
<uvos>
copy-paste
<bencoh>
(from 24 to 16 for instance)
<uvos>
depth 8, bits_per_pixel 8, scanline_pad 32
<bencoh>
interesting
<bencoh>
hmm, maybe not, that's just the stride alignment, probably
<bencoh>
(in bytes)
<uvos>
would be cool if we could get 16bit mode working globaly, 32bits is so pointless on a phone
<freemangordon>
totally agree
<uvos>
but its not really a winnable battle i fear
<uvos>
maybe on n900 it is
<freemangordon>
at least we can try
<uvos>
since it cant run bloated modern stuf anyhow
<dsc_>
< freemangordon> dsc_: so embedding qml in qwidget seems buggy <== ehh, yeah... no idea!
<dsc_>
maybe the QML works but its just a sizing issue
<dsc_>
i.e: it is not expanding
<dsc_>
within its container
<ac_laptop>
are there keyboard shortucuts available by default on fremantle which are not present on a leste fresh install ?
akossh has joined #maemo-leste
<uvos>
its more likely imo that the qml embeding is rendered to a texture in this case that is then drawn by qwidgets
<dsc_>
freemangordon: I would imagine you would also get various QML errors if that was really broken
<uvos>
and this pipeline just assumes 8bits per color somewhere
<dsc_>
man, I spent half a day figuring out why Qt was not using 3d acceleration only to find out I needed to 'turn on the GPU' via some system utility
<bencoh>
duh
<dsc_>
xD
<bencoh>
is that qt5 btw?
<freemangordon>
uvos: that would be really strange if qt does not support 16 bpp properly
<freemangordon>
bencoh: yes
<dsc_>
bencoh: qt6 in this case
<freemangordon>
5.15
<dsc_>
oh, nvm
<bencoh>
hmm
<bencoh>
ah
<freemangordon>
5.15.2
<uvos>
i maen it "supports" 16 bit mode
<uvos>
it would not suprise me if it gets essentaly no testing however
<freemangordon>
dsc_: how to make debug build when using cmake?
<uvos>
-DCMAKE_BUILD_TYPE
<dsc_>
CMAKE_BUILD_TYPE=Debug
<uvos>
=Debug
<dsc_>
-DCMAKE_BUILD_TYPE=Debug
<freemangordon>
thanks :)
<dsc_>
it may also need -DCMAKE_CXX_FLAGS=-O...
<dsc_>
not sure
<uvos>
Debug adds -g , which i gues fmg is after, unless the cmake script overrides the default
<dsc_>
aye
<ac_laptop>
I've just noticed that when booting on leste I have /boot on mmcblk0p1 , / on mmcblk0p2 , and swap on mmcblk*1*p3
<ac_laptop>
and I don't see any mmcblk*0*p3
<uvos>
wich is a problem why? and what device?
<ac_laptop>
I assume mmcblk1 designates the eMMC since the 3 partitions are respectively fat32, ext3 ans linux-swap
<ac_laptop>
and mmcblk0 is the mSD card, but it has only 2 partitions, no swap
<uvos>
yes thats correct for n900
<ac_laptop>
flashing the image on the microSD (via dd ) must create a swap on the mSD, right ?
<uvos>
but you really need to specify the device when asking questions
<uvos>
no
<ac_laptop>
oh sorry N900
<uvos>
why?
TheTechRobo has quit [Server closed connection]
<sicelo>
for swap, leste is using zram, but you can also just activate the existing swap on mmcblk*1*p3
<uvos>
the emmce is mutch faster so swaping there has advantages
TheTechRobo has joined #maemo-leste
<uvos>
i thought we disabled zram on n900?
<arno11>
and swap on emmc is supposed to be activated automatically in recent images
<ac_laptop>
uvos: ok, I had read some old manual procedures before flashing which were talking about putting the swap on the mSD and I assumed the lest image did the same :)
<uvos>
you can do that
<uvos>
if you have a fast sdcard you can beat emmc on random writes (by a wide margin)
tmlind has quit [Server closed connection]
<uvos>
but for sequental stuff emmc will win since its on a faster bus
tmlind has joined #maemo-leste
<ac_laptop>
uvos: what type of card are we talking about ? I'm using an class10 U1 (planning to try a class10 U3 in the next few days)
<uvos>
ac_laptop: mostly application class / uhs cards
<bencoh>
or they're just terrible at random writing
<bencoh>
looks like sandisk and lexar have opposite optimization/tuning goals
<sicelo>
i don't think we've also benchmarked how efficiently we're driving the uSD on N900. won't be surprised if there's lots of room for improvement
<uvos>
on d4 at least i can see these numbers
<bencoh>
for real ?
<uvos>
ie my sd extream can peg the bus at pretty mutch all times
<ac_laptop>
which card would you advise based on those numbers ?
<uvos>
well i bought a SanDisk Extreme A1
<uvos>
but its overkill
<uvos>
as i said it pegs the bus even down to pretty small random writes
<uvos>
i gues it helps with really small randoms
<uvos>
but you can likely get something cheaper that will still peg the bus most of the time
<uvos>
i doubt it helps on n900 anyhow
<uvos>
the cpu is so slow i doubt it helps mutch if the data comes in at full bus speed
<uvos>
you have to remember that the d4s cpu is 5x faster while its io speed is the same
<uvos>
so its mutch more io bound
<sicelo>
i want to debug ofono with gdb. i've run it's configure script with `--enable-debug`, and gdb is happy about the resulting binary. however, it seems that in the debug session, i am unable to list other parts of the code (the ones I'm interested in!)
<sicelo>
Single stepping until exit from function name_get_resp_cb, which has no line number information.
<sicelo>
any ideas? i guess the individual object files don't get built with the debug symbols :-/
<freemangordon>
do you build packge?
<freemangordon>
or you build with make?
<freemangordon>
is that on leste?
<sicelo>
build with make
<freemangordon>
on leste?
<freemangordon>
sicelo: ^^^
<sicelo>
currently, pmOS
<sicelo>
but i think it should be the same
<freemangordon>
you need to set CFLAGS="-O0 -g"
<freemangordon>
somehow
<freemangordon>
does it use meson or autotools?
<bencoh>
CFLAGS="-O0 -g" ./configure
<freemangordon>
mhm
<bencoh>
(and add whatever configure flag)
<freemangordon>
if it does not use meson ;)
<sicelo>
autotools :-)
<sicelo>
i just cloned the upstream repository
<freemangordon>
ok
<freemangordon>
bencoh: I was thinking CFLAGS are passed to configure as parameter
<freemangordon>
not as env var
<sicelo>
let me retry with the CFLAGS in front. i had done it as a param before (as suggested in ofono /INSTALL)
<freemangordon>
sicelo: could you pastebin ./configure --help
<bencoh>
freemangordon: I usually export CFLAGS in env before running configure, or use it the way I mentioned
<freemangordon>
ok
<tmlind>
hmm console lcd not refreshing and audio not working.. need to fix those first before i push out anything
<uvos>
tmlind: context?
<freemangordon>
linux 6.6
<uvos>
device?
<uvos>
6.6 works perfectly here besides audio
<sicelo>
my last test was with the following: `./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --sbindir=/usr/sbin --enable-external-ell --with-dbusconfdir=/usr/share --disable-bluetooth --disable-phonesim --disable-rilmodem --disable-qmimodem --disable-mbimmodem --enable-bluez4=no --enable-test --enable-tools --enable-debug CFLAGS="-ggdb -g3"`
<sicelo>
linux 6.6 working fine on N900 too (only thing i haven't tested is pvr)
<uvos>
tmlind: what do you mean with not refeshing?
<uvos>
i see the kernels scroll during boot
<ac_laptop>
If I wanted to create a shared space on the microSD card accessible from both fremantle and leste, I would have to create a FAT32 partition I suppose ?
<bencoh>
ac_laptop: fremantle reads ext3 just fine
<freemangordon>
sicelo: do as bencoh said (env var)
<ac_laptop>
bencoh: I'm asking because every time I boot on fremantle I get a message "card not recognised" or something like this
<bencoh>
(if you set your env var outside of the configure command, don't forget to export it)
<freemangordon>
ac_laptop: maybe some new ext3/4 option not supported by fremantle kernel
<bencoh>
ac_laptop: oh, that, right, yeah, it's fat32 ... I thought cssu removed that limitation at some point (?)
<ac_laptop>
maybe it's just the ext4 space that fremantle doesn't like but I wanted to be sure there wasn't anything else
k1r1t0_N900 has quit [Ping timeout: 245 seconds]
<freemangordon>
bencoh: ext3 is supported to the extend it is supported by 2.6.28 :)
<ac_laptop>
like the partition scheme, partition type, LVM or anything like that
<sicelo>
rebuilding - on N900 :p
<freemangordon>
ugh
<bencoh>
(why, oh why, when we have an lxc/qemu-based build system :>)
<freemangordon>
bencoh: please, share instructions for cross-building
<tmlind>
uvos: the lcd does not refresh on pressing enter or any key at the login prompt without a gui started
<tmlind>
uvos: mcbsp3 complains about dma channels on one d4 but not on the other..
<uvos>
tmlind: yeah i did see the latter
<sicelo>
ac_laptop: i've seen other mobile OSes try them with excitement ... then eventually returning to ext3/4
<uvos>
tmlind: the former i dident see since it booted streight to hildon
<uvos>
ext3 is kinda a poor choice for a flash device
<ac_laptop>
sicelo: Android devices use F2FS on their internal memory, right ?
<uvos>
ac_laptop: some vendors do
<uvos>
ac_laptop: its not universal
<ac_laptop>
of course I'm talking about flash-optimized FS for the eMMC. The mSD card must have some translation layers and I don't expect any improvement on those
<freemangordon>
ac_laptop: eMMC has too
<uvos>
mSD cards and emmcs are the same
<uvos>
really
<uvos>
often the very same chips
<freemangordon>
n900 has onenand, but we don;t use it ATM for leste
<freemangordon>
where flash-optimized fs would make sense
pere has joined #maemo-leste
<sicelo>
still getting same gdb issue with CFLAGS="-O0 -g" as env var for configure
<freemangordon>
sicelo: please do that in leste
<freemangordon>
I can help then
<sicelo>
`info source` in gdb says, Producer is GNU C17 13.1.1 20230722 -mtune=generic-armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mabi=aapcs-linux -mtls-dialect=gnu -mthumb -march=armv7-a+fp -g -g -O0
<sicelo>
ok
<freemangordon>
wait
<freemangordon>
please pastebin backtrace
<freemangordon>
ugh
<freemangordon>
dsc_: with QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software); it works fine
<freemangordon>
bencoh: hmm, this is musl, maybe it needs LD_FLAGS as well?
<freemangordon>
umm, LDFLAGS
<freemangordon>
sicelo: better switch to leste, I will be able to provide help there
<sicelo>
i only want to trace the ofono parts though. name_get_resp_cb is in ofono code. don't i need the musl stuff if i want to step into those parts?
<freemangordon>
sicelo: sorry, don;t have time now to go through ofono code to see where you can store the data
<freemangordon>
will try to find time soon
<sicelo>
sure, no rush.
<ac_laptop>
one last question : is there any list of the daemons running on the system and why they are needed ? I'd like to know what happens if I get rid of pulseaudio, policykit or gvfs... will it inpact only some programs or will it break the whole system ?
<sicelo>
you need most of them. why would you consider removing them?
<ac_laptop>
ac_laptop: I usually do this on my desktop system after an install, remove the unnecessary stuff, but my desktop doesn't have the same constraints as the neo900 in terms of audio routing, notifications, etc. So if you tell me that pulseaudio is necessary I'll understand
k1r1t0_N900 has joined #maemo-leste
k1r1t0 has joined #maemo-leste
k1r1t0 has quit [Read error: Connection reset by peer]
<dsc_>
freemangordon: really weird
lightbringer has quit [Server closed connection]
lightbringer has joined #maemo-leste
lightbringer has joined #maemo-leste
lightbringer has quit [Changing host]
leste has joined #maemo-leste
udder has quit [Server closed connection]
udder has joined #maemo-leste
<arno11>
dsc: ah i just noticed same black screen bug in NOmWeather
<arno11>
in 16 bpp of course otherwise it's fine
<bencoh>
ac_laptop: if you don't need telephony at all and hildon stuff you could do without pulseaudio
asriel has quit [Ping timeout: 240 seconds]
asriel has joined #maemo-leste
fab_ has quit [Quit: fab_]
<dsc_>
arno11: why are you running on 16 bpp btw
<arno11>
just a test with fmg to improve n900 responsiveness