uvos has quit [Remote host closed the connection]
nela has joined #maemo-leste
ashley has quit [Server closed connection]
ashley has joined #maemo-leste
ashley is now known as Guest5919
Guest5919 is now known as Elektra
Elektra is now known as Guest8474
Guest8474 is now known as Mary-Kate
Mary-Kate has quit [Changing host]
Mary-Kate has joined #maemo-leste
Mary-Kate is now known as ashley
ahmed_sam has joined #maemo-leste
[TheBug] has quit [Server closed connection]
[TheBug] has joined #maemo-leste
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
<freemangordon> "Note: Displaying a QOpenGLWidget requires an alpha channel in...."
<freemangordon> "If there is no alpha channel, the content rendered by the QOpenGLWidget will not be visible"
fab_ has joined #maemo-leste
xmn has quit [Ping timeout: 268 seconds]
ceene has joined #maemo-leste
<tmlind> got the mcbsp issue sorted out, disabled some unused devices to free more dma channels. pushed out v6.6 based branch to https://github.com/tmlind/linux/commits/mapphone-pending-v6.6
<tmlind> the framebuffer console not updating lcd issue still remains
<tmlind> pvr stuff seems to behave based on light testing, pushing that out too
<tmlind> here's the va_to_pfn() change i made, please check if i missed something.. https://github.com/tmlind/linux_openpvrsgx/commit/215165f141d239ac7ea518c004eaf697ec7d7a1e
<tmlind> will email that to linux_openpvrsgx list
<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
<Wizzup> right
<Wizzup> freemangordon: that's unfortunate @ alpha
<arno11> Wizzup: after double-checking, yes it concerns only apps with qt5 deps
elastic_dog has quit [Ping timeout: 260 seconds]
arno11 has left #maemo-leste [#maemo-leste]
elastic_dog has joined #maemo-leste
ahmed_sam has joined #maemo-leste
<Wizzup> sicelo: it might be that it's limited to n900 kbd
<sicelo> yeah anything is possible. but I doubt it's that.
<Wizzup> what I mean is that it's expecting a certain layout
ahmed_sam has quit [Read error: Connection reset by peer]
akossh has quit [Remote host closed the connection]
peetah has quit [Ping timeout: 240 seconds]
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
Pali has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 260 seconds]
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
akossh has quit [Remote host closed the connection]
akossh has joined #maemo-leste
akossh has left #maemo-leste [#maemo-leste]
sunshavi_ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
sunshavi has joined #maemo-leste
<Wizzup> I wonder if we can use XWayland's rootful mode
peetah has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
aat596_3 has quit [Quit: ZNC 1.8.2 - https://znc.in]
akossh has joined #maemo-leste
aat596_3 has joined #maemo-leste
sch has quit [Ping timeout: 240 seconds]
sch has joined #maemo-leste
sch has quit [Ping timeout: 268 seconds]
uvos has joined #maemo-leste
<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?
akossh has quit [Ping timeout: 245 seconds]
akossh has joined #maemo-leste
<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> .1 kernel?
<Wizzup> d=2023-11-15|t=19:43:16|i=OFF:0,RET:379348|p=381|c=100|b=none
<Wizzup> root@maindroid:~# /etc/init.d/droid4-powermanagement status
<Wizzup> d=2023-11-15|t=19:43:51|i=OFF:0,RET:379452|p=183|c=100|b=none
<Wizzup> root@maindroid:~# sleep 30 ; /etc/init.d/droid4-powermanagement status
<Wizzup> Linux maindroid 6.1.48 #1 SMP PREEMPT Wed Aug 30 14:28:56 UTC 2023 armv7l GNU/Linux
<uvos> hmm
<uvos> so its something specific to my install
<uvos> always fun
arno11 has joined #maemo-leste
<arno11> ac_laptop: taking lot of time to leave idle is not normal and not a known issue on N900
<Wizzup> uvos: looks like it yes
<arno11> seems something is slowing done your 0S: just a question, was wifi still On ?
<Wizzup> uvos: so what is the dtb problem specifically, did they get renamed?
<uvos> Wizzup: yes
<uvos> the whole thing got restructured
<uvos> its ti/omap/* now
<uvos> bigger issue is cpufreq is just missing with no explenation
<Wizzup> maybe the config got renamed
<arno11> ac_laptop: the only thing i know able to slowing down N900 (a loooot) periodically is apt-worker
Oksanaa has joined #maemo-leste
<Wizzup> uvos: what is the 6.x branch
<uvos> maemo-6.6
<uvos> maemo-6.1.y
<uvos> maemo-6.1
<Wizzup> git fetch didn't show it, weird
<Wizzup> sorry, I meant 6.6 branch*
<Wizzup> fatal: 'origin/maemo-6.6' is not a commit and a branch 'maemo-6.6' cannot be created from it
<uvos> huh
<sicelo> cpufreq is still in kernel. nothing changed there. what exactly are you seeing?
<uvos> the config is there
<uvos> but
<uvos> /sys/bus/cpu/devices/cpu0/cpufreq anf friends dissapeard
<Wizzup> uvos: the branch also isn't on github
<sicelo> i've had 6.6 on pmOS for a while. will check when my battery is charged
<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
<uvos> Wizzup: yeah "as suggested by tmlind" :)
<Wizzup> if you can make a PR for leste-config for this, that would be great
<uvos> Wizzup: i think doing it in sysctl is better
<Wizzup> yes
<Wizzup> sysctl.d more specifically
<Wizzup> I think we already have some files there, yeah?
<uvos> yes
<uvos> but i have to check if setting just net.ipv4.neigh.default.interval_probe_time_ms works
<uvos> first
<uvos> as long as its set before the interfaces are set up it should iiuc
<Wizzup> brb work mtg
sch has joined #maemo-leste
elastic_dog has quit [Ping timeout: 256 seconds]
Danct12 has quit [Quit: A-lined: This user has been AViVA-lined!]
Danct12 has joined #maemo-leste
<ac_laptop> Wizzup, uvos: who should I trust ? :)
Guest3390 has joined #maemo-leste
Guest3390 has quit [Changing host]
Guest3390 has joined #maemo-leste
Guest3390 has quit [Client Quit]
Danct12- has joined #maemo-leste
elastic_dog has joined #maemo-leste
Danct12- has quit [Remote host closed the connection]
Danct12- has joined #maemo-leste
Danct12 has quit [Quit: A-lined: This user has been AViVA-lined!]
<uvos> ac_laptop: forget about zram, swap on sd/emmc :)
<freemangordon> right, zram on n900 does more harm than good
<freemangordon> if there is any good at all
<freemangordon> arno11: So the only option to improve rendering performance on n900 is DRI3
<freemangordon> BTW, I wonder why with omapfb it was faster
<ac_laptop> wow leste looks *significantly* faster with this new U3 card o_O
<ac_laptop> dunno if it's U3 or just the quality of the card but the difference is perceptible
Danct12- is now known as Danct12
Danct12 has quit [Quit: ZNC 1.8.2 - https://znc.in]
Danct12 has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> freemangordon: ok, so is there any additional stuff to install or we have just to add it as an option in Device section (in omap.conf)
<arno11> ?
<freemangordon> no, we have to implement support for it in DDX :)
<freemangordon> or switch to modesetting
<freemangordon> seems gles2 has finally received some love
<freemangordon> maybe it makes sense to try ms/glamor again
<freemangordon> uvos: no idea what's going on, but in the last month there is merged code that was sitting there for years, see https://gitlab.freedesktop.org/xorg/xserver/-/commit/0076671e24670f1ddb151946e490497f171589f0 for example
<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
<arno11> when you say modesetting you mean KMS ?
<freemangordon> I mean modesetting DDX
<freemangordon> for example
<arno11> ah ok
arno11 has left #maemo-leste [#maemo-leste]
<uvos> perparing to port the new foss pvr rouge code down to sgx?
<uvos> sounds neat if true
sixwheeledbeast^ is now known as sixwheeledbeast
ikmaak has quit [Server closed connection]
<freemangordon> uvos: or rather open-sourcing pvr mesa code (the one I re-ed :) )
ikmaak has joined #maemo-leste
<freemangordon> but seems to be compatible with new mesa
<uvos> so deleating tracker state and letting it settle for several hours dosent help
<uvos> the mafw tracker is still using a huge amount of cpu time preventing the device from sleeping
<uvos> ill try to figure out what its doing tomorrow
<freemangordon> uvos: mafw != tracker
<uvos> yeah its gnomes tracker
<uvos> i know
<uvos> its used by mafw however
<freemangordon> there is mafw-tracker-source, but it is merely wrapping tracker
<freemangordon> yeah
<freemangordon> It seems tracker has issues
<freemangordon> I had to fork it already
<uvos> what dosent have issues
<uvos> yeah i saw that
<uvos> pretty silly
<freemangordon> also, TI repo has new sgx binaries
ac_laptop has quit [Ping timeout: 268 seconds]
<sicelo> looks like i finally got my ofono patch working, https://paste.debian.net/1298261/
panzeroceania has quit [Server closed connection]
panzeroceania has joined #maemo-leste