| 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) | 10:27 |
|---|---|---|
| arno11 | cpu usage in general is better | 10:31 |
| 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) | 10:45 |
| arno11 | (xdpyinfo return 16 planes instead of 24) | 10:46 |
| arno11 | (so it seems ok) | 10:50 |
| freemangordon | arno11: aor add -depth 16 to xorg startup script | 10:55 |
| freemangordon | *or | 10:55 |
| freemangordon | should be the same though | 10:55 |
| freemangordon | so, qt applications does not work on 16bpp? | 10:55 |
| freemangordon | that would be strange | 10:55 |
| arno11 | yes most of them | 10:55 |
| freemangordon | I'll try to switch my VM to 16 bpp to see what's going on | 10:57 |
| arno11 | ok | 10:57 |
| bencoh | which vo do you use with mplayer? | 11:00 |
| arno11 | xv | 11:00 |
| arno11 | i tried with others, same result | 11:00 |
| arno11 | ah video is running but not displaying (cpu @100%) | 11:08 |
| freemangordon | maybe a bug ion omap DDX | 11:09 |
| freemangordon | 16bpp does not work in virtualbox 6.0 :( | 11:10 |
| arno11 | ah ok | 11:11 |
| freemangordon | lemme try on d4 | 11:13 |
| arno11 | ok | 11:14 |
| freemangordon | yeah: | 11:19 |
| freemangordon | PVRDRI2ObjectCacheInsert: DRI buffer format doesn't match drawable format | 11:19 |
| arno11 | ok, is it omap kernel stuff or something possible to solve easely ? | 11:29 |
| freemangordon | not kernel, but if it is easy to be solved... hard to say | 11:31 |
| arno11 | ok | 11:31 |
| freemangordon | btw mpv works on 16bpp | 11:39 |
| freemangordon | with gpu vo | 11:40 |
| arno11 | ah ok cool but weird it works and not mplayer | 11:41 |
| freemangordon | xv seems to have issues | 11:41 |
| freemangordon | lemme try something | 11:42 |
| arno11 | ok | 11:42 |
| freemangordon | ok, maybe I have a fix for that | 11:50 |
| arno11 | cool :) | 11:51 |
| arno11 | (i tried to monitor picodrive and return XVideo error as well) | 11:52 |
| freemangordon | xv does not support 16bpp currently | 11:53 |
| arno11 | ok | 11:53 |
| arno11 | brb (switching device) | 11:56 |
| freemangordon | arno11: please upgrade, reboot and try again | 12:09 |
| freemangordon | gst glimagesink is still broken, but that's a bug in gst | 12:09 |
| arno11 | ok let's go | 12:10 |
| freemangordon | bbl | 12:14 |
| 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 | 13:57 |
| ac_laptop | not-completely-out-of-date | 13:57 |
| Wizzup | many people have tried to do this on regular fremantle and have failed time and time again :) | 14:00 |
| Wizzup | but yes, power management isn't up to fremantle levels yet | 14:00 |
| 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 | 14:16 |
| Wizzup | no, that's not the power draw for sure | 14:18 |
| maxwelld | ac_laptop, i would say - try to port/package/build (if you are from the field) fremantle programs you use to leste. | 15:03 |
| maxwelld | also we have some software here that is not available on fremantle. | 15:08 |
| maxwelld | plus up to date contemporary debian repos. | 15:08 |
| 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. | 15:32 |
| ac_laptop | on a daily basis* | 15:32 |
| Wizzup | if you have sw skills there are things you can do to improve pm btw | 15:33 |
| Wizzup | it's mostly just some drivers that are blocking idle | 15:33 |
| maxwelld | nokia had open sourced kernel patches no? and i guess we have those in our kernel? | 15:34 |
| bencoh | Wizzup: do we know which? | 15:34 |
| bencoh | maxwelld: nokia's kernel is opensource yeah | 15:34 |
| maxwelld | why then our kernel has worse pm? | 15:36 |
| maxwelld | some new features need special handling? | 15:36 |
| bencoh | usually it's the other way around | 15:38 |
| 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 | 15:38 |
| bencoh | or they're just re-implemented and some pm details are missed | 15:39 |
| bencoh | and overall mainline kernels behave poorly when it comes to pm on many (most?) platforms, afaict | 15:39 |
| Wizzup | bencoh: I think we do to some extent | 15:49 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/545 | 15:50 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/321 | 15:50 |
| Wizzup | tsc2005 is a good start | 15:51 |
| Wizzup | sicelo: did we ever figure out why the n900 would panic/reset in off mode? I think you were working on it | 15:51 |
| Wizzup | bencoh: but basically trying to hit RET would be a great improvement, we don't hit it on n900 yet | 15:51 |
| Wizzup | and then as soon as we do that we might see some drivers become unstable in RET, like the display driver / led driver | 15:51 |
| Wizzup | then we have to fix that | 15:52 |
| 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 | 15:52 |
| 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 | 15:52 |
| bencoh | I bet part of the components would lose their reg values after hitting OFF | 15:53 |
| bencoh | it might be a similar issue with RET btw | 15:53 |
| Wizzup | yes | 15:55 |
| Wizzup | it sounds like you've fix it in no time ;) | 15:55 |
| Wizzup | you'd fix it* | 15:55 |
| Wizzup | I only say yes because I've seen something like that happen I think | 15:55 |
| bencoh | Wizzup: nah, I mentioned it because I've seen it happen (and worked around it) on other platforms, that's all | 16:00 |
| Wizzup | I don't know how to work around it :) | 16:00 |
| 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 | 16:01 |
| bencoh | along with taking care of special cases | 16:01 |
| 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. | 17:20 |
| arno11 | of course i'm not talking about idle :) | 17:22 |
| freemangordon | arno11: did you try the new omap DDX? | 17:23 |
| arno11 | freemangordon: yes it works ! thx | 17:23 |
| freemangordon | cool | 17:23 |
| arno11 | no more issue with xv | 17:23 |
| arno11 | :) | 17:23 |
| freemangordon | anything else that does not seem working? | 17:23 |
| arno11 | yes conversations | 17:24 |
| freemangordon | besides glimagesink in gst | 17:24 |
| freemangordon | hmm | 17:24 |
| freemangordon | those should not have any issues | 17:24 |
| arno11 | still black screen in 16 bits | 17:24 |
| arno11 | weird | 17:24 |
| 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 | 17:24 |
| freemangordon | dsc_: any idea what could be the issue? | 17:25 |
| arno11 | ac_laptop: yes it happens sometimes but no real issue | 17:25 |
| 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 ? | 17:26 |
| arno11 | maybe your battery is not calibrates enough ? | 17:27 |
| arno11 | *calibrated | 17:27 |
| arno11 | freemangordon: seems everything else working :) | 17:28 |
| freemangordon | good | 17:28 |
| freemangordon | how's the performance? | 17:28 |
| arno11 | let's say 30% better with stock freqs | 17:29 |
| arno11 | and really good with overclock | 17:29 |
| freemangordon | not bad | 17:29 |
| dsc_ | arno11: conversations yields a black screen? | 17:30 |
| arno11 | dsc: yes when using 16 bpp | 17:31 |
| freemangordon | dsc_: the same on d4 | 17:31 |
| arno11 | but the app works | 17:31 |
| ac_laptop | arno11: I never had a message "battery not calibrated" but maybe I still need to do this ? https://leste.maemo.org/Nokia_N900#Battery_calibration | 17:31 |
| dsc_ | black screen on d4 ?! | 17:31 |
| arno11 | ac_laptop: yes :) | 17:31 |
| dsc_ | let me read scrollback | 17:31 |
| freemangordon | dsc_: do you use QGrachicsScene etc? | 17:32 |
| ac_laptop | The thing is, if I switch regularly between fremantle and leste, does it mess up battery calibration ? | 17:32 |
| dsc_ | freemangordon: no but I can imagine QtQuick does various graphics related things | 17:32 |
| dsc_ | I'm not following, arno has latest conversations on d4 and there is only a black screen? | 17:33 |
| 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) | 17:33 |
| ac_laptop | sicelo: ok | 17:34 |
| arno11 | dsc: black screen on n900 and apparently on d4 according to fmg | 17:34 |
| freemangordon | dsc_: this is when we switch xorg depth to 16 bpp | 17:35 |
| freemangordon | QtQuick is qml, no? | 17:35 |
| dsc_ | yes | 17:36 |
| freemangordon | lemme try to start it without GL | 17:36 |
| dsc_ | btw im not even sure if it actually uses GPU drivers or a software renderer | 17:36 |
| dsc_ | but this is unrelated | 17:36 |
| 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 | 17:36 |
| freemangordon | it should use GPU and yes, I think it is related | 17:37 |
| dsc_ | I think you can confirm that with `QT_LOGGING_RULES=qt.qpa.gl=true QSG_INFO=1` | 17:37 |
| freemangordon | dsc_: any idea where ""0x0 (0 DPI)"" message comes from? | 17:37 |
| dsc_ | as for color space, there is `QT_QPA_EGLFS_DEPTH` but thats eglfs stuff | 17:38 |
| dsc_ | freemangordon: i dont recall | 17:38 |
| dsc_ | maybe mainwindow, let me check | 17:38 |
| dsc_ | https://github.com/maemo-leste/conversations/blob/master/src/mainwindow.cpp#L29 | 17:38 |
| freemangordon | dsc_: LGTM https://pastebin.com/AJwVJkfc | 17:40 |
| dsc_ | oh cool :) | 17:40 |
| freemangordon | but somehow seems screen size is 0x0 :) | 17:41 |
| freemangordon | hmm, it outputs the same in VM, so I guess htis is harmless | 17:42 |
| 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 | 17:43 |
| sicelo | fremantle doesn't wait for 100%, while kernel does :-) | 17:45 |
| freemangordon | dsc_: anything else I could check? | 17:45 |
| dsc_ | freemangordon: I included those variables in mainwindow just for debugging purposes, I do not use them throughout the program | 17:45 |
| dsc_ | i'm not sure what could cause this specific issue | 17:45 |
| freemangordon | something with the rendering | 17:46 |
| freemangordon | dsc_: why do you need to parse system theme? | 17:47 |
| freemangordon | like, qt already does that | 17:49 |
| Wizzup | qml does not | 17:49 |
| dsc_ | QPalette does not offer enough colors | 17:49 |
| dsc_ | hildon theme config have more | 17:49 |
| freemangordon | Wizzup: it is not only about colors, but about sapwood engine | 17:50 |
| dsc_ | I was having trouble working with the limited colors offered by qpallete | 17:50 |
| freemangordon | ok | 17:50 |
| dsc_ | it did work though, but the QML needed a bit more | 17:50 |
| dsc_ | so I parsed them directly | 17:50 |
| Wizzup | freemangordon: conversations starts ok for me | 17:51 |
| Wizzup | no black screen | 17:51 |
| Wizzup | on d4 | 17:51 |
| freemangordon | Wizzup: 16 bpp ;) | 17:52 |
| freemangordon | xorg is started with -depth 16 | 17:52 |
| Wizzup | on your d4? | 17:52 |
| freemangordon | mhm | 17:52 |
| Wizzup | aha | 17:52 |
| tmlind | i may have v6.6 patches rebased finally.. let's see, boot testing.. | 17:56 |
| freemangordon | :) | 17:56 |
| arno11 | freemangordon: i didn't notice that cpu usage seems to decrease a lot in 16bpp, really cool | 17:58 |
| 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 | 17:59 |
| freemangordon | tmlind: ok, I will have a look at it when have to | 17:59 |
| freemangordon | dsc_: BTW, the same issue with LIBGL_ALWAYS_SOFTWARE=1 | 18:00 |
| 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 | 18:00 |
| dsc_ | interesting enough today I am debugging mesa/eglfs Qt issues on some other hardware | 18:02 |
| tmlind | uvos: i think i got some initial follow_pte() change done, not sure if it needs more checks for the addresses | 18:03 |
| freemangordon | dsc_: failing with both mesa and pvr would mean it is some qt fault | 18:04 |
| freemangordon | hmm, lemme try another theme | 18:04 |
| Wizzup | what theme do you have? | 18:04 |
| freemangordon | sorry I meant 'style' | 18:05 |
| freemangordon | the same happens with windows and gtk2 theme | 18:06 |
| dsc_ | this issue is a bit bizarre freemangordon | 18:06 |
| dsc_ | Qt should support that depth fine | 18:06 |
| freemangordon | right | 18:06 |
| freemangordon | actually qt does | 18:06 |
| freemangordon | like "new message" opens proper window | 18:07 |
| dsc_ | maybe because Qt was compiled against a different depth it cannot switch to another | 18:07 |
| dsc_ | ? | 18:07 |
| dsc_ | would be weird, just thinking out loud | 18:08 |
| freemangordon | dsc_: looks like some qtquick issue | 18:10 |
| freemangordon | dsc_: is there some simple qtquick application I can use for testing? | 18:12 |
| dsc_ | yeah | 18:13 |
| dsc_ | https://github.com/kroketio/qt5-qml-cmake-hello-world | 18:13 |
| freemangordon | thanks | 18:13 |
| dsc_ | cmake -Bbuild . && make -Cbuild -j2 | 18:13 |
| dsc_ | ./bin/... | 18:13 |
| dsc_ | might want to change https://github.com/kroketio/qt5-qml-cmake-hello-world/blob/master/src/main.qml#L11 | 18:14 |
| dsc_ | ./build/bin/qml_hello | 18:15 |
| arno11 | Wizzup: btw we really need the new daemon.conf on n900 | 18:15 |
| freemangordon | dsc_: ok | 18:15 |
| Wizzup | arno11: can you split it out from the transitions pr then perhaps? | 18:15 |
| arno11 | yes i'll try, sorry for that | 18:16 |
| dsc_ | freemangordon: if that doesnt work, try https://github.com/kroketio/qt5-widgets-qml-cmake-hello-world | 18:18 |
| dsc_ | because the first one uses QML's ApplicationWindow{}, dont know if Hildon can do that | 18:19 |
| dsc_ | should be fine though | 18:19 |
| freemangordon | dsc_: looks fine to me | 18:19 |
| freemangordon | a grey rectangle with some 'display' icon in it | 18:20 |
| freemangordon | so seems some issue in conversations | 18:20 |
| freemangordon | lemme try the other application as well | 18:21 |
| uvos | freemangordon: i would like to note that lots of things dont work in 16bit mode even on modern linux desktop | 18:23 |
| freemangordon | right, but qt should work | 18:24 |
| freemangordon | qt/qml | 18:24 |
| dsc_ | ah interesting | 18:24 |
| 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 | 18:24 |
| uvos | qwebengine being just black is suspicous | 18:24 |
| uvos | since it uses the same rendering engine in the end as qml | 18:25 |
| uvos | know any qml desktop app i can install? | 18:25 |
| uvos | thats likely in the repos | 18:25 |
| dsc_ | freemangordon: however, do try that second one, because that one creates a QML widget *inside* a QtWidgets window | 18:25 |
| dsc_ | just for testing | 18:25 |
| dsc_ | and conversations also does this | 18:25 |
| freemangordon | yes, that one has issue | 18:25 |
| freemangordon | uvos: qtwebbrowser works though | 18:26 |
| uvos | hmm ok wierd | 18:26 |
| freemangordon | dsc_: so embedding qml in qwidget seems buggy | 18:28 |
| uvos | liri calculator also works in 16bit | 18:28 |
| uvos | (qml) | 18:28 |
| bencoh | they do all render in the same way though? | 18:29 |
| freemangordon | uvos: pure qml works fine | 18:29 |
| freemangordon | it seems there is issue when you embed qml in qwidget | 18:30 |
| freemangordon | lemme check in qt bugtracker | 18:30 |
| uvos | mean while in 8bit mode the only thing i have found that works is sphone (gtk2) | 18:30 |
| uvos | (im just messing around i know) | 18:30 |
| bencoh | :D | 18:30 |
| freemangordon | heh | 18:30 |
| uvos | openbox also works in 8bit | 18:30 |
| uvos | freemangordon: yeah ill fix that (licence) | 18:31 |
| bencoh | silly question, does xdpyinfo reports a different scanline_pad when reducing xorg depth? | 18:31 |
| uvos | copy-paste | 18:31 |
| bencoh | (from 24 to 16 for instance) | 18:32 |
| uvos | depth 8, bits_per_pixel 8, scanline_pad 32 | 18:32 |
| bencoh | interesting | 18:32 |
| bencoh | hmm, maybe not, that's just the stride alignment, probably | 18:34 |
| bencoh | (in bytes) | 18:34 |
| uvos | would be cool if we could get 16bit mode working globaly, 32bits is so pointless on a phone | 18:37 |
| freemangordon | totally agree | 18:37 |
| uvos | but its not really a winnable battle i fear | 18:37 |
| uvos | maybe on n900 it is | 18:37 |
| freemangordon | at least we can try | 18:37 |
| uvos | since it cant run bloated modern stuf anyhow | 18:37 |
| dsc_ | < freemangordon> dsc_: so embedding qml in qwidget seems buggy <== ehh, yeah... no idea! | 18:39 |
| dsc_ | maybe the QML works but its just a sizing issue | 18:39 |
| dsc_ | i.e: it is not expanding | 18:39 |
| dsc_ | within its container | 18:39 |
| ac_laptop | are there keyboard shortucuts available by default on fremantle which are not present on a leste fresh install ? | 18:39 |
| uvos | its more likely imo that the qml embeding is rendered to a texture in this case that is then drawn by qwidgets | 18:40 |
| dsc_ | freemangordon: I would imagine you would also get various QML errors if that was really broken | 18:40 |
| uvos | and this pipeline just assumes 8bits per color somewhere | 18:40 |
| 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 | 18:41 |
| bencoh | duh | 18:42 |
| dsc_ | xD | 18:42 |
| bencoh | is that qt5 btw? | 18:46 |
| freemangordon | uvos: that would be really strange if qt does not support 16 bpp properly | 18:46 |
| freemangordon | bencoh: yes | 18:46 |
| dsc_ | bencoh: qt6 in this case | 18:46 |
| freemangordon | 5.15 | 18:46 |
| dsc_ | oh, nvm | 18:46 |
| bencoh | hmm | 18:46 |
| bencoh | ah | 18:46 |
| freemangordon | 5.15.2 | 18:46 |
| uvos | i maen it "supports" 16 bit mode | 18:48 |
| uvos | it would not suprise me if it gets essentaly no testing however | 18:48 |
| freemangordon | dsc_: how to make debug build when using cmake? | 18:49 |
| uvos | -DCMAKE_BUILD_TYPE | 18:50 |
| dsc_ | CMAKE_BUILD_TYPE=Debug | 18:50 |
| uvos | =Debug | 18:50 |
| dsc_ | -DCMAKE_BUILD_TYPE=Debug | 18:50 |
| freemangordon | thanks :) | 18:50 |
| dsc_ | it may also need -DCMAKE_CXX_FLAGS=-O... | 18:51 |
| dsc_ | not sure | 18:51 |
| uvos | Debug adds -g , which i gues fmg is after, unless the cmake script overrides the default | 18:52 |
| dsc_ | aye | 18:52 |
| ac_laptop | I've just noticed that when booting on leste I have /boot on mmcblk0p1 , / on mmcblk0p2 , and swap on mmcblk*1*p3 | 18:59 |
| ac_laptop | and I don't see any mmcblk*0*p3 | 18:59 |
| uvos | wich is a problem why? and what device? | 19:00 |
| ac_laptop | I assume mmcblk1 designates the eMMC since the 3 partitions are respectively fat32, ext3 ans linux-swap | 19:01 |
| ac_laptop | and mmcblk0 is the mSD card, but it has only 2 partitions, no swap | 19:02 |
| uvos | yes thats correct for n900 | 19:02 |
| ac_laptop | flashing the image on the microSD (via dd ) must create a swap on the mSD, right ? | 19:02 |
| uvos | but you really need to specify the device when asking questions | 19:03 |
| uvos | no | 19:03 |
| ac_laptop | oh sorry N900 | 19:03 |
| uvos | why? | 19:03 |
| sicelo | for swap, leste is using zram, but you can also just activate the existing swap on mmcblk*1*p3 | 19:03 |
| uvos | the emmce is mutch faster so swaping there has advantages | 19:03 |
| uvos | i thought we disabled zram on n900? | 19:03 |
| arno11 | and swap on emmc is supposed to be activated automatically in recent images | 19:05 |
| 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 :) | 19:05 |
| uvos | you can do that | 19:05 |
| uvos | if you have a fast sdcard you can beat emmc on random writes (by a wide margin) | 19:05 |
| uvos | but for sequental stuff emmc will win since its on a faster bus | 19:05 |
| 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) | 19:06 |
| uvos | ac_laptop: mostly application class / uhs cards | 19:07 |
| uvos | class10 u1 is really really slow | 19:07 |
| uvos | https://www.cameramemoryspeed.com/reviews/micro-sd-cards/ | 19:07 |
| uvos | see this nice table | 19:08 |
| bencoh | uh, wow | 19:08 |
| uvos | anything above 25mb/s is useless | 19:09 |
| uvos | since you are limited by the bus tehre | 19:09 |
| bencoh | something's off with those lexar cards | 19:10 |
| bencoh | or they're just terrible at random writing | 19:10 |
| bencoh | looks like sandisk and lexar have opposite optimization/tuning goals | 19:11 |
| 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 | 19:11 |
| uvos | on d4 at least i can see these numbers | 19:11 |
| bencoh | for real ? | 19:11 |
| uvos | ie my sd extream can peg the bus at pretty mutch all times | 19:12 |
| ac_laptop | which card would you advise based on those numbers ? | 19:12 |
| uvos | well i bought a SanDisk Extreme A1 | 19:13 |
| uvos | but its overkill | 19:13 |
| uvos | as i said it pegs the bus even down to pretty small random writes | 19:14 |
| uvos | i gues it helps with really small randoms | 19:14 |
| uvos | but you can likely get something cheaper that will still peg the bus most of the time | 19:14 |
| uvos | i doubt it helps on n900 anyhow | 19:16 |
| uvos | the cpu is so slow i doubt it helps mutch if the data comes in at full bus speed | 19:16 |
| uvos | you have to remember that the d4s cpu is 5x faster while its io speed is the same | 19:17 |
| uvos | so its mutch more io bound | 19:17 |
| 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!) | 19:23 |
| sicelo | Single stepping until exit from function name_get_resp_cb, which has no line number information. | 19:24 |
| sicelo | any ideas? i guess the individual object files don't get built with the debug symbols :-/ | 19:25 |
| freemangordon | do you build packge? | 19:25 |
| freemangordon | or you build with make? | 19:25 |
| freemangordon | is that on leste? | 19:25 |
| sicelo | build with make | 19:25 |
| freemangordon | on leste? | 19:26 |
| freemangordon | sicelo: ^^^ | 19:26 |
| sicelo | currently, pmOS | 19:26 |
| sicelo | but i think it should be the same | 19:26 |
| freemangordon | you need to set CFLAGS="-O0 -g" | 19:26 |
| freemangordon | somehow | 19:27 |
| freemangordon | does it use meson or autotools? | 19:27 |
| bencoh | CFLAGS="-O0 -g" ./configure | 19:27 |
| freemangordon | mhm | 19:27 |
| bencoh | (and add whatever configure flag) | 19:27 |
| freemangordon | if it does not use meson ;) | 19:27 |
| sicelo | autotools :-) | 19:27 |
| sicelo | i just cloned the upstream repository | 19:27 |
| freemangordon | ok | 19:27 |
| freemangordon | bencoh: I was thinking CFLAGS are passed to configure as parameter | 19:28 |
| freemangordon | not as env var | 19:28 |
| sicelo | let me retry with the CFLAGS in front. i had done it as a param before (as suggested in ofono /INSTALL) | 19:28 |
| freemangordon | sicelo: could you pastebin ./configure --help | 19:28 |
| bencoh | freemangordon: I usually export CFLAGS in env before running configure, or use it the way I mentioned | 19:29 |
| freemangordon | ok | 19:29 |
| tmlind | hmm console lcd not refreshing and audio not working.. need to fix those first before i push out anything | 19:30 |
| uvos | tmlind: context? | 19:30 |
| freemangordon | linux 6.6 | 19:30 |
| uvos | device? | 19:30 |
| uvos | 6.6 works perfectly here besides audio | 19:31 |
| 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"` | 19:31 |
| uvos | oh the kernel vt konsole | 19:31 |
| uvos | dident try that | 19:31 |
| sicelo | freemangordon: https://paste.debian.net/1298163/ | 19:31 |
| uvos | wait no it works | 19:32 |
| sicelo | linux 6.6 working fine on N900 too (only thing i haven't tested is pvr) | 19:32 |
| uvos | tmlind: what do you mean with not refeshing? | 19:32 |
| uvos | i see the kernels scroll during boot | 19:32 |
| 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 ? | 19:32 |
| bencoh | ac_laptop: fremantle reads ext3 just fine | 19:32 |
| freemangordon | sicelo: do as bencoh said (env var) | 19:32 |
| ac_laptop | bencoh: I'm asking because every time I boot on fremantle I get a message "card not recognised" or something like this | 19:33 |
| bencoh | (if you set your env var outside of the configure command, don't forget to export it) | 19:33 |
| freemangordon | ac_laptop: maybe some new ext3/4 option not supported by fremantle kernel | 19:33 |
| bencoh | ac_laptop: oh, that, right, yeah, it's fat32 ... I thought cssu removed that limitation at some point (?) | 19:33 |
| 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 | 19:34 |
| freemangordon | bencoh: ext3 is supported to the extend it is supported by 2.6.28 :) | 19:34 |
| ac_laptop | like the partition scheme, partition type, LVM or anything like that | 19:35 |
| sicelo | rebuilding - on N900 :p | 19:35 |
| freemangordon | ugh | 19:35 |
| bencoh | (why, oh why, when we have an lxc/qemu-based build system :>) | 19:36 |
| freemangordon | bencoh: please, share instructions for cross-building | 19:36 |
| freemangordon | where it is? | 19:36 |
| bencoh | lemme check | 19:36 |
| freemangordon | you never shared what you did :) | 19:36 |
| bencoh | http://bencoh.notk.org/maemo/leste-chimaera-builder-armhf-lxc-20220119.tar.zstd last rootfs looks pretty chunky | 19:36 |
| sicelo | i'm lazy ... pmos also have an easy process, but it doesn't take too long on N900 as well | 19:36 |
| bencoh | but I think that's the one | 19:36 |
| ac_laptop | also I've stumbled upon https://wiki.maemo.org/Changing_the_eMMC_filesystem and I'm curious : have you ever tried the flash-optimized filesystems ? like F2FS ? is there any difference ? | 19:37 |
| tmlind | uvos: the lcd does not refresh on pressing enter or any key at the login prompt without a gui started | 19:37 |
| tmlind | uvos: mcbsp3 complains about dma channels on one d4 but not on the other.. | 19:37 |
| uvos | tmlind: yeah i did see the latter | 19:38 |
| sicelo | ac_laptop: i've seen other mobile OSes try them with excitement ... then eventually returning to ext3/4 | 19:38 |
| uvos | tmlind: the former i dident see since it booted streight to hildon | 19:38 |
| uvos | ext3 is kinda a poor choice for a flash device | 19:39 |
| ac_laptop | sicelo: Android devices use F2FS on their internal memory, right ? | 19:39 |
| uvos | ac_laptop: some vendors do | 19:39 |
| uvos | ac_laptop: its not universal | 19:39 |
| 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 | 19:41 |
| freemangordon | ac_laptop: eMMC has too | 19:41 |
| uvos | mSD cards and emmcs are the same | 19:41 |
| uvos | really | 19:41 |
| uvos | often the very same chips | 19:41 |
| freemangordon | n900 has onenand, but we don;t use it ATM for leste | 19:41 |
| freemangordon | where flash-optimized fs would make sense | 19:42 |
| sicelo | still getting same gdb issue with CFLAGS="-O0 -g" as env var for configure | 19:46 |
| freemangordon | sicelo: please do that in leste | 19:49 |
| freemangordon | I can help then | 19:49 |
| 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 | 19:49 |
| sicelo | ok | 19:50 |
| freemangordon | wait | 19:50 |
| freemangordon | please pastebin backtrace | 19:50 |
| freemangordon | ugh | 19:50 |
| freemangordon | dsc_: with QQuickWindow::setSceneGraphBackend(QSGRendererInterface::Software); it works fine | 19:51 |
| sicelo | https://paste.debian.net/1298164/ , not sure if this is ok :-) | 19:53 |
| freemangordon | bencoh: hmm, this is musl, maybe it needs LD_FLAGS as well? | 19:54 |
| freemangordon | umm, LDFLAGS | 19:54 |
| freemangordon | sicelo: better switch to leste, I will be able to provide help there | 19:55 |
| 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? | 19:55 |
| sicelo | sure, let me get my SD | 19:55 |
| sicelo | fmg, actually this is still in connection with https://lore.kernel.org/ofono/ZUZqIXkQNnen4Bfv@tp440p.steeds.sam/T/#m1efa954d200d5cb1fba4ff0879875a36649d29aa ... maybe from reading that last email (or last two), you might be able to put me on right path right away :-) | 19:56 |
| freemangordon | sicelo: sorry, don;t have time now to go through ofono code to see where you can store the data | 19:58 |
| freemangordon | will try to find time soon | 19:59 |
| sicelo | sure, no rush. | 20:01 |
| 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 ? | 20:04 |
| sicelo | you need most of them. why would you consider removing them? | 20:07 |
| 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 | 20:11 |
| dsc_ | freemangordon: really weird | 20:32 |
| arno11 | dsc: ah i just noticed same black screen bug in NOmWeather | 21:11 |
| arno11 | in 16 bpp of course otherwise it's fine | 21:12 |
| bencoh | ac_laptop: if you don't need telephony at all and hildon stuff you could do without pulseaudio | 22:07 |
| dsc_ | arno11: why are you running on 16 bpp btw | 22:29 |
| arno11 | just a test with fmg to improve n900 responsiveness | 22:29 |
| arno11 | and it works great | 22:29 |
| arno11 | cpu usage decreases a lot for example | 22:30 |
| dsc_ | oh interesting | 22:31 |
| arno11 | yep and scrolling is better | 22:32 |
| arno11 | and touchscreen sensitivity too | 22:33 |
| sicelo | you may want to update https://leste.maemo.org/Nokia_N900#Overclocking :-) | 22:34 |
| arno11 | sicelo: yes | 22:35 |
| arno11 | i'll add turbo mode stuff | 22:36 |
| arno11 | combine with 16 bpp trick and transitions stuff, Leste seems faster than Fremantle honestly | 22:39 |
| arno11 | excepting when loading a qt5 app lol | 22:40 |
| sicelo | and since the dts is now merged, probably don't need the details on the wiki page anymore. could rather link to the commit | 22:41 |
| arno11 | yes indeed | 22:41 |
| sicelo | btw, any reason that the ofono patches for droid 4 haven't been sent to upstream ofono yet? | 23:03 |
| sicelo | Wizzup: re - OFF mode ... still never got around the serial issue | 23:16 |
| Wizzup | arno11: having maemo-launcher qt support might help | 23:29 |
| Wizzup | sicelo: as in, no serial? | 23:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!