Danct12 has quit [Remote host closed the connection]
<uvos>
most notably the launcher
belcher has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
Danct12 has joined #maemo-leste
<uvos>
but also tasknav etc
<Wizzup>
uvos: oh...
<Wizzup>
that would be a great catch
<Wizzup>
uvos: so it gets much more smooth this way?
dsc_ has joined #maemo-leste
Evil_Bob has joined #maemo-leste
<uvos>
no, the bug is, in the launcher etc, scolling and lifiting your finger is supposed to cause it to continue scrolling untill it coasts to a stop.
<uvos>
what happens in reality is it stops immidiatly
<Wizzup>
ah
<uvos>
this pr fixes that
<Wizzup>
I've asked fmg to look, I think he's our h-d person
<Wizzup>
meanwhile I need to figure out again why dist-upgrade doesn't work for me on experimental
<Wizzup>
*sigh*
<Wizzup>
I think I'll do that tomorrow
<Wizzup>
good catch
<Wizzup>
that's a funny one for the news post
<_inky>
uvos: >but, but we like our strange, rare, near obsolete nokia/motorola devices
<_inky>
me too, but those don't attract people and therefore developers.
vectis has quit [Ping timeout: 252 seconds]
uvos has quit [Ping timeout: 256 seconds]
vectis has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
Pali has quit [Ping timeout: 256 seconds]
Kabouik has quit [Remote host closed the connection]
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
<sicelo>
nice tmlind_ :-)
<sicelo>
_inky: you're actually correct. mentioning those devices in most rooms nowadays elicits zero response
<freemangordon>
tmlind_: we need someone to help with omapdrm
<freemangordon>
or with drm in general
<freemangordon>
I don;t know where the issue is, but according to specs drmModePageFlip should return immediately
<freemangordon>
6ms is not my understanding of "immediate"
<freemangordon>
given that 'flush' time on d4 seems to be 12.5 ms, this delay limits max FPS to 54
<freemangordon>
which is exactly what we see with 3-buffer
<freemangordon>
and it is even worse on n900
<freemangordon>
not to say that the tearing we see is a sign to a more general issue
<freemangordon>
*sign of
<freemangordon>
So, either framedone irq comes too early(so we request another flush while the previous on is still in progress), or flushing to panel should be done in a different way
pere has quit [Ping timeout: 252 seconds]
<tmlind_>
freemangordon: is this also with d4 hdmi?
mardy has joined #maemo-leste
elastic_dog has quit [Ping timeout: 260 seconds]
<freemangordon>
tearing?
<freemangordon>
have to test it
<freemangordon>
will do, later on
elastic_dog has joined #maemo-leste
<freemangordon>
Wizzup: BTW, is there tearing with ddk 1.9?
<freemangordon>
(sorry if you have already answered, I forgot)
<freemangordon>
tmlind_: yes, there is tearing
<freemangordon>
you imply that GPU is still rendering?
<tmlind_>
no just wondering if this might be limited to command mode lcd only
<freemangordon>
doesn't seem to be
<tmlind_>
ok
<freemangordon>
I am curious what Wizzup will report re ddk1.9, given he still keeps it
<freemangordon>
hmm, wait
* freemangordon
checks something
<freemangordon>
flase alarm
pere has joined #maemo-leste
inky_ has joined #maemo-leste
<sicelo>
iirc he said there is tearing in ddk 1.9 too
_inky has quit [Ping timeout: 252 seconds]
tmlind_ is now known as tmlind
<freemangordon>
:(
<freemangordon>
so, unfortunately the issue is in omapdrm, not in pvr driver or ddx
<freemangordon>
at least that's my understanding
<tmlind>
freemangordon: so how much slower is the flip on n900 then?
<uvos>
mighty17[m]: dss is on device cant idle with that isent ideling
<uvos>
also sgx
<uvos>
also your sysconfig is wrong full_log tells you what exactly in eatch category
<mighty17[m]>
uvos: well so how do i add idle support to it?
<mighty17[m]>
or do i just stop dss ???
<uvos>
omapdrm has perfectly fine support for ideling dss
<uvos>
its just broken on your device for some reason
<uvos>
could be userspace
<mighty17[m]>
cant debug that?
<mighty17[m]>
and what about sgx?
<uvos>
sgx is probubly active becasue the display is active
<uvos>
well debuging
<uvos>
run the device with minimal userspace
<uvos>
just /bin/bash
<uvos>
see if it idles
<uvos>
you have to enter dpms with the drm devices there
<mighty17[m]>
uvos: uhh how do i do that :/
<uvos>
there is no "easy" way to debug any of this
<uvos>
init=/bin/bash
<uvos>
but you dont have serial
<uvos>
so really no idea
<bencoh>
actually there is, but not with a full-blown maemo
<bencoh>
unless you disable everything
<mighty17[m]>
uvos: welp :(
<bencoh>
serial on d4 is easy though
<uvos>
he isent on d4
<bencoh>
oh, my bad
<uvos>
hes on some samsung tablet
<uvos>
problem is he cant interact with the device at all without full blown gui userspace
<bencoh>
that'll be hard yeah
<uvos>
no otg not serial and no keyboard
<mighty17[m]>
uvos: at max i have ssh
<uvos>
yeah i mean make yourself a runlevel with just the absolute minimum to connect with ssh
<uvos>
ie just load the wifi kernel module and have bash + wpa_supplicant
<uvos>
and ssh and nothing else
<mighty17[m]>
ow thats gonna be a lot of work
<mighty17[m]>
well any other way i can improve my battery life?
<uvos>
mo
<uvos>
no
<uvos>
its not _that_ hard
<uvos>
also check what drm output is active in sysfs
<mighty17[m]>
omapdrm?
<uvos>
also go around sysfs and check the runtime pm states of varoious devices
<uvos>
but really you need a minimal system
<bencoh>
wait, why wifi? don't you have usbnet?
<uvos>
otherwise figureing out what is using what and keeping it active and what is the kernel not implementing pm on some device is going to be nigh impossible
<mighty17[m]>
i do....
<uvos>
oh you do
<uvos>
last i heard usb dident work
<uvos>
well use that
<mighty17[m]>
thats why i said ssh
<uvos>
ok
<mighty17[m]>
uvos: usb otg
<uvos>
well minimal system with just usb net
<uvos>
then
<mighty17[m]>
i have no idea how'd i do that
<uvos>
well maybe focus on why dss isent ideling first
<uvos>
that should be possible with full system
<uvos>
thats not enough to get it to idle ofc
<uvos>
but its a first step
<uvos>
omapdrms outputs arnt in dapm state
<uvos>
so figure out why
<mighty17[m]>
wait wait, lemme understand
<uvos>
some of the stuff that omapconf reports as errors in sysconfig are proububly easy pickings too
<mighty17[m]>
uvos: maybe coz it isnt getting the clk it wants
<uvos>
see full_log
<mighty17[m]>
`/os_idle_uc_audit_summary.txt` ?
<uvos>
no
<uvos>
full_log
<uvos>
you have to specify that omapconf shal create it in its cmdline
<uvos>
anyhow on d4 we have 6 errors in omapconf - those are related to off mode not working and some spurtious ones with clock rates
<uvos>
you have 12
<uvos>
so check out what those 6 extra are and fix em.
<mighty17[m]>
Alright, thanks for the help! I'll try to check those extra 6
<uvos>
"[14:51] <mighty17[m]> uvos: maybe coz it isnt getting the clk it wants" i have no idea what you mean by this
<uvos>
but if somehing isent geting the right clock you should fix that ofc
<mighty17[m]>
uvos: I don't know how to fix that tho! I put the correct value and my display goes crazy, I have to put half the value
<uvos>
anyone else haveing issues with dtschema when building 5.16-rc3?
<uvos>
tmlind: maybe
<uvos>
sort: -:2: disorder: 2021.02
<uvos>
ERROR: dtschema minimum version is v2021.2.1
<uvos>
anyone here have a bit more expierance with debootstrap?
<Wizzup>
I think bencoh has some, looking at his lxc setup
<uvos>
i can create a debian rootfs just fine
<uvos>
but if i try to create a devuan one
<uvos>
i end up with no init
Wikiwide_ has joined #maemo-leste
<uvos>
so imanaged to boot devuan on mz617 depolying lest on
<uvos>
this thing is going to be fun
<uvos>
we have to create a small 600 mb ish image that we flash to preinstall that copyies itself over to userdata and then downloads the rest of the packages
<Wizzup>
uvos: hm... making a small image isn't a big problem if we make it interactive I guess