Oksanaa has quit [Read error: Connection reset by peer]
Oksanaa has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
Pali has quit [Ping timeout: 250 seconds]
System_Error has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
rafael2k has quit [Ping timeout: 240 seconds]
joerg has quit [Ping timeout: 256 seconds]
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
<freemangordon>
uvos: Care to share how you made that work and eventually do a PR?
<freemangordon>
because in leste d4 images (at least) there is no sound in FF
pere has quit [Ping timeout: 268 seconds]
Twig has joined #maemo-leste
akossh has joined #maemo-leste
pere has joined #maemo-leste
Pali has joined #maemo-leste
Oksanaa has quit [Ping timeout: 256 seconds]
rafael2k has joined #maemo-leste
avoidr has quit [Ping timeout: 240 seconds]
avoidr has joined #maemo-leste
avoidr has quit [Ping timeout: 240 seconds]
avoidr has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: i dident do anything, this has allways worked for me. it also works on a d4 i qute recently installed and upgraded to devel (last weeks image i think)
<uvos>
so its a very recent problem or confined to stable
<Wizzup>
freemangordon: ok I think I hit the display not turning on problem
<Wizzup>
what did you want me to do again?
<Wizzup>
wait it turned on now...
<Wizzup>
tmlind: uvos: so I'm having to offline/online my modem a lot to get my pending messages flushes out, weird
<uvos>
Wizzup: i havent used the modem in a while
<uvos>
Wizzup: so maybe this is a new issue
<uvos>
or i just dident notice, what are the symptoms?
<uvos>
are they not sent or sent more than once?
<Wizzup>
they are not sent and just in pending messages
<uvos>
hmm
<Wizzup>
I sent like a bunch with telepathy-ring and they weren't delivered for a day or two
<uvos>
that worked for sure realiably ~1 month ago when i was useing sms often
<Wizzup>
ok
<uvos>
i think i saw it double send a couple of times
<uvos>
or maybe sphone was buggy dunno
<Wizzup>
I mean if ofono misses a confirmation of sending (could be some kicks again) then that is possible
<uvos>
might be related to wether the carrier dose dlr
xmn has quit [Ping timeout: 250 seconds]
<Wizzup>
rigt
<rafael2k>
I did not see any sms problems
Daanct12 has joined #maemo-leste
<Wizzup>
rafael2k: pinephone is different from d4 :)
Danct12 has quit [Ping timeout: 240 seconds]
pere has quit [Ping timeout: 256 seconds]
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 256 seconds]
<uvos>
freemangordon: so the mce power key issue is fixed, as far as possible
<uvos>
there are actually lots of issues, all of witch can be repoduced on fremantle
<uvos>
you just have to be a bit quicker, as mentioned
<uvos>
anyhow mce now uses kernel event times intstead of its own timers
<uvos>
this fixes single presses being reigsterd as long, doubles as singles etc due to mce stalling
Daaanct12 is now known as Danct12
<uvos>
it also checks if those times straddle a mode change to avoid applying the event to the wrong mode because it changed in between it happening and the mode changing
<uvos>
however not all problems are fixable and the mce/systemui architecture of global state loosly synced between deamons is fundamentally flawed
<freemangordon>
uvos: great, thanks, will test as soon as I can
<freemangordon>
yeah, I know
<uvos>
single presses can still be registerd wrongly as long in extream circumstances
<freemangordon>
mhm
<uvos>
and mce will discard events now that straddle a mode change
<uvos>
so because it cant apply them correctly
<uvos>
this causes events to be missed sometimes
<uvos>
ie opening the power menu right after exiting tklock
<uvos>
may fail
<uvos>
theres nothing that can be done about this
<freemangordon>
that's not really I big issue
<freemangordon>
we can;t (or rather should not) queue events, IIUC
<freemangordon>
lemme upgrade and test
<uvos>
freemangordon: still building
<freemangordon>
ok
<uvos>
just finished
<uvos>
for amd64
<uvos>
so wait a bit
<freemangordon>
yeah
<freemangordon>
hmm, neither hildon-status-menu nor hildon-home register new applets :(
<Wizzup>
freemangordon: if you pkill it works I guess?
<freemangordon>
maybe this has something to do with multi-arch
<freemangordon>
yeah, but it should not be needed
<freemangordon>
lemme check what's goign on
rafael2k has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: so I think I see X being stuck in drm ioctls again
<Wizzup>
what did you want me to check?
<freemangordon>
if all the fences are signalled
<Wizzup>
so /sys/kernel/debug/dma_buf
<freemangordon>
yes
<Wizzup>
hmm now it works again, but it took forever to unlock
<Wizzup>
and touchscreen still doesn't react
<uvos>
Wizzup: i think i see this in charge-mode
<uvos>
Wizzup: btw
<uvos>
Wizzup: if you run charge-mode for a long time
<Wizzup>
freemangordon: btw you mean /sys/kernel/debug/dma_buf/bufinfo right
<uvos>
Wizzup: since switching to drm it somtiems hangs
<freemangordon>
Wizzup: yes
<freemangordon>
maybe pastebin it
<freemangordon>
but not it works again, it makes no sense
<uvos>
id like to also recommend making tklock the singlepress action on devices with just a power button and no lock slider. The doublepress is really janky beacuse it cuases the singlepress action to be executed first and then also the double press action so the power menu shows for a while and then the device turns off.
<uvos>
this is impossible to fix
<uvos>
as the timout is really long (1s)
<uvos>
so singlepress latecy is way to long if you wait and see if its a double press or not
<Wizzup>
we can change this in leste-config right?
<uvos>
sure but then you double press is hard
<uvos>
wich is also bad for a action that is really the most common thing you do with the button
<uvos>
(ie lock the device)
<freemangordon>
somehot this works fine on fremantle
<uvos>
nope
<uvos>
you can see i happen there too
<uvos>
*it
<freemangordon>
yes, I am using that hundreds of times every day
<Wizzup>
rsync: write failed on "/home/amprolla/images/droid4/20220116/maemo-leste-1.0-armhf-droid4-20220116.img.xz": No space left on device (28)
<Wizzup>
we really should just host it somewhere else
<tmlind>
ok
<Wizzup>
in 1-2 hours there will be a new one
<Wizzup>
but we didn't change anything in stable so you can just take the previous one and upgrade to -devel
<humpelstilzchen[>
cool now I have a welcome screen with ssh credentials - that might help a lot for future users :)
<Wizzup>
humpelstilzchen[: yeah, it is :)
<Wizzup>
uvos: ^^ :)
<tmlind>
Wizzup: ok thanks i'll try again a bit later then
<freemangordon>
sicelo: actually, you should not have "add widget" button enabled, as when you install new h-h applet, it should be placed automatically on the desktop ;)
<freemangordon>
and this is what is broken :)
<freemangordon>
well, *was* broken
<freemangordon>
after the fix there remains a minor issue in h-h that even after you uninstall an applet, it is still selectable in the menu
<Wizzup>
humpelstilzchen[: btw if you're up for helping with the keyboard layout, lmk, I ordered a keyboard but it will take a few weeks before I get it
<humpelstilzchen[>
Wizzup: thanks for your help. I will probably come back for you. But first I'm going to get some "feeling" for the keyboard and fine some replacement programs for the ones I'm missing from the n900
<Wizzup>
ok
<Wizzup>
which programs are you missing?
<humpelstilzchen[>
I don't have the full list yet. There was easylist, which was a todo/shopping list. Maybe the sources are still in the internet and can be compiled. A weather and calendar widget would also be nice, does that currently exist?
<humpelstilzchen[>
And is there a recommended browser?
<uvos>
qtwebbrowser works well ootb, or firefox works very well but needs hwkbd and some envvars about:config entrys
<uvos>
calendar widget exits and works fine bte
<uvos>
no weather
_inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
_inky has joined #maemo-leste
huckg has quit [Ping timeout: 256 seconds]
<uvos>
freemangordon: so did the mce race fix solve your issues?
<freemangordon>
uvos: at least on PP it looks to behave fine
<freemangordon>
have guests so didn't have time to play on d4
<freemangordon>
will report as soon as I test it
<freemangordon>
uvos: RE firefox - do we have those settings documented somewhere?
mepy has quit [Remote host closed the connection]
mepy has joined #maemo-leste
<freemangordon>
uvos: why it takes so long for mce to lock screen on d4? on PP it happens in an instant.
<sicelo>
freemangordon: ty @fix. i haven't tested it yet, but nice finding. i'm not sure i fully like widget auto-placement in desktop, but i definitely prefer it over having to kill hd/hh or reboot :-)
<freemangordon>
sicelo: this it how it was designed to be. and honestly, it kind of makes sense
<freemangordon>
imagine if you are not familiar with maemo
<freemangordon>
you would expect to see what you have just installed somewhere
<sicelo>
right, :-)
<uvos>
freemangordon: so quirks-mapphone is pretty slow (it waits for the modem and kernel several times) also d4 has a lot of input devices, it waits for x for eatch one
<freemangordon>
uvos: can;t we reorder?
<freemangordon>
as it takes nearly 2 seconds
<uvos>
no
<uvos>
reording is an ordeal if you want tklock to work
<uvos>
otherwise yeah my setup is reorderd for performance
<freemangordon>
we cannot turn display off first? why is that?
<uvos>
and its very fast
<uvos>
because its determined by the module loading order
<freemangordon>
uvos: sorry, I don;t get that
<uvos>
the module loading order is however also subject to lots of subtle bugs
<uvos>
in the old modules
<uvos>
so mce uses data pipes
<freemangordon>
so, "turn off" callbacks are called in module load order?
<uvos>
yes
<uvos>
so every module registers its callbacks
<uvos>
and they are called in the order they are registerd
<uvos>
most callbacks are regsiterd at load time ofc
<uvos>
changing the order breaks the legacy/fremantle modules
<uvos>
because they use global state
<uvos>
so the callbacks that modify global state break later callbacks
<freemangordon>
well, we can implement priority, no?
<uvos>
you could but you would have to untange a huge mess
<freemangordon>
or, have a separate module for turning the display off that's loaded first
<uvos>
a better way is to reimplement the mess
<uvos>
(wich i have done for myself)
<uvos>
and make stuff async
<uvos>
lots of stuf could be async
<freemangordon>
uvos: no matter what, the same legacy module on fremantle turns display off on an instant
<freemangordon>
*modules
<uvos>
freemangordon: sure they dident run into the issues as mutch, mce as just a lot more to do on d4
<uvos>
also the problem is that its dose just ipc
<uvos>
and the ipc its doing is stalling it wating for other processies
<freemangordon>
well, no matter the reason, this is not really user friendly
<freemangordon>
I know you don;t use double-press, but that's no reason to not implement it right
<uvos>
wdym
<uvos>
i fixed double press
<uvos>
otherwise make stuff async
<freemangordon>
sorry, was it broken?
<uvos>
yes it was
<uvos>
(also on fremantle)
<uvos>
anyhow make mce more async so it dosent wait for other processies all the time
<uvos>
is the fix
<uvos>
ofc thats lots of work
<uvos>
also figure out why dpms is so damn sloww
<uvos>
thats just a ddx thing
<freemangordon>
I don;t know what you mean by "broken", but on fremantle double-press locks the device instantly
<freemangordon>
on d4 it takes 2 seconds
<freemangordon>
yeah, dpms
<freemangordon>
we may have kernel issue there
<freemangordon>
I think it is related with vblank patch
<freemangordon>
I will do some experimenting with that reverted
<freemangordon>
but, if on d4 we wait modem and whatnot to be turned off before even trying to turn off the display, then I would say we have a bad design
<uvos>
yes
<uvos>
this is the design of mce
<uvos>
it dose suff in serial and order cant be controlled
<freemangordon>
we shall implement some control then
<freemangordon>
as I said - priority
<freemangordon>
no need to do it asunc
<freemangordon>
*async
<uvos>
async is mutch better
<uvos>
really
<uvos>
and there are easy wins here
<freemangordon>
as I can imagine this will be a huge task
<uvos>
no
<uvos>
there are some self contained easy wins here
<uvos>
priority ordering is a huge task
<freemangordon>
uvos: the easiest way is with priorities
<uvos>
to make it not mess with the global state problem
<uvos>
no
<uvos>
its gona be pretty insane
<uvos>
trust me
<freemangordon>
see, it is not that I didn;t work on mce code
<uvos>
at this point i have rewritten all modules
<freemangordon>
it is just that it was some time ago
<uvos>
(that i use)
<freemangordon>
uvos: ok, but having such a big delay for such a simple task like turning the display off which was not there initially means that something is not quite right
<uvos>
yes and i told you whats not quite right
<uvos>
it waits on ipc in cases it dosent really have to
<freemangordon>
and I think it makes sense to try to fix that without having to reengineer the whole codebase from scratch
<freemangordon>
going async will brign other problems I would like to avoid
<uvos>
no it wont
<uvos>
i know lots of places where it would not
<freemangordon>
you need to syncronize at some point
<freemangordon>
*synchronize
<freemangordon>
otherwise you will never have deterministic behaviour. anyway, lets not go into that
<uvos>
there are places where this is really easy
<freemangordon>
if you don;t want to look at it, fine
<freemangordon>
I will
<uvos>
please dont, reording is not a good solution to the problem really
<freemangordon>
as I said - not reordering, but priorities
<uvos>
that is effectively reodring the callbacks
<uvos>
sure you can fake it being fast by turning off the backlight