<uvos>
and a lot changed, so almost nothing merges/rebases cleanly on latest stable 6.6
<uvos>
i was just noteing that
<Wizzup>
understood
<Wizzup>
I would like to put in some effort at least to try to figure out this cpufreq issue once more
<uvos>
i dident rebase anything yet i just did a git rebase and skipped all the conflicts
<uvos>
so theres nothing to push atm
<Wizzup>
so you tried 6.6 without our patches to see if cpufreq would work
<uvos>
i tried 6.6 with limited patches
<uvos>
and 6.9 totaly stock
<Wizzup>
ok
<uvos>
theres nothing about cpufreq in dmesg in either situation
<uvos>
it just dosent load and dosent probe
<uvos>
manually loading the modules dosent make them probe either
<Wizzup>
on my mz617 I get
<Wizzup>
# modprobe cpufreq
<Wizzup>
modprobe: FATAL: Module cpufreq not found in directory /lib/modules/6.6.0-g3e1ba4fc6a7f
<uvos>
probubly something is up with the dtb
<Wizzup>
but I got the name wrong
<Wizzup>
it's cpufreq_dt
<Wizzup>
mhm @ dtb
<uvos>
hmm
<uvos>
cpufreq dosent feature at all in my stock 6.9 dmesg
<Wizzup>
I got it wrong, the module is named cpufreq_dt
<uvos>
i mean dmesg | grep cpufreq dosent show anything so thats covered
<Wizzup>
does it show something on 6.1.76?
<Wizzup>
(cpufreq)
<uvos>
no
<uvos>
but i am expecting an error/warning ofc
<Wizzup>
right
<Wizzup>
I am looking at some other commits like 3fa966ebb08132a90197cc96faa697a7a14873ee and they add a device_type = "cpu"; to cpu@0 nodes
<Wizzup>
I don't know how relevant this is
<uvos>
no idea what its for
<Wizzup>
yeah
<Wizzup>
I'm searching around a bit
<uvos>
modprobe: FATAL: Module cpufreq not found in directory /lib/modules/6.6.0-g3e1ba4fc6a7f
<Wizzup>
did we email the list about this?
<Wizzup>
yeah but it's not called cpufreq
<Wizzup>
it's called cpufreq_dt
<uvos>
as was mentioned before CONFIG_ARM_OMAP2PLUS_CPUFREQ and CONFIG_PM_DEVFREQ are disabled in config
<uvos>
but this is the same as 6.1
<uvos>
but maybe they got build as a depedancy before that was removed
<Wizzup>
I think we tried to enable these didn't we?
<Wizzup>
I mean worth trying..
<uvos>
i dont quite remember
<Wizzup>
ok we should enable those
<uvos>
anyhow they remain disabled in stock omap2plus_defconfig
<Wizzup>
I mean for our tests
<Wizzup>
so if I enable those too
<Wizzup>
and run oldconfig
<Wizzup>
it asks me for DEVFREQ_GOV_SIMPLE_ONDEMAND
<Wizzup>
if I want to enable it
<Wizzup>
and for PM_DEVFREQ
<Wizzup>
so yeah, looks like those are disabled too currently
<Wizzup>
I'll build a kernel
<Wizzup>
if we get this to work, would you be up for rebasing to latest 6.6 stable?
<uvos>
sure
<Wizzup>
btw my droid4 has 18 days uptime
<Wizzup>
still solid :)
<uvos>
yeah mine is on 6 days or so
<uvos>
6.1 has been compleatly solid
<uvos>
do send a patch to the ml if it ends being omap2plus_defconfig being broken
<Wizzup>
of course
<Wizzup>
I want to go to 6.6 just to keep a bit more up to date, and also because my mz617 needs 6.6 and I want to finish the packing for it
<uvos>
yeah sure
<Wizzup>
we should probably also have some 6.9 or higher branch at some point
<uvos>
not sure we gain anything from chaceing mroe than latest stable atm
<Wizzup>
I guess for developing features but you're probably right
<uvos>
er lts i mean
<Wizzup>
I'm going to have the entire weekend off for maemo stuff, so I'm excited to push some things along at least
<Wizzup>
I feel with some additional work we can really improve the lineup, if we can get razr screen to work ok for example
<uvos>
i think it makes more sense to integrate one device for real than to work on lots
<uvos>
the most usefull for that is probubly mz617
<Wizzup>
that is true
<Wizzup>
the razr just feels very close too, if you catch my drift
<Wizzup>
in any case, kernel building
<uvos>
my intrest has wained a bit since i only have one with a spi modem
<Wizzup>
I can send you ones with usb modems whenever
<Wizzup>
I have a lot
<uvos>
nah :)
<Wizzup>
I mean I did get them to send to folks, but ok :D
<Wizzup>
I've used it the razr for calls and it works
<Wizzup>
s/it the/the/
<Wizzup>
the battery life is pretty good too
<Wizzup>
arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi:237.30-250.4: ERROR (phandle_references): /ocp/interconnect@48000000/segment@0/target-module@72000/i2c@0/touchscreen@4a: Reference to non-existent node or label "touchscreen_pins"
<Wizzup>
still getting this when making dtbs
<Wizzup>
I think this can probably go since we have this in handset
<Wizzup>
there's also arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi:107.23-138.4: ERROR (phandle_references): /mapphone_touchscreen: Reference to non-existent node or label "touchscreen"
<Wizzup>
ok nvm for now
<Wizzup>
this was just for xyboard mz609
<Wizzup>
uvos: it's still empty
<uvos>
whats empty?
<Wizzup>
ls /sys/devices/system/cpu/cpufreq
<Wizzup>
Linux maindroid 6.6.0-ga8ce941e80fc #5 SMP PREEMPT Thu May 2 11:53:50 CEST 2024 armv7l GNU/Linux
<uvos>
right ok
<Wizzup>
but the options you mentioned above are enabled
<uvos>
cpufreq_dt loaded?
<uvos>
cpufreq_dt 16384 0 - Live 0x00000000 <- 6.1
<Wizzup>
wasn't on boot, but when I loaded it, nothing appeared
SystemError has quit [Remote host closed the connection]
uvos__ has quit [Ping timeout: 245 seconds]
<Wizzup>
mailed the ml
f_ has quit [Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.]
<Wizzup>
sicelo: ok, I see some issues with calls too atm, maybe it is 6.6, maybe it is the same you were seeing
SystemError has joined #maemo-leste
Livio has joined #maemo-leste
uvos__ has joined #maemo-leste
<arno11>
Wizzup: on my device with 6.1.76 (and i forgot to mention it), calls are buggy with TP if you don't launch sphone UI first (after boot). Sometimes it fails 3-4 times before working properly. and then everything is fine (call audio)
<arno11>
(when i say calls are buggy, i mean audio works sometime only in one way or is crappy/distorded)
<arno11>
but once sphone UI starts normally, everything is fine (excepting the weird hangup issue)
<Wizzup>
OK
<uvos__>
yeah tp backend still has issues here too whenever i try it
<uvos__>
still needs a bit time in the oven before we can promote it thats for sure
<Wizzup>
I am not sure if this is tp but will try to figure out now
<uvos__>
sure something in the stack, could very well be the kernel
<uvos__>
the issues i see are the same as arno11, well i cant say that the launch order dose anything
<uvos__>
but sometimes i get no audio
<Wizzup>
mhm
<uvos__>
while direct ofono has been 100% for me
Rodney_ has quit [Ping timeout: 252 seconds]
<arno11>
same for me, no troubles with direct ofono
<uvos__>
arno11: btw what do you mean launch "sphone"
<uvos__>
it launches itself
<uvos__>
at boot
<arno11>
i mean the caller UI
<uvos__>
really that makes a difference for you
<uvos__>
thats wierd
<arno11>
yes
<arno11>
it works, able to use it normally
<uvos__>
opening the ui just dose a dbus call to the sphone process to show a window ithas open anyhow
<Wizzup>
on 6.6 ofono backend does not work for me either
<Wizzup>
let me go to 6.1
<uvos__>
Wizzup: well its not fully rebased so the modem could just be missing
<dsc_>
uvos__> still needs a bit time in the oven :D
<uvos__>
could you check if sphone is runing at boot arno11?
<uvos__>
dsc_: btw latest jib is really great
<Wizzup>
it does say 'VOICECALL 0' and such
<dsc_>
oh cool, thanks for letting me know
<uvos__>
love the ui
<dsc_>
any wishes still
<dsc_>
?
<uvos__>
dsc_: but opening a new window via context menu dosent seam to work
<uvos__>
should it?
<uvos__>
but the context menu looks great now
<dsc_>
ah hmm
<dsc_>
yes it should work
<uvos__>
hmm
<dsc_>
new menu was wizzup's idea btw
<dsc_>
with the icons
<dsc_>
but yes better
<dsc_>
or maybe it doesnt have icons yet, i forgot
<arno11>
uvos: yes it runs on boot (because i'm able to receive 'buggy calls' immediately after boot)
<uvos__>
arno11: ok, behaivor is really wierd then
<arno11>
yep
<Wizzup>
could maybe relate to vcm somehow
<Wizzup>
uvos__: just tried on mz617, new window works there
<Wizzup>
About however shows nothing :p
<uvos__>
Wizzup: hmm
<uvos__>
yeah about dosent work here either
<uvos__>
generally i cant seam to select anythin in the context menu at all
<Wizzup>
on 6.1 calls worked ok, but I will debug more
<Wizzup>
I need to keep it on 6.1 for the moment because I am expecting a call :D
<arno11>
:D
<arno11>
6.1 is amazingly stable
<Wizzup>
I hope others will be too going forward
<Wizzup>
but we will see :D
<uvos__>
expirance says d4 random reboots and n900 dosent boot at all :P
<Wizzup>
lol
<Wizzup>
yeah
<Wizzup>
but I think it has gotten better
<Wizzup>
it might get worse when we try to improve pm
<uvos__>
tmlind: or Wizzup: do you know if the decoupeling of the kenrel serial console with pm landed in 6.6?
<Wizzup>
I don't know but I would be excited if it did
<Wizzup>
I suppose it deletes regular files in /tmp that weren't touched for a long time if the disk is getting full
<Wizzup>
kind of niche
<Wizzup>
but with year+ uptime of fremantle I suppose it made sense
<kiva>
ah..it really has good reason to that name.
<kiva>
thanks for good answer
<Wizzup>
we might eventually remove some of these things from maemo leste
<Wizzup>
especially if/when they get upstream replacements
<kiva>
nerdcore: About that font size. Pinephone screen resolution is 1440x720, AllWinner support hardware zoom 720x360 screen memory (layer) to 1440x720 screen, but there is not support for that. xrandr have software solution, you can try that.
kiva has quit [Quit: Client closed]
pere has quit [Ping timeout: 268 seconds]
<Wizzup>
I think he did
Rodney_ has joined #maemo-leste
<uvos__>
if you kiss potterings ring you get systemd-tmpfiles which dose exactly the same thing
<uvos__>
not sure if the sysv/openrc world has something like this too
<nerdcore>
decreasing the xrandr scale value from 1.0 to 0.8 helped. I might try even more scaling another day, and I will try to get some screenshots for the gang here
<Wizzup>
sweet
<Wizzup>
maybe also add it to the pinephone wiki page
<Wizzup>
(ours)
<Wizzup>
uvos__: we also get a sudo replacement then :D
pere has joined #maemo-leste
parazyd has quit [Ping timeout: 268 seconds]
parazyd has joined #maemo-leste
branon has quit [Ping timeout: 240 seconds]
branon has joined #maemo-leste
f_ has joined #maemo-leste
uvos__ has quit [Ping timeout: 272 seconds]
xmn has quit [Quit: xmn]
xmn has joined #maemo-leste
uvos__ has joined #maemo-leste
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: i opened a new issue (#737) as a reminder for last N900 tweaks
Livio has quit [Ping timeout: 246 seconds]
Livio has joined #maemo-leste
<arno11>
i forgot appmenu-gtk stuff btw
Livio has quit [Ping timeout: 252 seconds]
<nerdcore>
Wizzup: with respect, I would suggest that UI/font scaling is an Accessibility issue not specific to the PinePhone device.
<Wizzup>
I mean, sure, but there's no alternatives to doing what I suggested and it seems like a bigger issue on high dpi screens
<Wizzup>
you can put it on some other page if you want
<nerdcore>
it's not just about high DPI values. As humans get older (which we all do) our eyes go through about 3-4 changes, when we are very young and in puberty and later on in life... So likely each and every one of us will have worse vision at some time in our lives.
<nerdcore>
building accessible systems is not just about supporting people who live with disabilities today, but supporting our own future selves.
<Wizzup>
that's all fine and you get no argument from me, but right now this is the best we can do
<Wizzup>
we are planning to move to gtk3/gtk4 at a later point, but we don't have the man power to do this