ahmed_sam has quit [Read error: Connection reset by peer]
Pali has quit [Ping timeout: 260 seconds]
Evil_Bob has quit [Server closed connection]
Evil_Bob has joined #maemo-leste
parazyd has quit [Ping timeout: 240 seconds]
parazyd has joined #maemo-leste
ahmed_sam has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
k1r1t0_N900 has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
RedW has quit [Server closed connection]
RedW has joined #maemo-leste
k1r1t0_N900 has joined #maemo-leste
<sicelo>
yes. will get around to it though, as i already obtained all the electronic components i need. just need a plan for making contact with the pads
ahmed_sam has quit [Ping timeout: 260 seconds]
ceene has quit [Ping timeout: 245 seconds]
maxwelld has quit [Server closed connection]
maxwelld has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
<freemangordon>
dsc_: heh, m_quickWidget->setAttribute(Qt::WA_AlwaysStackOnTop); makes it work
<tmlind>
mailed, that's it for me probably until the weekend. i'll start posting the pending dts and usb patches so we can at least clear out the major branch merge bottlenecks with the dts files
fab_ has quit [Quit: fab_]
<tmlind>
at least dmesg -l err,warn helped debugging the audio issue with less errors and warnings to look at now
<tmlind>
sicelo: the ofono d4 serial port modem support should be updated to use ell for raw packet reads and writes and then it could get merged
fab_ has joined #maemo-leste
sch has joined #maemo-leste
Daanct12 has joined #maemo-leste
<sicelo>
ok
<sicelo>
btw, osso contacts has a h-i-m bug ... you can't type a number in the cell field using hwkb when adding a contact. at least that's what i observe on my Droid 4
pere has quit [Ping timeout: 260 seconds]
fab_ has quit [Quit: fab_]
akossh has quit [Quit: Leaving.]
akossh has joined #maemo-leste
k1r1t0_N900 has quit [Ping timeout: 246 seconds]
akossh has quit [Remote host closed the connection]
pere has joined #maemo-leste
arno11 has joined #maemo-leste
akossh has joined #maemo-leste
<arno11>
Wizzup: oh there is no qt support for maemo-launcher ? could explain why some apps start in a sec and others in 10
<uvos>
Wizzup: we could, but it would be monumentally stupid
<uvos>
you loose all the advantages of x, while gaining no advantages
pere has quit [Ping timeout: 246 seconds]
<dsc_>
freemangordon: ok <_<
<dsc_>
thanks for debugging that, ill set the flag
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: is it ok for you if i cancel the current transitions PR and create a new one with PA daemon.conf only ?
<Wizzup>
sure
<Wizzup>
I am interested in the transitions one too, but let's separate them
<arno11>
ok, so i'll create 2 different PR's
<arno11>
and indeed custom transitions is really cool and easy to modify on the fly
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
DPA has quit [Server closed connection]
pere has joined #maemo-leste
DPA has joined #maemo-leste
<arno11>
Wizzup: i added 2 different PRs (and closed the old one)
Daanct12 has quit [Quit: WeeChat 4.1.1]
<Wizzup>
thanks
<Wizzup>
uvos: mz615 arrived too, so I could probably try to get various utags later for the models if they are different
akossh has quit [Quit: Leaving.]
<arno11>
Wizzup: btw is Twinkle still working on your D4 ? can't login my sip account anymore (with 401 unauthorized) on n900 (the account works on other devices)
akossh has joined #maemo-leste
<Wizzup>
I don't think twinkle should act differently on different devices
<arno11>
i mean just the sip account works on other devices
<arno11>
just twinkle shows error on my n900
<arno11>
anyway i'll have a look later, i asked just in case you have the same issue
<Wizzup>
I still have to set up my n900 again
<arno11>
issue solved, forget my question :)
<arno11>
just a wrong parameter i forgot to remove
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
makes sense
<Wizzup>
lol, qemu goes black every time I make a call and then I have to reboot
<Wizzup>
arg
ceene has quit [Ping timeout: 268 seconds]
mn3monic6 has joined #maemo-leste
mn3monic has quit [Quit: Ping timeout (120 seconds)]
mn3monic6 is now known as mn3monic
akossh has quit [Quit: Leaving.]
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
DFP has quit [Quit: Leaving]
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
akossh has quit [Client Quit]
akossh has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
<Wizzup>
it looks like quectel eg-25 (usb glink from olimex) can emulate a virtual sound card over usb and then calls can be done that way
<Wizzup>
not super interesting but I didn't know
<Wizzup>
uvos: for mz617 or similar, I guess I can open one up and hook its battery connected directly to a lab psu
<Wizzup>
connector*
nela has quit [Ping timeout: 256 seconds]
<uvos>
Wizzup: sure
<uvos>
tmlind: none of the mapphone dtbs compile on your mapphone-pending-v6.6 branch
<uvos>
as allways dtc isent very helpfull: Error: omap4-droid4-xt894.dts:4.1-9 syntax error
<uvos>
thats just #include "motorola-mapphone-xt8xx.dtsi"
<uvos>
i gues the real problem could be in any subsiquent file
<uvos>
ah its because i have to build ti/omap/omap4-droid4-xt894.dtb
<uvos>
whats really confusing about that is that omap4-droid4-xt894.dtb worked just fine with make[3]: Nothing to be done for 'arch/arm/boot/dts/omap4-droid4-xt894.dtb' untill i cleaned the tree
<uvos>
thats really error prone
<uvos>
it was just using the old dtb from 6.1 previously
<uvos>
that feals like a buildsystem bug, if arch/arm/boot/dts/omap4-droid4-xt894.dts dissapears the omap4-droid4-xt894.dtb target should not work, just because a old dtb is lying around
<uvos>
Wizzup: do you know where ci gets what dtbs to build from?
<uvos>
Wizzup: anyhow maemo-6.6 is ready for a build as soon as the ci dts situation is cleared
<uvos>
besides the kernel not refreshing the cm display in vt, i dont see any futher issues
<uvos>
this breaks the emergency shell mode but is otherwise inconsequential
<uvos>
d4 tested only ofc
<uvos>
someone has to do n900
akossh has quit [Ping timeout: 256 seconds]
nela has joined #maemo-leste
akossh has joined #maemo-leste
<uvos>
hmm and cpufreq dissapeard in 6.6
<uvos>
and powermanagement dosent work, no ret
<uvos>
but it dosent work on 6.1 either here it seams
ac_laptop has joined #maemo-leste
<ac_laptop>
Hello people
<ac_laptop>
Good news: I realised that when my N900 on Leste was idle for a long time (a few hours) it was taking a loooooot of time to leave idle mode. Then it's possible that what I had interpreted as the device being shut down because it had used all its battery was just the device taking a lot of time to respond. I'll make further tests, with the stock battery and a 1430mAh replacement battery that
<ac_laptop>
I've bought.
<ac_laptop>
I've also received my c10 u3 card, I've just installed Leste on it. Suppose I want to put an additional partition on it, do you advise that I run the expand.sh script and then reduce the main partition ? Or that I create the new partition with the size I want and then run the expand.sh script ?
<sicelo>
no need for expand ... jyst do it your own way, e.g. with gparted
<sicelo>
s/expand/expand script/
<Wizzup>
uvos: yes, I can help add any dtbs, it is a bit hacky
<Wizzup>
uvos: you get no RET ?
<Wizzup>
(in 6.1)
<uvos>
its not the kernel
<uvos>
its userspace
<uvos>
i do get ret before the maemo userspace loads
<uvos>
after that its 300 ish mw and no futher rets
<Wizzup>
so some driver that is used by maemo now keeps kernel awake?
Oksanaa has quit [Ping timeout: 260 seconds]
<uvos>
maybe idk
<uvos>
dose it work on your system with the current 6
<uvos>
its there, havent pushed it to the maemo repo
<uvos>
will now however
<Wizzup>
so the way I remember this works is that we patch scripts/package/builddeb
<uvos>
can remove the rules
<uvos>
its confuseing
<Wizzup>
so you would edit scripts/package/builddeb if the dtbs are renamed
<Wizzup>
what the debian/rules do I have to check but I think we do need them, maybe just not the DTB part of it
<uvos>
powertop suggests tracker-store is using a lot of cpu while idle
<Wizzup>
ah, maybe it's either buggy on your machine, or it's doing it's initial indexing?
<Wizzup>
I had to nuke my tracker state to get it to behave too
<uvos>
where dose it have its state?
<Wizzup>
try
<Wizzup>
tracker reset --hard
<Wizzup>
rm -rf ~/.cache/tracker/
<sicelo>
cpufreq available on N900 using 6.6 (pmOS ... but distro is irrelevant for kernel)
<Wizzup>
is it the same kernel config?
<uvos>
i mean the related configs are enabled CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPUFREQ_DT=m, they are also not renamed
<uvos>
i suspect the problem in omap4 dt
<ac_laptop>
arno11: I'll make some more tests
<Wizzup>
uvos: so they didn't add some setting for cpufreq sysfs or so?
<ac_laptop>
Concerning the fresh install message, the part about install zram-tools and removing /etc/init.d/zram can probably be removed since it's already done. But I guess it's still necessary to configure /etc/default/zramswap ?
<uvos>
Wizzup: looking at drivers/cpufreq/Kconfig i dont see anything
<ac_laptop>
is it relevant to put a value of SIZE=1024 on n900 ?
<uvos>
Wizzup: so killing everything mafw related has improved the pm situation
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
ac_laptop: I think 1024 would be too high
<ac_laptop>
Wizzup: so 256 ? the size of the RAM ?
<uvos>
more than half physical ram is pretty silly
<uvos>
besides its questionable if enableing it at all is good idea
<uvos>
the n900s cpu is really slow, im not sure it needs the extra work
<uvos>
Wizzup: i think "find /proc/sys/net/ -name interval_probe_time_ms | xargs -I% sh -c 'echo -1 > %'" helps a bit
<uvos>
as suggested by tmlind
<Wizzup>
ac_laptop: 512 would be sensible
<uvos>
we could also try setting net.ipv4.neigh.default.interval_probe_time_ms in systctl.d
<Wizzup>
uvos: ah, yes, I think tmlind also mentioned that
<freemangordon>
I will definitely git it a shot when I have some spare time
<freemangordon>
*give
<arno11>
freemangordon: (for DDX) ok, is it complicated to implement ?
<norayr>
very hard to deal with rust softawer. especially when it wants newer crates etc. i tried to package some crates but they want newer compiler...
<freemangordon>
arno11: yes
<arno11>
ok
<freemangordon>
I would rather try modesetting with glamor