| freemangordon | uvos: Care to share how you made that work and eventually do a PR? | 08:11 |
|---|---|---|
| freemangordon | because in leste d4 images (at least) there is no sound in FF | 08:11 |
| 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) | 10:55 |
| uvos | so its a very recent problem or confined to stable | 10:55 |
| Wizzup | freemangordon: ok I think I hit the display not turning on problem | 10:59 |
| Wizzup | what did you want me to do again? | 10:59 |
| Wizzup | wait it turned on now... | 10:59 |
| Wizzup | tmlind: uvos: so I'm having to offline/online my modem a lot to get my pending messages flushes out, weird | 11:04 |
| uvos | Wizzup: i havent used the modem in a while | 11:17 |
| uvos | Wizzup: so maybe this is a new issue | 11:17 |
| uvos | or i just dident notice, what are the symptoms? | 11:17 |
| uvos | are they not sent or sent more than once? | 11:18 |
| Wizzup | they are not sent and just in pending messages | 11:19 |
| uvos | hmm | 11:19 |
| Wizzup | I sent like a bunch with telepathy-ring and they weren't delivered for a day or two | 11:19 |
| uvos | that worked for sure realiably ~1 month ago when i was useing sms often | 11:19 |
| Wizzup | ok | 11:20 |
| uvos | i think i saw it double send a couple of times | 11:20 |
| uvos | or maybe sphone was buggy dunno | 11:20 |
| Wizzup | I mean if ofono misses a confirmation of sending (could be some kicks again) then that is possible | 11:23 |
| uvos | might be related to wether the carrier dose dlr | 11:26 |
| Wizzup | rigt | 12:34 |
| rafael2k | I did not see any sms problems | 13:26 |
| Wizzup | rafael2k: pinephone is different from d4 :) | 13:30 |
| uvos | freemangordon: so the mce power key issue is fixed, as far as possible | 13:59 |
| uvos | there are actually lots of issues, all of witch can be repoduced on fremantle | 13:59 |
| uvos | you just have to be a bit quicker, as mentioned | 13:59 |
| uvos | anyhow mce now uses kernel event times intstead of its own timers | 14:00 |
| uvos | this fixes single presses being reigsterd as long, doubles as singles etc due to mce stalling | 14:00 |
| 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 | 14:01 |
| uvos | however not all problems are fixable and the mce/systemui architecture of global state loosly synced between deamons is fundamentally flawed | 14:02 |
| freemangordon | uvos: great, thanks, will test as soon as I can | 14:02 |
| freemangordon | yeah, I know | 14:02 |
| uvos | single presses can still be registerd wrongly as long in extream circumstances | 14:02 |
| freemangordon | mhm | 14:02 |
| uvos | and mce will discard events now that straddle a mode change | 14:02 |
| uvos | so because it cant apply them correctly | 14:03 |
| uvos | this causes events to be missed sometimes | 14:03 |
| uvos | ie opening the power menu right after exiting tklock | 14:03 |
| uvos | may fail | 14:03 |
| uvos | theres nothing that can be done about this | 14:03 |
| freemangordon | that's not really I big issue | 14:03 |
| freemangordon | we can;t (or rather should not) queue events, IIUC | 14:03 |
| freemangordon | lemme upgrade and test | 14:04 |
| uvos | freemangordon: still building | 14:04 |
| freemangordon | ok | 14:04 |
| uvos | just finished | 14:04 |
| uvos | for amd64 | 14:04 |
| uvos | so wait a bit | 14:04 |
| freemangordon | yeah | 14:05 |
| freemangordon | hmm, neither hildon-status-menu nor hildon-home register new applets :( | 14:06 |
| Wizzup | freemangordon: if you pkill it works I guess? | 14:06 |
| freemangordon | maybe this has something to do with multi-arch | 14:06 |
| freemangordon | yeah, but it should not be needed | 14:06 |
| freemangordon | lemme check what's goign on | 14:06 |
| Wizzup | freemangordon: so I think I see X being stuck in drm ioctls again | 14:09 |
| Wizzup | what did you want me to check? | 14:09 |
| freemangordon | if all the fences are signalled | 14:10 |
| Wizzup | so /sys/kernel/debug/dma_buf | 14:10 |
| freemangordon | yes | 14:11 |
| Wizzup | hmm now it works again, but it took forever to unlock | 14:11 |
| Wizzup | and touchscreen still doesn't react | 14:11 |
| uvos | Wizzup: i think i see this in charge-mode | 14:11 |
| uvos | Wizzup: btw | 14:11 |
| uvos | Wizzup: if you run charge-mode for a long time | 14:11 |
| Wizzup | freemangordon: btw you mean /sys/kernel/debug/dma_buf/bufinfo right | 14:11 |
| uvos | Wizzup: since switching to drm it somtiems hangs | 14:11 |
| freemangordon | Wizzup: yes | 14:11 |
| freemangordon | maybe pastebin it | 14:11 |
| freemangordon | but not it works again, it makes no sense | 14:12 |
| freemangordon | *now | 14:12 |
| freemangordon | still, lets see | 14:12 |
| Wizzup | freemangordon: https://wizzup.org/bufinfo.txt | 14:12 |
| Wizzup | 1004 fds open btw | 14:13 |
| Wizzup | 965 of them are dmabuf | 14:13 |
| uvos | now that dose seam excessive | 14:13 |
| freemangordon | mhm | 14:14 |
| freemangordon | maybe it leaks | 14:14 |
| freemangordon | I will have a look at this | 14:14 |
| freemangordon | lemme first see why plugins are not being registered (should be trivial) | 14:15 |
| Wizzup | maybe the huge amount of bufs causes the slowness/problems | 14:16 |
| freemangordon | oh, I may look int https://github.com/maemo-leste/hildon-status-menu/pull/3while at it :) | 14:16 |
| freemangordon | Wizzup: sure | 14:17 |
| Wizzup | sounds good | 14:17 |
| Wizzup | uptime is ~2 days | 14:22 |
| Wizzup | it looks like one or two fd's are leaked every time I unlock the device maybe | 14:23 |
| Wizzup | will try to find some pattern | 14:23 |
| freemangordon | hmm: | 14:23 |
| freemangordon | /usr/lib/aarch64-linux-gnu/hildon-desktop/personal-ip-address.so | 14:23 |
| 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. | 14:24 |
| uvos | this is impossible to fix | 14:24 |
| uvos | as the timout is really long (1s) | 14:24 |
| uvos | so singlepress latecy is way to long if you wait and see if its a double press or not | 14:24 |
| Wizzup | we can change this in leste-config right? | 14:24 |
| uvos | sure but then you double press is hard | 14:24 |
| uvos | wich is also bad for a action that is really the most common thing you do with the button | 14:25 |
| uvos | (ie lock the device) | 14:25 |
| freemangordon | somehot this works fine on fremantle | 14:25 |
| uvos | nope | 14:25 |
| uvos | you can see i happen there too | 14:25 |
| uvos | *it | 14:25 |
| freemangordon | yes, I am using that hundreds of times every day | 14:25 |
| uvos | i can make it happen no problem | 14:25 |
| Wizzup | on boot: | 14:25 |
| Wizzup | $ sudo ls -lsh /proc/3385/fd | grep dmabuf | wc -l | 14:25 |
| Wizzup | 184 | 14:25 |
| freemangordon | my only phone is n900 with fremantle | 14:25 |
| Wizzup | on fremantle it also shows power menu first | 14:26 |
| Wizzup | and then locks | 14:26 |
| freemangordon | not here | 14:26 |
| uvos | if you doubless slowly | 14:26 |
| Wizzup | weird, does for me, maybe you're faster :) | 14:26 |
| uvos | otherwise n900 is just to slow | 14:26 |
| uvos | to show the menu | 14:26 |
| uvos | but it dose the action | 14:26 |
| freemangordon | yeah, if you double-press slowly | 14:26 |
| uvos | well thats just because n900 is to slow to show the menu quickly ;) | 14:26 |
| freemangordon | but you double=press normally, there is no power menu | 14:26 |
| Wizzup | no the menu shows for me almost always on fremantle | 14:26 |
| Wizzup | (I am slow I guess) | 14:26 |
| uvos | mce still raises the menu immidatly | 14:26 |
| uvos | if it pops up before the device locks is just a race | 14:27 |
| Wizzup | at any rate we can decide to change that in leste-config for some devices I think | 14:27 |
| Wizzup | freemangordon: so on the d4 I cannot lock it with double press without the menu showing at all | 14:27 |
| freemangordon | I don;t think we shall do that, we'd rather fix mce to not show power menu instantly | 14:27 |
| Wizzup | which I think is what he is saying | 14:27 |
| freemangordon | sure | 14:27 |
| uvos | freemangordon: its not possible | 14:27 |
| uvos | freemangordon: without lots of latceny | 14:27 |
| Wizzup | in any case I think we'll discuss somewhere else if single press should be lock or no | 14:27 |
| Wizzup | or not* | 14:27 |
| Wizzup | I think I would prefer single press to lock, and long press to show power menu | 14:28 |
| freemangordon | no, please | 14:28 |
| uvos | i also prefer this (on devices without lock slider) | 14:28 |
| freemangordon | lets keep defaults as in fremantle and make cpl applet to set this | 14:28 |
| Wizzup | we can also just make it a wiki entry, it's trivial to change anyway | 14:29 |
| freemangordon | well, having UI to change is user friendly, no? :) | 14:30 |
| Wizzup | yeah, I would like to port over this cssu thing | 14:31 |
| uvos | pls no | 14:32 |
| Wizzup | do you know what I mean? the one that allowed to change a whole bunch | 14:32 |
| uvos | lets not have random stuff change mce.ini | 14:32 |
| Wizzup | uvos: I am not sure if you know what I refer to :) | 14:32 |
| uvos | if you want to change this in ui you have to port the vars to rtconf | 14:32 |
| Wizzup | https://www.my-maemo.com/software/applications_name_CSSU_Transitions_Tuner_fldAuto_2133_faq_42.html stuff like this I think | 14:32 |
| freemangordon | Wizzup: I think we'd rather reimplement it, IIRC CSSU one was buggy as hell | 14:32 |
| uvos | Wizzup: well the only way to change it in mce atm is to change its config file | 14:32 |
| freemangordon | uvos: so? | 14:33 |
| uvos | Wizzup: we _dont_ want random stuff changing mces config file | 14:33 |
| uvos | Wizzup: it has rtconf for that | 14:33 |
| Wizzup | sure, but a ui can use rtconf :) | 14:36 |
| uvos | right but porting it i mean | 14:37 |
| uvos | with the pls no | 14:37 |
| uvos | since it dosent | 14:37 |
| Wizzup | uvos: is there also PowerKeyMediumAction ? | 14:38 |
| uvos | no | 14:38 |
| uvos | the medium time is used only in actdead | 14:38 |
| Wizzup | too bad | 14:39 |
| Wizzup | ok | 14:40 |
| Wizzup | freemangordon: it was this http://wiki.maemo.org/CSSU_Features_Configuration_Editor | 14:40 |
| freemangordon | yeah. And iirc it was buggy :) | 14:41 |
| freemangordon | se we'd better reimplement | 14:41 |
| freemangordon | but nit now ;) | 14:41 |
| freemangordon | *not | 14:41 |
| freemangordon | anyway, I am on applets not showing now | 14:42 |
| Wizzup | mhm | 14:46 |
| Wizzup | so you can't swap short and long without the long being useless if you set long to menu | 14:57 |
| Wizzup | err | 14:57 |
| Wizzup | sorry | 14:57 |
| Wizzup | not long, but short and double | 14:57 |
| uvos | ? | 14:58 |
| Wizzup | [PowerKey] | 14:58 |
| Wizzup | PowerKeyShortAction=tklock | 14:58 |
| Wizzup | PowerKeyDoubleAction=menu | 14:58 |
| Wizzup | I did this as a test | 14:58 |
| Wizzup | and I cannot get the menu to show | 14:58 |
| uvos | right | 14:58 |
| uvos | because short triggers | 14:58 |
| Wizzup | right | 14:58 |
| uvos | and then the deivice is locked | 14:58 |
| uvos | i use: | 14:59 |
| uvos | PowerKeyShortAction=tklock | 14:59 |
| uvos | PowerKeyLongAction=menu | 14:59 |
| uvos | PowerKeyDoubleAction=poweroff | 15:00 |
| uvos | and PowerKeyDoubleDelay=150 | 15:00 |
| Wizzup | right | 15:00 |
| Wizzup | I won't do that now as a test because that will mess me up badly wrt my muscle memory | 15:00 |
| uvos | and PowerKeyLongDelay=2000 | 15:00 |
| sicelo | freemangordon: what about personal-ip-address widget? | 15:07 |
| freemangordon | nothing about it in particular | 15:07 |
| freemangordon | it is that h-h ignores it after installation | 15:08 |
| freemangordon | there is a bug in libhildon1 | 15:08 |
| freemangordon | oops | 15:08 |
| sicelo | as for widget not appearing, see https://github.com/maemo-leste/bugtracker/issues/459 and https://github.com/maemo-leste/bugtracker/issues/368 | 15:08 |
| freemangordon | in libhildondesktop-1 | 15:08 |
| sicelo | https://bugs.maemo.org/show_bug.cgi?id=9370 ... i think it all comes from there | 15:08 |
| freemangordon | mhm | 15:08 |
| freemangordon | I am on it | 15:08 |
| sicelo | great :-) | 15:08 |
| freemangordon | will let you know when I fix that to test and eventually close the issue, ok? | 15:09 |
| freemangordon | *issues | 15:09 |
| sicelo | cool, thanks. indeed the bmo bug suggested libhildondesktop too | 15:09 |
| humpelstilzchen[ | Hi, anyone here has the hardware-keyboard working on pinephone? | 15:30 |
| humpelstilzchen[ | Anything special to conside? | 15:31 |
| humpelstilzchen[ | s/conside/consider/ | 15:31 |
| Wizzup | we have a kernel where it is supposed to work but we didn't push it to stable yet | 15:34 |
| humpelstilzchen[ | ok, do you have the kernel git/branch for me please? | 15:40 |
| Wizzup | you can add the beowulf-devel repo and apt dist-upgrade | 15:49 |
| Wizzup | find the line with 'deb https://maedevu.maemo.org/leste beowulf ...' in /etc/apt/sources.list | 15:50 |
| Wizzup | and copy it and change beowulf to beowulf-devel | 15:50 |
| Wizzup | (so you have both) | 15:50 |
| humpelstilzchen[ | aah, so its already build, thx | 15:55 |
| Wizzup | humpelstilzchen[: please let me know if it works for you | 16:07 |
| Wizzup | you can be the first to confirm that it works :) | 16:07 |
| humpelstilzchen[ | Wizzup: most keys seem to work, have not tested all the special fn-something combos yet | 16:09 |
| freemangordon | sicelo: hmm, I wonder if that has ever worked | 16:13 |
| freemangordon | (first h-h applet that is) | 16:13 |
| Wizzup | humpelstilzchen[: we will need to make a xkb map for it, if it doesn't exist already | 16:18 |
| Wizzup | humpelstilzchen[: including maps for our fn key and others | 16:18 |
| Wizzup | humpelstilzchen[: but that means the kernel side works for you, that's great! | 16:18 |
| freemangordon | oh, I see | 16:19 |
| Wizzup | humpelstilzchen[: see https://leste.maemo.org/Motorola_Droid_4#Notes and in particular https://leste.maemo.org/File:Maemo-leste-droid4-kbd-2021-07.png - and https://github.com/maemo-leste-upstream-forks/xkb-data/blob/master/symbols/motorola_vndr/droid4 | 16:21 |
| Wizzup | humpelstilzchen[: btw you should also get better 2d/3d on pp with that upgrade, we're working on moving that to stable to | 16:21 |
| Wizzup | s/to/too/ | 16:21 |
| humpelstilzchen[ | only updated the kernel so far, I still get artifacts, maybe I should try the new mesa packages then | 16:23 |
| Wizzup | try 'apt dist-upgrade' | 16:23 |
| Wizzup | there will be -some- artifacts still, but should be less | 16:23 |
| humpelstilzchen[ | hmm, dist-upgrade wants to remove hildon-desktop-rotation-support, something seems to collide | 16:25 |
| Wizzup | humpelstilzchen[: that is fine if it wants to remove that | 16:25 |
| Wizzup | freemangordon: you tested this one right? https://maedevu.maemo.org/images-devel/pinephone/20220119/ (maybe compare md5sum?) | 16:25 |
| freemangordon | lemme check | 16:26 |
| humpelstilzchen[ | ok | 16:26 |
| Wizzup | freemangordon: I was going to poke enunes :) | 16:26 |
| freemangordon | Wizzup: 6f5027e1c8483342483db4a206ade1d3 maemo-leste-1.0-arm64-pinephone-20220119.img.xz | 16:26 |
| Wizzup | humpelstilzchen[: yeah the support will still be there | 16:26 |
| Wizzup | freemangordon: $ md5sum maemo-leste-1.0-arm64-pinephone-20220119.img.xz | 16:27 |
| Wizzup | 6f5027e1c8483342483db4a206ade1d3 maemo-leste-1.0-arm64-pinephone-20220119.img.xz | 16:27 |
| Wizzup | freemangordon: so looks like I can poke enunes | 16:27 |
| freemangordon | mhm | 16:27 |
| humpelstilzchen[ | on upgrade: Call to flock failed: Resource temporarily unavailable - invoke-rc.d: initscript hildon-desktop, action "restart" failed | 16:30 |
| humpelstilzchen[ | gonne uncomment that part in postinst and do a manual reboot | 16:30 |
| Wizzup | humpelstilzchen[: full disk? | 16:31 |
| Wizzup | humpelstilzchen[: run /etc/expandcard.sh | 16:31 |
| Wizzup | humpelstilzchen[: probably don't need to uncomment it in postinst, better to finish the upgrade first | 16:32 |
| humpelstilzchen[ | not full according to df | 16:32 |
| Wizzup | ok | 16:32 |
| Wizzup | did the upgrade complete otherwise? | 16:32 |
| Wizzup | (also yeah hildon-desktop restart should be a no-op fwiw) | 16:32 |
| humpelstilzchen[ | now its completed | 16:32 |
| Wizzup | (reboot is a good idea fwiw) | 16:34 |
| tmlind | hmm the images directories for the 16th are empty? | 16:35 |
| tmlind | https://maedevu.maemo.org/images/droid4/20220116/ | 16:35 |
| Wizzup | let me check, maybe somethin failed | 16:39 |
| Wizzup | let me just rerun em | 16:39 |
| Wizzup | tmlind: yeah | 16:40 |
| 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) | 16:40 |
| Wizzup | we really should just host it somewhere else | 16:41 |
| tmlind | ok | 16:42 |
| Wizzup | in 1-2 hours there will be a new one | 16:43 |
| Wizzup | but we didn't change anything in stable so you can just take the previous one and upgrade to -devel | 16:43 |
| humpelstilzchen[ | cool now I have a welcome screen with ssh credentials - that might help a lot for future users :) | 16:43 |
| Wizzup | humpelstilzchen[: yeah, it is :) | 16:43 |
| Wizzup | uvos: ^^ :) | 16:43 |
| tmlind | Wizzup: ok thanks i'll try again a bit later then | 16:50 |
| 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 ;) | 17:02 |
| freemangordon | and this is what is broken :) | 17:02 |
| freemangordon | well, *was* broken | 17:03 |
| 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 | 17:10 |
| freemangordon | but I guess we can live with that | 17:10 |
| lel | freemangordon closed an issue: https://github.com/maemo-leste/bugtracker/issues/459 (hildon-home doesn't show the "Add widget" button upon installation of the first widget) | 17:26 |
| 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 | 17:51 |
| 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 | 18:01 |
| Wizzup | ok | 18:05 |
| Wizzup | which programs are you missing? | 18:05 |
| 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? | 18:15 |
| humpelstilzchen[ | And is there a recommended browser? | 18:16 |
| uvos | qtwebbrowser works well ootb, or firefox works very well but needs hwkbd and some envvars about:config entrys | 18:17 |
| uvos | calendar widget exits and works fine bte | 18:19 |
| uvos | no weather | 18:19 |
| uvos | freemangordon: so did the mce race fix solve your issues? | 20:01 |
| freemangordon | uvos: at least on PP it looks to behave fine | 20:39 |
| freemangordon | have guests so didn't have time to play on d4 | 20:40 |
| freemangordon | will report as soon as I test it | 20:40 |
| freemangordon | uvos: RE firefox - do we have those settings documented somewhere? | 20:41 |
| freemangordon | uvos: why it takes so long for mce to lock screen on d4? on PP it happens in an instant. | 21:14 |
| lel | freemangordon closed an issue: https://github.com/maemo-leste/bugtracker/issues/368 (hildon-desktop - needs a restart to pickup new desktop widgets) | 21:15 |
| 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 :-) | 21:34 |
| freemangordon | sicelo: this it how it was designed to be. and honestly, it kind of makes sense | 21:35 |
| freemangordon | imagine if you are not familiar with maemo | 21:35 |
| freemangordon | you would expect to see what you have just installed somewhere | 21:35 |
| sicelo | right, :-) | 21:36 |
| 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 | 21:36 |
| freemangordon | uvos: can;t we reorder? | 21:37 |
| freemangordon | as it takes nearly 2 seconds | 21:37 |
| uvos | no | 21:37 |
| uvos | reording is an ordeal if you want tklock to work | 21:37 |
| uvos | otherwise yeah my setup is reorderd for performance | 21:37 |
| freemangordon | we cannot turn display off first? why is that? | 21:37 |
| uvos | and its very fast | 21:37 |
| uvos | because its determined by the module loading order | 21:37 |
| freemangordon | uvos: sorry, I don;t get that | 21:38 |
| uvos | the module loading order is however also subject to lots of subtle bugs | 21:38 |
| uvos | in the old modules | 21:38 |
| uvos | so mce uses data pipes | 21:38 |
| freemangordon | so, "turn off" callbacks are called in module load order? | 21:38 |
| uvos | yes | 21:38 |
| uvos | so every module registers its callbacks | 21:38 |
| uvos | and they are called in the order they are registerd | 21:38 |
| uvos | most callbacks are regsiterd at load time ofc | 21:39 |
| uvos | changing the order breaks the legacy/fremantle modules | 21:39 |
| uvos | because they use global state | 21:39 |
| uvos | so the callbacks that modify global state break later callbacks | 21:39 |
| freemangordon | well, we can implement priority, no? | 21:39 |
| uvos | you could but you would have to untange a huge mess | 21:40 |
| freemangordon | or, have a separate module for turning the display off that's loaded first | 21:40 |
| uvos | a better way is to reimplement the mess | 21:40 |
| uvos | (wich i have done for myself) | 21:40 |
| uvos | and make stuff async | 21:40 |
| uvos | lots of stuf could be async | 21:40 |
| freemangordon | uvos: no matter what, the same legacy module on fremantle turns display off on an instant | 21:40 |
| freemangordon | *modules | 21:40 |
| uvos | freemangordon: sure they dident run into the issues as mutch, mce as just a lot more to do on d4 | 21:41 |
| uvos | also the problem is that its dose just ipc | 21:41 |
| uvos | and the ipc its doing is stalling it wating for other processies | 21:41 |
| freemangordon | well, no matter the reason, this is not really user friendly | 21:41 |
| freemangordon | I know you don;t use double-press, but that's no reason to not implement it right | 21:42 |
| uvos | wdym | 21:42 |
| uvos | i fixed double press | 21:42 |
| uvos | otherwise make stuff async | 21:42 |
| freemangordon | sorry, was it broken? | 21:42 |
| uvos | yes it was | 21:42 |
| uvos | (also on fremantle) | 21:42 |
| uvos | anyhow make mce more async so it dosent wait for other processies all the time | 21:43 |
| uvos | is the fix | 21:43 |
| uvos | ofc thats lots of work | 21:43 |
| uvos | also figure out why dpms is so damn sloww | 21:43 |
| uvos | thats just a ddx thing | 21:43 |
| freemangordon | I don;t know what you mean by "broken", but on fremantle double-press locks the device instantly | 21:43 |
| freemangordon | on d4 it takes 2 seconds | 21:43 |
| freemangordon | yeah, dpms | 21:43 |
| freemangordon | we may have kernel issue there | 21:44 |
| freemangordon | I think it is related with vblank patch | 21:44 |
| freemangordon | I will do some experimenting with that reverted | 21:44 |
| 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 | 21:45 |
| uvos | yes | 21:45 |
| uvos | this is the design of mce | 21:45 |
| uvos | it dose suff in serial and order cant be controlled | 21:45 |
| freemangordon | we shall implement some control then | 21:45 |
| freemangordon | as I said - priority | 21:46 |
| freemangordon | no need to do it asunc | 21:46 |
| freemangordon | *async | 21:46 |
| uvos | async is mutch better | 21:46 |
| uvos | really | 21:46 |
| uvos | and there are easy wins here | 21:46 |
| freemangordon | as I can imagine this will be a huge task | 21:46 |
| uvos | no | 21:46 |
| uvos | there are some self contained easy wins here | 21:47 |
| uvos | priority ordering is a huge task | 21:47 |
| freemangordon | uvos: the easiest way is with priorities | 21:47 |
| uvos | to make it not mess with the global state problem | 21:47 |
| uvos | no | 21:47 |
| uvos | its gona be pretty insane | 21:47 |
| uvos | trust me | 21:47 |
| freemangordon | see, it is not that I didn;t work on mce code | 21:47 |
| uvos | at this point i have rewritten all modules | 21:48 |
| freemangordon | it is just that it was some time ago | 21:48 |
| uvos | (that i use) | 21:48 |
| 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 | 21:49 |
| uvos | yes and i told you whats not quite right | 21:49 |
| uvos | it waits on ipc in cases it dosent really have to | 21:49 |
| freemangordon | and I think it makes sense to try to fix that without having to reengineer the whole codebase from scratch | 21:49 |
| freemangordon | going async will brign other problems I would like to avoid | 21:50 |
| uvos | no it wont | 21:50 |
| uvos | i know lots of places where it would not | 21:50 |
| freemangordon | you need to syncronize at some point | 21:50 |
| freemangordon | *synchronize | 21:51 |
| freemangordon | otherwise you will never have deterministic behaviour. anyway, lets not go into that | 21:51 |
| uvos | there are places where this is really easy | 21:51 |
| freemangordon | if you don;t want to look at it, fine | 21:51 |
| freemangordon | I will | 21:52 |
| uvos | please dont, reording is not a good solution to the problem really | 21:52 |
| freemangordon | as I said - not reordering, but priorities | 21:53 |
| uvos | that is effectively reodring the callbacks | 21:53 |
| uvos | sure you can fake it being fast by turning off the backlight | 21:53 |
| uvos | but it will still be dreadfully slow | 21:53 |
| freemangordon | which will be enigh | 21:53 |
| uvos | making it annoying to the user | 21:53 |
| freemangordon | *enougj | 21:53 |
| uvos | no | 21:53 |
| uvos | not really | 21:53 |
| freemangordon | why? | 21:53 |
| freemangordon | 1. Turn backlight off, 2. disable TS | 21:54 |
| uvos | you cant fake it tunring on, thats really slow to, tunring it off and on again (wich happens by accident often) will be really slow | 21:54 |
| freemangordon | those are enough for te user to see that somethiong actually happens | 21:54 |
| uvos | and mce will discard power buttion presses in the mean time etc | 21:54 |
| uvos | the state changes around dim mode will be terrible | 21:54 |
| freemangordon | because now you double-press, but nothing happens | 21:54 |
| uvos | (as they are now) | 21:54 |
| uvos | its just not a good solution | 21:54 |
| freemangordon | dim? | 21:54 |
| uvos | dim mode | 21:54 |
| freemangordon | why dim, you wont lock | 21:54 |
| freemangordon | *want | 21:55 |
| uvos | no | 21:55 |
| uvos | so if the device dims | 21:55 |
| freemangordon | yes, you want lock on double-press | 21:55 |
| uvos | it takes forever form mce to undim | 21:55 |
| uvos | this isent about that | 21:55 |
| uvos | im talking about problems reodring the callbacks dosent solve | 21:55 |
| freemangordon | ah, yeah, why it takes ages to dim? do we do SW dim? | 21:55 |
| uvos | hmm ages to dim? | 21:56 |
| uvos | it takes ages for mce to realise its goten an event | 21:56 |
| freemangordon | well, undimming | 21:56 |
| uvos | and then undim | 21:56 |
| freemangordon | ah | 21:56 |
| freemangordon | why is that? | 21:56 |
| uvos | it waits for xinput | 21:56 |
| uvos | is the main problem i think | 21:56 |
| uvos | but haven profiled that | 21:56 |
| freemangordon | hmm | 21:56 |
| uvos | and yes we use sw to drive the backlight fade | 21:57 |
| uvos | (as did fremantle) | 21:57 |
| freemangordon | does not makes sense, as h-d registers touches instantly | 21:57 |
| uvos | right so dose mce | 21:57 |
| uvos | but | 21:57 |
| uvos | there are several problems here | 21:57 |
| freemangordon | and why it needs 2 seconds to realize it has to undim? | 21:57 |
| uvos | it dosent | 21:57 |
| freemangordon | here it does | 21:57 |
| uvos | it needs a long time to undim | 21:57 |
| freemangordon | yeah, why? | 21:57 |
| uvos | (it also has a 1 sec timeout that migght be in the way) | 21:58 |
| uvos | again xinput | 21:58 |
| uvos | it reanbles xes input devices | 21:58 |
| uvos | so for ts events | 21:58 |
| uvos | it also works like this | 21:58 |
| freemangordon | those are disabled on dim? | 21:58 |
| uvos | yes for one click mode | 21:58 |
| freemangordon | wait | 21:58 |
| freemangordon | there is event eater in tklock for that | 21:58 |
| freemangordon | there is absolutely no need to disable anything at that point | 21:59 |
| uvos | right but mce implements this again (allways has, on fremantle it disables the devices in kernel) | 21:59 |
| uvos | tklock is totaly redundant | 21:59 |
| freemangordon | no | 21:59 |
| freemangordon | no | 21:59 |
| uvos | yes | 21:59 |
| uvos | yes | 21:59 |
| uvos | anyhow back to ts events | 21:59 |
| freemangordon | no, you are doing broken redesign here | 21:59 |
| uvos | theres another problem | 21:59 |
| uvos | no | 21:59 |
| freemangordon | yes, listen: | 21:59 |
| uvos | anyhow back to ts events: it works like this | 22:00 |
| uvos | it listens for ts events | 22:00 |
| uvos | when it gets one | 22:00 |
| freemangordon | on dim, screen is dimmed and event eater in tklock is armed | 22:00 |
| uvos | i know | 22:00 |
| freemangordon | it "eats" the first input event (no matter TS or another) | 22:00 |
| uvos | i know | 22:00 |
| freemangordon | and then you just undim | 22:00 |
| uvos | i also know | 22:00 |
| freemangordon | no need to disable anytthing | 22:00 |
| uvos | right but mce disables other input devces in this mode | 22:01 |
| uvos | in kernel on fremantle | 22:01 |
| freemangordon | your private no-tklock use-case is not reason for mce to disable anything | 22:01 |
| uvos | i dident add this | 22:01 |
| freemangordon | please show me the code | 22:01 |
| freemangordon | in 'stock' mce | 22:01 |
| uvos | back to mce input: so when it gets a ts event there is a 1 sec timeout where it ignores ts events | 22:02 |
| uvos | so sometimes when it enters dim mode | 22:02 |
| freemangordon | mce? | 22:02 |
| uvos | yes | 22:02 |
| uvos | i cant switch out for 1 second no mater what | 22:02 |
| freemangordon | there is no such timeout in fremantle mce | 22:02 |
| uvos | this again was implemented in fremantle | 22:02 |
| uvos | yes there is | 22:02 |
| freemangordon | and that's for sure | 22:02 |
| uvos | yes there is | 22:02 |
| uvos | and they added this | 22:02 |
| * freemangordon tries | 22:02 | |
| uvos | because otherwise mce uses huge amount of cpu time | 22:02 |
| uvos | because of the event rate of the ts | 22:03 |
| uvos | also ofc this is only happens if you touch right before it enter the mode | 22:03 |
| uvos | so its not that relevant | 22:03 |
| uvos | i was just mentioning this bug/race that exists that can extend the time by 1 sec sometimes | 22:03 |
| freemangordon | on d4 it is way worse | 22:03 |
| freemangordon | and just tried on fremantle: | 22:04 |
| freemangordon | dimmig happesn in .5s or something | 22:04 |
| freemangordon | and I clicked immediately after the dim | 22:04 |
| freemangordon | instant undim | 22:04 |
| freemangordon | did that several times | 22:04 |
| freemangordon | consistent behaviour | 22:05 |
| uvos | idk how easy this race is to trigger in real life | 22:05 |
| freemangordon | do you want me to capture a video? | 22:05 |
| uvos | i just know it exists in the code | 22:05 |
| uvos | no | 22:05 |
| uvos | i know its slow | 22:05 |
| freemangordon | on fremantle? | 22:05 |
| uvos | yes | 22:05 |
| freemangordon | it is not | 22:05 |
| uvos | on d4 i mean | 22:05 |
| freemangordon | it happens in an instant | 22:06 |
| freemangordon | ah | 22:06 |
| uvos | yes | 22:06 |
| freemangordon | yeah, on d4 it is slow | 22:06 |
| freemangordon | but, it is not on PP | 22:06 |
| freemangordon | and I think it is not on n900 | 22:06 |
| uvos | right d4 mce dose quite a bit more stuff | 22:06 |
| freemangordon | right | 22:06 |
| uvos | im sure | 22:06 |
| uvos | if you go and unload lots of modules it will be fine | 22:07 |
| freemangordon | and that is what I am saying - this "other' stuff shall be done after the prymary stuff | 22:07 |
| freemangordon | *primary | 22:07 |
| uvos | not possible/ usefull in many cases | 22:07 |
| freemangordon | also, why do you need to do anything on dim? | 22:07 |
| uvos | i have not profiled this | 22:07 |
| uvos | so i dont know | 22:07 |
| uvos | its not that mutch really | 22:07 |
| freemangordon | uvos: right, maybe we shall see what happens there | 22:07 |
| freemangordon | no, it is really ~ 2 seconds | 22:08 |
| freemangordon | which it too much | 22:08 |
| freemangordon | half a second would be acceptable | 22:08 |
| freemangordon | 2 seconds is not | 22:08 |
| freemangordon | thats really a broken UX | 22:08 |
| uvos | its like 0.5s here | 22:08 |
| uvos | but yeah i use different modules | 22:08 |
| freemangordon | but yeah, we need to profile | 22:08 |
| freemangordon | uvos: :nod: | 22:09 |
| freemangordon | I guess this makes all the difference | 22:09 |
| freemangordon | I use stock setup | 22:09 |
| freemangordon | and yes, as Wizzup said, on d4 power menu always pops on double-press | 22:09 |
| freemangordon | not on PP | 22:09 |
| uvos | this is just a race | 22:10 |
| uvos | that exists on all devices | 22:10 |
| uvos | if dpms is slow | 22:10 |
| uvos | it will show | 22:10 |
| freemangordon | mhm | 22:10 |
| uvos | ie if the device is slow to turn off the display | 22:10 |
| uvos | it will show | 22:10 |
| freemangordon | agree | 22:10 |
| uvos | its also a race with your finger | 22:10 |
| uvos | since doublepres is 1 sec | 22:10 |
| uvos | so you can press 1 sec press | 22:10 |
| uvos | that will make it happen on any device | 22:10 |
| freemangordon | see, I know how this works :) | 22:10 |
| freemangordon | and I know it is wacy | 22:11 |
| freemangordon | *racy | 22:11 |
| uvos | right an i think is pretty terrible | 22:11 |
| uvos | honeslty i would scrap doublpress for this reason | 22:11 |
| uvos | since it cant be fixed | 22:11 |
| uvos | and its janky | 22:11 |
| freemangordon | but, this shows only on d4 | 22:11 |
| uvos | no it dosent | 22:11 |
| uvos | i shows only on d4 if you doublepres really fast | 22:11 |
| uvos | it happens on fremantle n900 for me to 100% of the time | 22:12 |
| freemangordon | uvos: only on d4 it takes 2seconds to power-off the screen | 22:12 |
| uvos | i gues my finger isent as fast | 22:12 |
| freemangordon | it is not about power menu showing | 22:12 |
| freemangordon | it is about taking 2 seconds to turn the display off | 22:12 |
| freemangordon | on PP and on fremantle the instant right after second press the display is off | 22:13 |
| uvos | btw double press to off is the slowes method possible | 22:13 |
| uvos | since it | 22:13 |
| freemangordon | on d4 it takes 2 seconds after the second press to turn the display off | 22:13 |
| uvos | https://github.com/maemo-leste/mce/blob/b69ca6df857fce86051182943ade97de95493576/src/utils/powerkey.c#L514 | 22:13 |
| freemangordon | this is what I am talking about | 22:14 |
| uvos | ie it waits for mce to idle | 22:14 |
| uvos | i had to do that | 22:14 |
| uvos | for the global state to be correct | 22:14 |
| uvos | when it enters lock | 22:14 |
| uvos | otherwise the powermenu mode breaks tklock | 22:14 |
| freemangordon | ok, have to see how it is done on fremant;e | 22:15 |
| uvos | its perfomed in a timer | 22:15 |
| freemangordon | uvos: also, for sure double-press is registered correctly | 22:15 |
| freemangordon | because what happens is: | 22:16 |
| freemangordon | on the first press, power menu gets shown | 22:16 |
| freemangordon | on the second press it gets hidden | 22:16 |
| freemangordon | then you wait 2 seconds | 22:16 |
| freemangordon | and display turns off | 22:16 |
| uvos | not really | 22:16 |
| freemangordon | do you want me to take a video? | 22:17 |
| uvos | yes i know what happens | 22:17 |
| uvos | so no | 22:17 |
| uvos | but your desciption is wrong | 22:17 |
| uvos | the second press dosent hid the menu | 22:17 |
| freemangordon | no, it is not | 22:17 |
| uvos | the mode change dose | 22:17 |
| freemangordon | this is what happens here from the user POV | 22:17 |
| uvos | the mode change closes the window, this happens to happen way before dpms compleats | 22:18 |
| freemangordon | what do you mean "mode change"? | 22:18 |
| freemangordon | mode change to "tklock" I guess | 22:18 |
| uvos | global mode | 22:18 |
| freemangordon | but, this mode change happens because of the second press, no? | 22:18 |
| uvos | maybe | 22:18 |
| uvos | depends on what you have there | 22:18 |
| uvos | also depends on global state | 22:18 |
| freemangordon | nothing else but the second press can make power menu be hidden | 22:19 |
| freemangordon | so, it gets registered correctly | 22:19 |
| freemangordon | and then it takes 2 seconds here for display being turned off | 22:20 |
| freemangordon | uvos: sec, have to answer to enunes | 22:20 |
| Wizzup | freemangordon: fwiw I believe the answer to his question is that it doesn't | 22:20 |
| Wizzup | checking | 22:20 |
| freemangordon | yes, it doesn;t | 22:21 |
| Wizzup | ok | 22:21 |
| freemangordon | but I have to register to answer :) | 22:21 |
| Wizzup | I'll let you answer | 22:21 |
| Wizzup | check | 22:21 |
| Wizzup | maybe also point him at being able to use apt get source or just link to the repo https://github.com/maemo-leste-upstream-forks/clutter-0.8 | 22:21 |
| freemangordon | ugh, I don;t remember the password, will reconnect | 22:23 |
| uvos | freemangordon: btw go into 70-droid4.init and remvoe quirks-mapphone | 22:37 |
| uvos | makes a large difference | 22:37 |
| uvos | suggesting that indeed about 0.3s or so is wating for the modem | 22:37 |
| uvos | thats not really mutch of a problem | 22:38 |
| uvos | we can async that | 22:38 |
| uvos | it dosent need to be synced with anything | 22:38 |
| freemangordon | uvos: ok, will do, but not now as we are in some discussion on #lima re PP | 22:38 |
| uvos | iio-accelerometer;iio-als;;iio-proximity makes a difference | 22:38 |
| uvos | not very supprising | 22:38 |
| uvos | thats up to 3 dbus round trips | 22:38 |
| uvos | to unbind the sensors | 22:38 |
| uvos | again this is device specific module | 22:39 |
| uvos | also easy to async | 22:39 |
| freemangordon | uvos: and I guess those can be disabled after screen is turned off | 22:40 |
| uvos | no dosent reall matter when the sensors are unbound realtive to other stuff | 22:40 |
| uvos | async is better | 22:40 |
| freemangordon | ok, but you'll have to implement some kind of semaphore there | 22:43 |
| uvos | sure dbus makes this easy | 22:43 |
| uvos | use the async calls | 22:44 |
| freemangordon | and I am afraid this will make it even more complicated and error prone | 22:44 |
| uvos | if you end up having to rebind the sensors beofre it returns | 22:44 |
| uvos | just block then | 22:44 |
| uvos | not really | 22:44 |
| freemangordon | ok | 22:44 |
| freemangordon | I still think there should be an easier way to fix that | 22:45 |
| uvos | not really dbus round trips have bad latency | 22:45 |
| uvos | thats just how it is | 22:45 |
| uvos | also modem is slow | 22:45 |
| uvos | thats also unfixable | 22:45 |
| freemangordon | yeah | 22:45 |
| freemangordon | btw, why do we touch modem on lock? | 22:46 |
| uvos | we have to stop its rssi reporting | 22:46 |
| uvos | otherwise it wont sleep | 22:46 |
| freemangordon | ah, wait, you are talking about dbus because we are using iio-senors? | 22:46 |
| uvos | yesh | 22:46 |
| freemangordon | ahaaa | 22:46 |
| uvos | we have to takl to ii-sensors over dbus | 22:46 |
| freemangordon | I see now what do you mean by async | 22:47 |
| uvos | to tell it we dont need trhe sensors | 22:47 |
| freemangordon | well, yeah, thats fine | 22:47 |
| freemangordon | async dbus calls is just right | 22:47 |
| freemangordon | as soon as you keep the local state consistent | 22:47 |
| freemangordon | yeah, right. we have a deal on that :) | 22:47 |
| freemangordon | sure you can issue async dbus call and queue enabling if it needs to be enalbed before you have disable call result | 22:48 |
| uvos | yes exactl | 22:49 |
| uvos | y | 22:49 |
| freemangordon | correct | 22:49 |
| uvos | there are lots of place like that in mce | 22:49 |
| uvos | *places | 22:49 |
| freemangordon | it took me a while until I understand what do you mean by "async" :) | 22:49 |
| freemangordon | but yes, I agree this will help a lot | 22:49 |
| freemangordon | do you want me to help with the implementation? | 22:50 |
| uvos | if you like | 22:50 |
| uvos | but its not mutch work really | 22:50 |
| uvos | https://github.com/maemo-leste/mce/blob/b69ca6df857fce86051182943ade97de95493576/src/modules/quirks-mapphone.c#L42 | 22:50 |
| uvos | this code block is slow | 22:50 |
| uvos | open() is slow here | 22:50 |
| uvos | and so is the write | 22:50 |
| freemangordon | hmm, but why do you use open() etc? IIRC mce wa using gio for async file operations | 22:51 |
| freemangordon | GIOChannel etc | 22:51 |
| uvos | sometimes yeah | 22:52 |
| uvos | it also uses open etc often | 22:52 |
| freemangordon | I guess I can rewrite this to use giochannel | 22:52 |
| uvos | this module is also kinda throwaway since its a collection of hacks really | 22:52 |
| uvos | you have to close the fd btw | 22:52 |
| uvos | otherwise modem dosent sleep | 22:52 |
| uvos | so i dont se how gio can do better | 22:53 |
| uvos | wrt open | 22:53 |
| freemangordon | because we can open async | 22:53 |
| freemangordon | and write on it being opened | 22:53 |
| uvos | sure ok | 22:53 |
| freemangordon | no need to block in display_state_trigger | 22:54 |
| freemangordon | and we can always cancel pending async calls | 22:54 |
| freemangordon | uvos: ok, so I'll take on that one | 22:54 |
| freemangordon | please have a look at iio modules, ok? | 22:55 |
| uvos | sure | 22:55 |
| uvos | the other thing tahts slow is dpms | 22:56 |
| uvos | and on enable tklock | 22:56 |
| uvos | xset dpms force on and off takes about a second by itself here | 22:56 |
| uvos | so thats half the problem right there already | 22:56 |
| freemangordon | right | 22:56 |
| freemangordon | but lets first pick the low-hanging fruits | 22:57 |
| freemangordon | ok, going to have some sleep, night! | 23:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
