<Wizzup>
did you also figure out the other difference between tmlind's droid4?
<Wizzup>
iirc in omapconf?
<Wizzup>
btw we should sync stuff from devel to stable when the n900 X stuff is stable (and then we'll do a droid4-image)
<Wizzup>
err omap-linux pkg
<uvos>
yeah so we have a device more active than tmlind
<uvos>
but i have not done anything to see why
<uvos>
this is also true for xt75
<uvos>
*xt875
<uvos>
so its seperate from the xt875 difference
uvos has quit [Ping timeout: 256 seconds]
<Wizzup>
ok
* Wizzup
zz
Pali has quit [Ping timeout: 252 seconds]
amk has quit [Ping timeout: 256 seconds]
amk has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 260 seconds]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
<freemangordon>
do we know why omap8250_set_mctrl oops-es on poweroff/reboot?
<freemangordon>
on d4
_inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
elastic_dog has quit [Ping timeout: 268 seconds]
inky_ has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
<freemangordon>
hmm, modesetting tearing with HW accel means that omapdrm has some issue
_inky has joined #maemo-leste
<freemangordon>
tmlind: uvos: does anyone of you have access to d4 vendor kernel source code?
<freemangordon>
I need to know if vendor kernel uses PROGRAMMEDLINENUMBER_IRQ or TE_TRIGGER_IRQ
pere has joined #maemo-leste
<tmlind>
freemangordon
<tmlind>
omap8250_set_mctrl pm is broken
<tmlind>
freemangordon: you can find the stock v3.0.8 kernel on github, i use github.com/NotKit/android_kernel_motorola_omap4-common as it's been patched for gcc v6
<tmlind>
can't find those defines there
<tmlind>
sounds like omap8250_set_mctrl needs serial8250_rpm_get() and put around it
xmn has quit [Quit: ZZZzzz…]
uvos has joined #maemo-leste
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
<Wizzup>
uvos: looks like it worked indeed
<Wizzup>
in the morning my d4 still said 'two days left'
<Wizzup>
(I didn't charge it since the evening)
<Wizzup>
took about 15% in ~8-9 hours
<Wizzup>
so that's like 54 hours
<Wizzup>
08:55 < freemangordon> hmm, modesetting tearing with HW accel means that omapdrm has some issue
<Wizzup>
just to be clear, why is that?
<Wizzup>
modesetting also has tearing problems does it not?
<Wizzup>
it has on my amdgpu
<Wizzup>
well actually that is not modesetting I think
<Wizzup>
in any case even my amdgpu needs: randr --output HDMI-A-0 --set TearFree on
<uvos>
btw the device we have on more than tmlind is the audio codec
<uvos>
but i have really no idea why
<uvos>
booting w/o pulse dosent help, messing with the mixer dosent help and blacklisting the faling hdmi audio module dosent help either
rafael2k has joined #maemo-leste
<Wizzup>
uvos: maybe it's some modem config?
<uvos>
its the omap4 audio codec
<Wizzup>
rafael2k: will try to do all the pkgs today, had christmas/family stuff
<uvos>
the modem is not involved
<Wizzup>
uvos: hm
<Wizzup>
uvos: kernel config diff?
<Wizzup>
hdmi related?
<rafael2k>
Wizzup: hey!
<uvos>
maybe
<uvos>
i balcklisted hdmi audio
<rafael2k>
what up!
<rafael2k>
Wizzup: which packages? just got sick as a dog the last days... after covid I got some virus
<Wizzup>
ofono, kernel, etc
<Wizzup>
the work you did
<Wizzup>
I'll get it packaged
<rafael2k>
they worked well
<Wizzup>
I need to go out and pick up some friends from the station
<uvos>
Wizzup: sure maybe something keeps alsa busy even when pulse is not there
<rafael2k>
I'm using for days
<Wizzup>
yeah but we need them in the CI etc
<uvos>
via alsa
<Wizzup>
rafael2k: great
<uvos>
could be mis or soemthing
<Wizzup>
uvos: I am not sure if I have hdmi blacklisted, maybe some probe doesn't complete
<uvos>
Wizzup: the probe of hdmi audio errors out yes
<uvos>
since 5.9 irrc
<rafael2k>
just the kernel postinst needs some care, like copying dtbs are copy kernel and initrd to the proper place to make uboot pick them by default
<rafael2k>
also, is it normal that I get "Calibration needed" for battery applet?
<uvos>
rafael2k: btw could you implement the emergency shell on pp via the volume buttons?
<rafael2k>
sound setup need some care with newer kernel need some care too - this is my next goal
<uvos>
"Calibration needed" is normal if the battery dosent report its current full cap.
<rafael2k>
uvos: could be, through u-boot right? Any hint what command args to pass to kernel?
<Wizzup>
uvos: maybe this is not the case for tmlind
<rafael2k>
uvos: I realized no matter what, battery always shows changing, even after a long time charging...
<uvos>
yes via uboot, would be cool if one of the vol buttions woudl cause the device to boot that
<uvos>
Wizzup: tmlind reported the hdmi autio bug too i think but <---- tmlind
<rafael2k>
sure, that would be easy, and indeed, with three options (vol up, vol down, and no vol pressed) it is good for the common user (one for eMMC, one for emergecy shell, default for maemo normal boot)
<rafael2k>
Wizzup: ok!
<uvos>
rafael2k: youll need fbkeyboard installed
<rafael2k>
uvos: ok
<rafael2k>
one feature I did not see in other pinephone distros is the call recording VoiceCall profile... I'd like to implement this too. How cool wouldnt it be to record a real CS voice call!
<rafael2k>
or just plug any audio recorder in the pa source and voila!
<rafael2k>
just on very new Android phones this is available, and I don't think there is even official API for that
<uvos>
not really
<uvos>
its been avaiable on random android phones for a long time
<uvos>
mostly beacuse of regulatory reasons
<rafael2k>
anyway, it does not matter, we can do it
<uvos>
yes
<rafael2k>
; )
<uvos>
would be great to have sphone support this via module
<uvos>
xt875/xt894/xt860 can also do this
<rafael2k>
that is what I'm thinking
<rafael2k>
btw, this battery issue that upower does not report its current full cap can fuck up the battery?
<uvos>
no
<rafael2k>
tks
<rafael2k>
can we hardcode this somehow to make it nice in the UI?
<uvos>
im sure the pp's hw setup can report battery capcaity if callibrated
<uvos>
i just dont know how beacuse i dont have one
<rafael2k>
right
<uvos>
on many devices you have to charge fully and discharge the device fully once in a single boot
<uvos>
for it to mesure the capacity
<rafael2k>
right, I can do this and see what happens, tks!
<freemangordon>
it should not, as it does page flip
<freemangordon>
page flip happens on vsync (in theory) so it should not tear
<freemangordon>
all this with compositing ofc
<freemangordon>
so, compositing + page flip should not tear, IIUC
<freemangordon>
but it does
<freemangordon>
which means page flip is somehow broken, thus omapdrm has issues
<freemangordon>
does that make sense to you?
<Wizzup>
well I know that modesetting is not considered tear free on I think any device
<freemangordon>
Wizzup: but, why should it tear with compositing WM, like h-d?
<freemangordon>
I mean, rendering happens like (with 2-buffer):
<freemangordon>
2. page flip is queued for that back buffer
<freemangordon>
3. page flip happens
<freemangordon>
4. old back buffer is now front, old front is now back and is given to GPU to render the next frame
<freemangordon>
1. back buffer is being rendered
<freemangordon>
there is simply no way front buffer to be rendered to
<freemangordon>
Wizzup: also, on PP there is absolutely no tearing
<freemangordon>
modesetting/glamor
<uvos>
compositing window managers sould be able to prevent tearing on modesetting without tear free, yes
<uvos>
unless you have multiple monitors
<uvos>
or your talking about x draw call tearing
<freemangordon>
it seems Wizzup is talking about that,yes
<freemangordon>
there I agree we cannot prevent tear
<freemangordon>
but with h-d there should be none
<freemangordon>
and at least on PP this is what happens
<Wizzup>
freemangordon: hm ok wrt compositing
<freemangordon>
uvos: tmlind: do you know why te_support is false in droid4 panel data?
<Wizzup>
freemangordon: hm @ pp and tearing, I need to check
<freemangordon>
I already did, but yes, please do
<freemangordon>
with latest fixes that is (clutter)
<uvos>
freemangordon: no
<Wizzup>
ok
<freemangordon>
uvos: so, panel driver in vendor kernel should be panel-mapphone.c, right?
_inky has quit [Ping timeout: 256 seconds]
pere has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
<uvos>
freemangordon: i would say so, but cant confirm since uvos.xyz is currently down and i cant find where i have the dmesg from stock kernel locally
inky_ has quit [Ping timeout: 240 seconds]
<freemangordon>
ok. looke tear-free is enabled there
<freemangordon>
*looks
<freemangordon>
going to enable it in our kernel and test
pere has joined #maemo-leste
<freemangordon>
doesn;t look good
<freemangordon>
"DSI: omapdss DSI error: TE not received for 250ms!"
_inky has joined #maemo-leste
<rafael2k>
I come back later
peetah has quit [Ping timeout: 252 seconds]
rafael2k has quit [Quit: BitchX: the headache medicine]
<uvos>
so i managed to make cpcap-charger charge reliably even on the most crapy of cables
<uvos>
by having it ramp up current slowly instead of instantly switching on charging
<Wizzup>
makes sense
<Wizzup>
that's neat
<freemangordon>
hmm, tear-free support in omapdss is FUBAR :(
<uvos>
complain on linux-omap i gues
<freemangordon>
I don;t really get why it is so hard to keep what is already working when new things are implemented
<freemangordon>
yeah
<uvos>
there was some pretty big refactoring to dss in 5.10 or so
<freemangordon>
I would say it has never been implemented
<uvos>
maybe check if worked before then (if its easy)
<uvos>
freemangordon: ok
<freemangordon>
I think it was working in omapfb
<freemangordon>
but not in omapdrm
<freemangordon>
actually, there seems to be some TE support
<freemangordon>
but, it seems it is supported only the gpio variant
<freemangordon>
but not fully
<freemangordon>
because, for example n950 has te-gpios in DTS
<freemangordon>
but panel data says te_enabled=false
<uvos>
appearntly the CPCAP_REG_CRM_CHRG_LED_EN register bit is load bearing
<uvos>
:P
<uvos>
(charging fails entirely if you try and use it to disable the light)
<uvos>
wierd
xmn has joined #maemo-leste
<tmlind>
uvos: that's weirde
<freemangordon>
tmlind: there is a note in omapdrm framedone handler, that we have framedone irq when "DISPC has finished sending pixels"
<freemangordon>
but: "However, DSI still has the pixels in its buffers"
<freemangordon>
so, if I read that correctly, we cannot use framedone as vsync
<freemangordon>
OTOH tear-free is enabled in vendor kernel
<freemangordon>
I tried to enable it in our, but it leads to lots of errors
<freemangordon>
obviously I am missing something
<tmlind>
freemangordon: ok no idea about that one
pere has quit [Ping timeout: 256 seconds]
TonyStone has quit [Quit: Leaving]
pere has joined #maemo-leste
<_inky>
Wizzup: i updated pinephone from devel, and wow, you made a lot of progress. there are still problems, but it's now much much better.
<Wizzup>
yes the other problem is a lima bug
<_inky>
mahjong is playable, keyboard almost always works, but sometimes some buttons "stuck", like on real keyboard, when it went down but doesn't come back, so in our case keyboard's key can remain in blue color, instead of getting the default color. also after some time it can again become blue.
<_inky>
the other problem that i see is with my lightmeter application: when you press on a popup-menu with list of aperture or shutter settings
<_inky>
it often reappears again when not pressed, just old memory.
<_inky>
so the video driver is haunted by old memories. (:
<Wizzup>
yes, swap buffer problem
<_inky>
is that the same as lima bug?
<Wizzup>
yes
<_inky>
is lima driver open, does anyone work on it? did you try latest version? i remember sxmo was perfect though it was x.
<_inky>
sorry i know you put a lot of work.
<_inky>
but i came to express the gratitude.
<_inky>
so thank you this changes many many many things.
<_inky>
i'll try now to use it on a daily basis under maemo.
<_inky>
it's a pity, megapixels (camera) app uses gtk4, and megapixels-compat (just tried it, i have a build in my home) is first of all, rotated
<Wizzup>
yeah
<_inky>
and secondly it updates the screen slowly.
<_inky>
but i guess it is possible to make a photo with some effort. i'll experiment further.
<_inky>
i meant by the question, did you reach the deadend already, or there is hope for further improvement?
<Wizzup>
I need to file a bug with lima
<_inky>
great.
<Wizzup>
I have the trace, I just need to read back what fmg wrote to me
<uvos>
sxmo likely works becaue it dosent comopse via gl
<_inky>
yes, true.
<_inky>
but this is much much much much better already.
<uvos>
you can suspend composistion on windows that give you trouble as a workaround until upstream hopefully fixes the issue
<_inky>
i'll try frozen-bubble as well, it was a disaster before.
<uvos>
not sure how you play forzen-bubble on pp. otg keyboard?
<_inky>
yes, with bt kbd.
<_inky>
i wanted to make a video comparing frozen-bubble on droid4 and pp.
<_inky>
dino xmpp client has a 'handy' branch with small screen optimized interface, plus they added voice and video calls.
<_inky>
i'll build it, if it turns out well, will add it to maemo repos.
<uvos>
yeah would be great to get libhandy applicaitons to work on maemo
<uvos>
but they need newer gtk3 etc
<_inky>
hmmmm. didn't think of it. didn't think dino uses libhandy.
<_inky>
i think it doesn't.
<uvos>
and also plamo applicaitons
<_inky>
not sure. will find out.
<_inky>
plamo?
<_inky>
plasma?
<uvos>
plasma mobile
<_inky>
ah.
<_inky>
maemo feels (even with the breaks it has currently) more lightweight than phosh.
<_inky>
that is also why it is more attractive to me. also i don't like phosh' interface: the minimized windows on the top need to be scrolled through to choose a window to push out.
<uvos>
phosh was terribly laggy on xt1602 when i tried it
<_inky>
in maemo all minimized programs are visible in one screen and it is very cool.
<uvos>
but plamo was fine
<_inky>
from what i see (didn't install plamo myself, but my two friends have pinephone) phosh is much faster than plasma.
<_inky>
i think i've heard that's because plamo has a lot of js running.
<_inky>
on the other hand, one of my friends uses sailfish on pinephone, and it is pretty smooth and feels fast.
<uvos>
yeah but the fact that hildon is almost terrible in portrait is a problem imo since you cant get to the buttons at the top one handed (unless you have the hw buttons like d4)
<uvos>
i still want to fix that
<_inky>
nothing is ever as slow as with phosh.
<uvos>
otherwise hildon is pretty good ui wise
<_inky>
yes, right?
<_inky>
(:
<_inky>
btw, on ui, dino mobile put the 'back' button to the left upper corner of the ... of itself.
<_inky>
that's the most far place for the fingers to reach.
<uvos>
ios dose this too
<_inky>
i noticed today maemo places the similar button at the right corner.
<uvos>
its idiotic
<_inky>
never used ios, but wow, i thought it is well designed.
<uvos>
on modern phones this means the back button is like a km awayy
<uvos>
well to be fair they have gesture navigation now
<uvos>
so its mitigated
<_inky>
today i received a battery for my wife's google nexus s, i know postmarket supports it, probably will install sxmo on it to test how is it. it was also supported by SHR distro, i remember, but it's very very very old now.
<_inky>
SHR was for openmoko phones.
<_inky>
and is currently dead. they still have the site i guess.
<_inky>
i hope.
<_inky>
it used enlightenment toolkit.
<uvos>
i dont think messing with shr is usefully anymore
<_inky>
me too, i'll try sxmo. but i'm afraid it'll be anyway too heavy for that device.
<_inky>
it is comparable with droid4, i guess.
<uvos>
no
<uvos>
galaxy nexus is comparable to d4
<uvos>
nexus s is more d2
<_inky>
oh. thanks!
<uvos>
nexus s is 1 core cortex-a8
<_inky>
i also guess, pinephone under maemo doesn't go to sleep, that's why it will eats more battery power. but not sure, now after upgrade how is it.
<uvos>
ie /4 cpu performance of d4 just about
<_inky>
wow!
<_inky>
i have a fibbonacci benchmark that works on one cpu
<_inky>
i'll try. surprisingly pinephone gave me about same performance (almost) like xperia xa2 with sailfish.
<_inky>
and how would you compare pinephone? i don't understand its hardware.
<_inky>
i understand more or less quallcom chipsets as reference point.
<_inky>
is pinephone a 4cpu version of droid4? in terms of cpu power?
<uvos>
no idea what soc dose it have?
<_inky>
minute
<_inky>
it doesn't list soc, it lists several cpus, a something
<uvos>
its lots faster than d4 for sure
<_inky>
let me find
<sicelo>
i love enlightenment stuff, and can't wait till they're fully wayland)
<_inky>
seriously, huh? i don't understand this wayland anyway. is it really that better than xorg? i love maemo for being able to use ssh forwarding with it.
<uvos>
so pp soc is really close in perf to MSM8916
<uvos>
if that tells you anything
<uvos>
since both are 4x Cortex-A53
<uvos>
so same as xt1602
<_inky>
uvos: Quad-Core Allwinner A64 @ 1.152 GHz
<_inky>
yes, you found it.
<uvos>
wayland is better than x11
<_inky>
so it's like snapdragon 410
<uvos>
while the wayland display servers/wms are not really better than xorg and often worse
<uvos>
yeah snapdragon 410 is marketing speak for MSM8916
<_inky>
i think i can tolerate it on xorg. well, i patched that squeeekboard with armenian layouts, it is really very useful.
<_inky>
and the fact that vkbd opens a separate window to type freaks out my friends from maemo.
<uvos>
with good reason the vkb is bad
<_inky>
"i think i can tolerate it on xorg" i meant "i think i can toleraty wayland on phone"
<_inky>
it is so discouraging that programs written for sailfish is very hard to port to other linuxes, authors tell me they need to rewrite ui from scratch.
<uvos>
this is a problem that fremantle/leste applications also have sadly
<uvos>
less, but still
<_inky>
and though sailfish is really nice, and lightweight, i don't feel like putting efforts in to it.
<_inky>
but with fremantle/leste it is much better.
<uvos>
the mobile toolkit space on linux suffers from crippling fragmentation
<_inky>
i write on my computer, then build on device and it works.
<_inky>
but i agree, i understand what you usually say very well.
<_inky>
i also would like hildon to be something like gnome or phosh, installable on any distro.
<sicelo>
it can, if someone's willing to package it there ... pmOS packaged it at some point
<sicelo>
and it was in official debian repos even in fremantle days
<_inky>
i remember about pmos, i think it rings a bell about debian, but wasn't it more like diablo days? whatever, yes, that would be cool.
<sicelo>
maybe. i know there used to be hildon packages in debian, although i never used them myself
<Wizzup>
21:49 < _inky> i also guess, pinephone under maemo doesn't go to sleep, that's why it will eats more battery power. but not sure, now after upgrade how is it.
<Wizzup>
unchanged
<Wizzup>
we need to think about how/if we want to integrate those sleep hacks
<uvos>
probubly a button in power menu: sleep
<Wizzup>
or do it automatically when locked
<uvos>
and a quirks-pinephone mce module that makes it happen
<uvos>
hmm what about listening to music or downloading files compileing etc?
<uvos>
dosent pinephone need to suspend?
<Wizzup>
uvos: yes, so none of that will work
<Wizzup>
or it needs like clever hacks
<Wizzup>
but it can never work well
<Wizzup>
I don't want to add wake locks or anything like that atm
<uvos>
so "or do it automatically when locked isent an option"
<uvos>
and failing android style wake locks only a sleep button remains
<sicelo>
isn't a wake lock a mechanism to *prevent* sleeping/idling?
<uvos>
no
<uvos>
well yes but no
<uvos>
:P
<uvos>
the wake locks on android tell the os that it can suspend to ram, (if the hw needs it for pm its not used on d4 for instance or on xt1602) if none are held
TonyStone has joined #maemo-leste
<uvos>
one could for instance add a .desktop prop that tells hildon it can infrom mce that we cant suspend
<uvos>
and suspend in all cases where the display is off and no applicaiton with sutch a .desktop file is open
<uvos>
effectively creating android style wakelocks on lesste
<uvos>
this would work pretty well (not nearly as good as android but still)
<_inky>
so do you know how maemo fremantle or sailfish work, they receive jabber messages immediately, they see that the contact changed status immediately.
<_inky>
and still the battery works very well.
<_inky>
pinephone sleeps under pmos, so when i start using it, dino reconnects, and syncs messages.
<_inky>
i guess sailfish and maemo fremantle don't sleep.
<_inky>
you said the os can put some apps to sleep depending on .desktop file.
<_inky>
but whole os doesn't sleep right?
<Wizzup>
on pp it has to to save battery
<sicelo>
_inky: fremantle doesn't suspend-to-(ram/anything else) in the way pmOS and others do for pp (hence Wizzup's comments earlier). instead, runtime power management is used. pmOS recently started documenting something along those lines here, https://wiki.postmarketos.org/wiki/Runtime_Power_Management
<_inky>
hmmm. but i don't understand what does it mean it needs to suspend?
<_inky>
just curious.
<_inky>
why it needs to? because of the some features of chipset?
<_inky>
ok let me see the wiki.
<sicelo>
yes soc must support it in mainline. seems TI OMAP have some of the best support for that kind of power management, as far as linux kernel is concerned. even there making it work reliably isn't a walk in the park (e.g. for N900 it's currently not very trivial)
<_inky>
the device lacks untime power management with mainline kernel.