Wizzup | fwiw rafael said he'll be back on monday | 00:00 |
---|---|---|
uvos | Wizzup: how do you make g_debug() messages show up | 00:18 |
uvos | Wizzup: i forget this every time | 00:18 |
Wizzup | G_MESSAGES_DEBUG=all I think | 00:18 |
uvos | dosent appear to work for hildon-status-menu | 00:18 |
Wizzup | we should add it to https://leste.maemo.org/Debugging | 00:18 |
Wizzup | uvos: that is because it detaches I think | 00:18 |
Wizzup | do you run it with maemo-summoner? | 00:18 |
uvos | no | 00:18 |
Wizzup | how do you run it? | 00:19 |
uvos | hildon-status-menu | 00:19 |
uvos | :P | 00:19 |
Wizzup | try envvarshere maemo-summoner /usr/bin/hildon-status-menu.launch | 00:19 |
uvos | envvarshere? | 00:20 |
Wizzup | G_MESSAGES_DEBUG=all maemo-summoner /usr/bin/hildon-status-menu.launch | 00:21 |
uvos | maemo-summoner /usr/bin/hildon-status-menu.launch dosent result in any difference in behavior | 00:21 |
uvos | no change | 00:21 |
Wizzup | is it maemo-invoker then? | 00:21 |
Wizzup | I always forget | 00:21 |
Wizzup | let me try on my d4 | 00:21 |
uvos | invoker stars it without maemo-launcher | 00:22 |
uvos | and summoner just calls dbus | 00:22 |
uvos | iirc | 00:22 |
uvos | not sure what you want | 00:22 |
Wizzup | I think summoner should be right one, but in this case I also do not see any messages | 00:22 |
Wizzup | maybe there is something more special about hildon-status-menu | 00:22 |
uvos | i had this working before | 00:22 |
uvos | with h-s-m | 00:22 |
Wizzup | maybe it has a custon env var? | 00:23 |
Wizzup | it uses osso logging | 00:23 |
uvos | yeah | 00:23 |
uvos | thats it | 00:23 |
uvos | i think it had some arcane var | 00:23 |
Wizzup | still I can recommend maemo-summoner | 00:23 |
Wizzup | this also work with gdb | 00:23 |
uvos | yea sure i know | 00:24 |
uvos | if (getenv ("DEBUG_OUTPUT") == NULL) | 00:25 |
uvos | closes all the stdio fds | 00:25 |
uvos | on that condition | 00:26 |
uvos | this is sillyness we should probubly just remove | 00:26 |
Wizzup | uvos: agreed @ remove | 00:29 |
uvos | it still also reacts to G_MESSAGES_DEBUG levels | 00:29 |
uvos | so i dont get at all why they added this | 00:30 |
Wizzup | freemangordon: upgraded to new kernel but don't have wifi (?) | 01:18 |
Wizzup | looks like some oops | 01:19 |
Wizzup | seems like a race | 01:21 |
Wizzup | https://dpaste.com/33RHBF3DK | 01:22 |
Wizzup | freemangordon: yeah reboot made it go away | 01:37 |
Wizzup | freemangordon: really this is so nice, really smooth 3d, 2d, stable (it seems) | 01:39 |
mighty17[m] | `[ 43.466] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (Error loading shared library /usr/lib/xorg/modules/dri/swrast_dri.so: No such file or directory)` there is swrast.so, should i just rename it? | 08:13 |
* mighty17[m] hasnt set MESA_LOADER_DRIVER_OVERRIDE=pvr for xorg | 08:14 | |
freemangordon | hmm, ants are still there, but besides that and tearing I think we have a pretty descent GPU stack now | 09:02 |
freemangordon | tmlind: ping | 09:02 |
freemangordon | Wizzup: I guess you don't mind if I move sgx-ddk-um to autotools? | 11:32 |
mighty17[m] | <mighty17[m]> "hasnt set MESA_LOADER_DRIVER_OVE..." <- That didn't work as well | 12:21 |
mighty17[m] | swrast_dri.so is necessary? | 12:21 |
uvos | aiglx is never going to work on pvr | 12:27 |
uvos | aiglx: acellerated indirect opengl for x | 12:28 |
uvos | 1. indirect rendering is disabled by default in x since 2016 or so | 12:28 |
uvos | 2. omap4 dosent support opengl | 12:28 |
uvos | 3. aiglx supports opengl up to version 1.2 only | 12:29 |
uvos | 4. no one uses opengl 1.2 | 12:29 |
Wizzup | freemangordon: don't mind | 12:30 |
uvos | 5. except for special niche uses (like me remote rendering cnc program tracebacks over the network) aiglx is useless | 12:30 |
mighty17[m] | aiglx is related to my issue? :O | 12:34 |
uvos | aiglx is trying to load swrast_dri | 12:35 |
uvos | this is red herring | 12:35 |
mighty17[m] | Ah, I wonder why it's used in lxqt then | 12:35 |
uvos | its not used | 12:35 |
uvos | its just loaded | 12:35 |
uvos | its totaly unrealted to any problems you might have | 12:35 |
uvos | aiglx is _never_ used | 12:36 |
mighty17[m] | Imma send full log then | 12:36 |
uvos | unless you enable it explicitly in like 3 places | 12:36 |
mighty17[m] | https://paste.debian.net/1226456/ | 12:36 |
mighty17[m] | uvos: That's unlikely | 12:36 |
uvos | your using mdoesetting | 12:38 |
uvos | that cant be acellerated on pvr | 12:39 |
mighty17[m] | The one fmg sent :D | 12:39 |
uvos | for xorgs own rendering | 12:39 |
uvos | no | 12:39 |
uvos | that one also dosent work | 12:39 |
uvos | it might do acceleration for 3d clients in dri3 mode, but dri2 mode was broken last time i tried | 12:39 |
uvos | it | 12:40 |
uvos | just use omap-ddx | 12:40 |
uvos | also 2d rendering is broken in dri3 mode | 12:40 |
mighty17[m] | I can't seem to build it :/ | 12:40 |
uvos | aka it dosent work | 12:40 |
uvos | just gennerally | 12:40 |
mighty17[m] | This is a mess xD | 12:40 |
mighty17[m] | I should just work on getting omap-ddx working | 12:40 |
mighty17[m] | uvos: Maybe that's why xfce worked and lxqt didn't | 12:41 |
uvos | no | 12:41 |
uvos | lxqt uses openbox as wm | 12:41 |
uvos | it dosent need any 3d at all | 12:41 |
mighty17[m] | Then why did it fail here, coz modesetting? | 12:42 |
uvos | no | 12:42 |
uvos | it fails because you have another issue on your end unrelated to 3d/xorg | 12:42 |
mighty17[m] | Hm?? | 12:43 |
* mighty17[m] didnt know this existed https://pkgs.alpinelinux.org/package/edge/community/armv7/xf86-video-omap | 13:03 | |
uvos | wont work | 13:04 |
mighty17[m] | ye thats 0.4.5 | 13:04 |
mighty17[m] | atleast the build instructions are fine? | 13:04 |
Wizzup | mighty17[m]: don't use that xf86-video-omap, use ours | 13:11 |
mighty17[m] | Wizzup: i was just trying to get build instructions and deps | 13:14 |
mighty17[m] | gonna modify that to suits ours | 13:14 |
Wizzup | I think we have a debian/control and debian/rules file | 13:16 |
Wizzup | for deps and such | 13:16 |
Wizzup | you'll also need to pkg the sgx stuff to build | 13:17 |
mighty17[m] | Wizzup: sgx-ddk-um? | 13:18 |
Wizzup | yes, see the build-depends on our xf86-video-omap | 13:18 |
* mighty17[m] is confused with sgx-ddk-umhttps://gitlab.com/postmarketOS/pmaports/-/tree/master/non-free/sgx-ddk-um | 13:18 | |
* mighty17[m] * is confused with sgx-ddk-um https://gitlab.com/postmarketOS/pmaports/-/tree/master/non-free/sgx-ddk-um | 13:20 | |
Wizzup | make sure it's the exact same we use | 13:20 |
Wizzup | I think the version might be different | 13:20 |
mighty17[m] | `1.17.4948957` ? | 13:22 |
Wizzup | per our repo... https://github.com/maemo-leste/sgx-ddk-um/commit/a1d07a194ea93882920292b5594169b03d19b257 | 13:23 |
Wizzup | check commit hash | 13:23 |
mighty17[m] | yeah we use ti's repo :D | 13:23 |
Wizzup | it might be the same, but better make sure | 13:23 |
Wizzup | I think I bumped it at some point | 13:24 |
mighty17[m] | Wizzup: it isnt :( | 13:24 |
* Wizzup bbiab | 13:24 | |
Wizzup | figured | 13:24 |
mighty17[m] | you're using older hash :( | 13:25 |
freemangordon | mighty17[m]: which has is the newest? | 13:28 |
freemangordon | 742cf38aba13e1ba1a910cf1f036a1a212c263b6? | 13:29 |
mighty17[m] | 551665bf9c321bc3e7721416e6ebbc9f65c18155 | 13:29 |
freemangordon | no, it is not :P | 13:29 |
freemangordon | there is a newer one in -next | 13:29 |
freemangordon | Wizzup: but yeah, we shall upgrade blobs to latest | 13:29 |
mighty17[m] | oh there's a next :o | 13:29 |
* mighty17[m] finds git.ti super slow | 13:30 | |
freemangordon | Wizzup: either 551665bf9c321bc3e7721416e6ebbc9f65c18155 or 742cf38aba13e1ba1a910cf1f036a1a212c263b6 | 13:30 |
mighty17[m] | 742cf38aba13e1ba1a910cf1f036a1a212c263b6 seems to be the newest with -next | 13:31 |
freemangordon | mhm | 13:31 |
mighty17[m] | 551665bf9c321bc3e7721416e6ebbc9f65c18155 is newest in zeus | 13:31 |
freemangordon | right | 13:31 |
mighty17[m] | whats the difference? | 13:31 |
freemangordon | 742cf38aba13e1ba1a910cf1f036a1a212c263b6 is just some headers so it is not really relevant | 13:31 |
mighty17[m] | `configure: error: Package requirements (sgx-ddk-um randrproto renderproto videoproto xextproto) were not met:` :( | 13:33 |
freemangordon | mhm | 13:33 |
freemangordon | you need to install the relevant -dev packages | 13:33 |
mighty17[m] | i dont think we have -dev for these | 13:34 |
mighty17[m] | https://git.alpinelinux.org/aports/tree/main/xextproto/APKBUILD?h=3.8-stable#n11 | 13:34 |
mighty17[m] | and def not for sgx-ddk-um | 13:35 |
freemangordon | well, you'll have to create | 13:36 |
mighty17[m] | for sgx-ddk-um yes, what do we need for others? its quite likely they were packaged | 13:38 |
freemangordon | they shoud be a part of xorg-dev (or similar) package | 13:39 |
mighty17[m] | freemangordon: https://packages.ubuntu.com/bionic/all/xorg-dev/filelist seems to only have docs? | 13:43 |
uvos | wtf | 13:44 |
freemangordon | x11proto-dev | 13:44 |
Wizzup | freemangordon: we haev -next afaik | 13:45 |
uvos | what dose it matter what some ubuntu package contains | 13:45 |
Wizzup | freemangordon: last time I pulled them | 13:45 |
uvos | you have to check what alpine package contains the headers | 13:45 |
freemangordon | Wizzup: ahm yes | 13:46 |
freemangordon | sorry, my bad | 13:46 |
mighty17[m] | https://pkgs.alpinelinux.org/package/edge/main/armv7/xorgproto | 13:46 |
mighty17[m] | already in deps | 13:46 |
mighty17[m] | uvos: i wanted to compare, like deb has some x file, what pkg in alpine has that x file | 13:47 |
freemangordon | well, you need xorgproto-dev, or whatever it is in alpine | 13:47 |
Wizzup | mighty17[m]: you can get a debian system and use dpkg -L | 13:47 |
freemangordon | also, xorgproto != x11proto-dev | 13:48 |
mighty17[m] | doesnt exist | 13:48 |
Wizzup | freemangordon: I suggest we just let mighty17[m] do the alpine packaging | 13:48 |
Wizzup | I think he'll figure out what he needs from autotools | 13:48 |
mighty17[m] | freemangordon: files seem to be similar :P | 13:48 |
freemangordon | yeah | 13:48 |
mighty17[m] | https://pkgs.alpinelinux.org/contents?branch=edge&name=xorgproto&arch=x86&repo=main | 13:48 |
mighty17[m] | Wizzup: deb doesnt have smth like pkgbuilds right? | 13:51 |
uvos | various files debian directlry | 13:51 |
uvos | *directory | 13:52 |
uvos | mostly crontrol and rules | 13:52 |
tmlind | freemangordon: pong | 13:58 |
freemangordon | tmlind: do you want to help me with upstreaming https://github.com/maemo-leste/droid4-linux/commit/f56836db3ec4210c5cfaf40fa721a6e21cd7730e ? The problem is that when we discussed that with Tomy over th ML back then he was opposing to this :) | 14:01 |
freemangordon | OTOH I don;t really think his arguments are valid, but I am not sure I can convince him | 14:01 |
freemangordon | *Tomi | 14:02 |
tmlind | freemangordon: not sure i can help much with that one | 14:03 |
freemangordon | well, without this omapdrm is more or less useless for anything else but a simple usecases | 14:04 |
freemangordon | esp n omap3 | 14:04 |
freemangordon | *on | 14:04 |
freemangordon | without that all GEM buffers must be allocated from CMA, otherwise they cannot be exported == PVR cannot render to them | 14:05 |
freemangordon | and given that CMA is unreliable... | 14:06 |
tmlind | ok | 14:06 |
freemangordon | tmlind: I am asking you because I know what the result be if I send that for upstreaming | 14:08 |
freemangordon | an instant NAK | 14:08 |
freemangordon | without even a discussion why and how | 14:08 |
freemangordon | I am not sure it will be the same if you send it | 14:08 |
freemangordon | but well... | 14:08 |
tmlind | heh i doubt me sending it makes any difference :) | 14:09 |
freemangordon | well, I bet it makes | 14:09 |
tmlind | best to have some clear test case in the description | 14:10 |
freemangordon | what do you mean? I don't think a test case is needed to prove that non-linear buffers are not exported. There are checks in current (upstream) code to assure that, -22 otherwise | 14:11 |
tmlind | how about some memory usage comparison in the description? | 14:18 |
tmlind | i guess on n900 it makes a difference | 14:18 |
freemangordon | I can do tiler_map comparison on d4, but it will be huge | 14:18 |
freemangordon | it makes all the difference on d4 as well | 14:19 |
freemangordon | this is needed as well https://github.com/maemo-leste/droid4-linux/commit/067976f0afd4a65bf32a3f450ee42f508a1b0612 | 14:19 |
uvos | problem is address space usage | 14:19 |
uvos | not physical ram | 14:19 |
tmlind | ah | 14:19 |
freemangordon | so either ways those 2 shall be send as series | 14:19 |
freemangordon | as 2 combined makes omapdrm stable for daily usage | 14:20 |
freemangordon | on d4 at least | 14:20 |
freemangordon | uvos: problem is eitehr address space usage (omap4) or cma (omap3) | 14:21 |
sicelo | okay ... i might just give up trying to calibrate the droid 4. 3 cycles completed, still mAh readout is 700mAh :-/ | 14:21 |
uvos | might be true | 14:21 |
uvos | i get 800-900mah for oem batterys | 14:21 |
uvos | (that are as old as teh devices ie ~2012) | 14:22 |
sicelo | no. | 14:22 |
uvos | if you say so | 14:22 |
sicelo | i have a new battery, and it lasts much longer than the previous one | 14:22 |
uvos | ok | 14:22 |
sicelo | the value hasn't changed even by 1mAh from old battery. that'd be a real miracle | 14:22 |
uvos | right | 14:23 |
uvos | so call dident compleat | 14:23 |
sicelo | the way i see it, calibration isn't happening. not sure why | 14:23 |
uvos | it needs to see empty+full and needs to shutdown cleanly | 14:23 |
sicelo | i charge to full, and i let the device go till empty. | 14:23 |
sicelo | so why it doesn't work ... beats me | 14:23 |
sicelo | what's the location of the saved file btw? maybe i shall delete that and see what happens | 14:24 |
uvos | /var/lib/droid4-battery-calibration/charge_full | 14:24 |
sicelo | thanks. let me check | 14:24 |
uvos | "i charge to full, and i let the device go till empty." it needs to shutdown cleanly | 14:25 |
uvos | rn the device allways oopses on shutdown | 14:25 |
uvos | because of some bug in uart | 14:25 |
uvos | that might be the reason | 14:25 |
sicelo | mmm | 14:25 |
Wizzup | right we should test if not detaching the console makes that go away | 14:26 |
uvos | it dose | 14:26 |
uvos | the oops | 14:26 |
Wizzup | maybe tmlind already has a patch for this | 14:27 |
Wizzup | I assume he should see it too, since we share the droid4-pm scripts | 14:27 |
sicelo | that charge_full file was last modified on Jan 5, so yeah, not got calibration since i replaced battery | 14:28 |
uvos | your battery might also just not be sutable | 14:28 |
uvos | the d4 needs really low ir | 14:28 |
uvos | with high ir it will shutdown way to soon | 14:29 |
uvos | because the voltage drops to mutch during the ms while the omap wakes up from ret | 14:29 |
uvos | leads also need to be short | 14:29 |
sicelo | i reused the original battery's controller | 14:33 |
uvos | thats not relevant | 14:34 |
sicelo | no leads in between. the new battery's terminals fit perfectly where the old ones did | 14:34 |
sicelo | anyway, i guess i'll accept this as broken for the time being | 14:35 |
uvos | you can also just set /var/lib/droid4-battery-calibration/charge_full to whatever you expect | 14:35 |
uvos | btwe | 14:35 |
uvos | maybe a bit lower | 14:35 |
uvos | this gives better results than uncalibrated | 14:36 |
Wizzup | freemangordon: what do you think about https://github.com/maemo-leste/bugtracker/issues/588 | 14:51 |
Wizzup | uvos: which patch did you want me to revert wrt wakeups | 15:05 |
Wizzup | a20f161298226a368d73af1b1467568ba5d05efa ? | 15:06 |
Wizzup | that is: drm/omap: get fbdev working for manually updated display | 15:06 |
freemangordon | Wizzup: looks ok | 15:10 |
Wizzup | freemangordon: I'll split it up into some mapphone specific stuff, too | 15:13 |
uvos | Wizzup: yess | 15:27 |
tmlind | Wizzup: sorry not sure if you already sent a device earlier for tomi.. i guess you'd have some email about it? | 16:12 |
Wizzup | tmlind: I'll check | 16:20 |
Wizzup | tmlind: looks like in 2019 with thread 'Motorola Droid 4 devices' | 16:21 |
Wizzup | I don't know if I sent two or three, but I think three, to Tero, Peter and Tomi might have hone already | 16:22 |
tmlind | ok | 16:32 |
Wizzup | uvos: kernel without fbdev emul is in repo | 17:15 |
uvos | Wizzup: great | 17:19 |
uvos | since you merged the series on leads | 17:20 |
uvos | please https://github.com/maemo-leste/leste-config/pull/28 | 17:20 |
Wizzup | hmm my X seems stuck here: [pid 3721] ioctl(12, DRM_IOCTL_MODE_SETPROPERTY, 0xbe85c978) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) | 17:26 |
Wizzup | no error in dmesg | 17:26 |
Wizzup | uvos: ok will merge | 17:27 |
freemangordon | ugh, libtool does not allow library revision to be > 99999 :( | 17:29 |
Wizzup | https://dpaste.com/2SSKGP2ZB I set drm.debug to 0xff when this happened | 17:29 |
Wizzup | freemangordon: weird | 17:30 |
uvos | ssomething something autotools :P | 17:30 |
freemangordon | no, this is lobtool ;) | 17:30 |
freemangordon | *libtool | 17:30 |
uvos | libtool ist part of autotools really | 17:31 |
uvos | practicly | 17:31 |
uvos | but ok | 17:31 |
freemangordon | Wizzup: no idea | 17:31 |
freemangordon | well, kinda makes sense, but cannot produce lib that matches PVR blobs versions | 17:32 |
freemangordon | at least not that easy | 17:32 |
uvos | hopfully firefox dosent use libtool | 17:34 |
uvos | they will reatch version 99999 next year probubly | 17:34 |
freemangordon | no, this is revision, not version ;) | 17:34 |
uvos | ah oh | 17:34 |
freemangordon | the same restrictions apply for version though :) | 17:34 |
Wizzup | freemangordon: wonder how pvrtool folks do it | 17:35 |
freemangordon | also, this is applicable to libs onjly | 17:35 |
freemangordon | Wizzup: yeah | 17:35 |
freemangordon | maybe they use Makefiles | 17:35 |
Wizzup | right | 17:35 |
Wizzup | btw so the drm debug I posted above, we can ignore it now but the screen on my d4 won't turn on | 17:36 |
Wizzup | it doesn't seem to be an X crash but X seems to get erestartsys | 17:36 |
Wizzup | and it keeps trying to do some ioctl | 17:36 |
Wizzup | so I'll reboot my d4 unless we want more debug info | 17:36 |
Wizzup | (gdb) bt | 17:37 |
Wizzup | #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78 | 17:37 |
Wizzup | #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:37 |
Wizzup | #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:37 |
Wizzup | #3 0xb66c3f12 in () at /usr/lib/xorg/modules/drivers/omap_drv.so | 17:37 |
Wizzup | is the gdb backtrace | 17:37 |
Wizzup | I did also try to run xrandr and xset later on, but I don't think this is because of that | 17:37 |
freemangordon | it tries to set "rotate" property, most-probably | 17:38 |
Wizzup | well the device was locked | 17:39 |
Wizzup | and then it wouldn't unlock | 17:39 |
Wizzup | so I wasn't sure what was up | 17:39 |
Wizzup | and then I ssh'd in and tried things | 17:39 |
Wizzup | so it might be perhaps turning on the display | 17:39 |
freemangordon | "wouldn't unlock" like? stays on black screen? | 17:39 |
Wizzup | yes | 17:39 |
freemangordon | right | 17:40 |
Wizzup | let me get ddx dbgsym for more accurate trace | 17:40 |
Wizzup | #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78 | 17:40 |
Wizzup | #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:40 |
Wizzup | #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 17:40 |
Wizzup | #3 0xb66c3f12 in drmmode_output_dpms (output=<optimized out>, mode=0) at drmmode_display.c:797 | 17:40 |
Wizzup | #4 0x005074f4 in xf86DPMSSet () | 17:40 |
Wizzup | #5 0x0050755c in xf86SaveScreen () | 17:40 |
Wizzup | #6 0x004db078 in dixSaveScreens () | 17:40 |
freemangordon | what is ret=-512 ? | 17:41 |
freemangordon | maybe send email to Tomi, no idea what is this | 17:41 |
freemangordon | uvos: btw, do you know if .so revision is somehow set in headers? | 17:44 |
freemangordon | like, do we care if it is lib.so.1.2.3 or lib.so.1.2.0? | 17:44 |
Wizzup | freemangordon: I think this: | 17:46 |
Wizzup | [pid 3721] ioctl(12, DRM_IOCTL_MODE_SETPROPERTY, 0xbe85c978) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) | 17:46 |
Wizzup | [pid 3721] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- | 17:46 |
Wizzup | [pid 3721] sigreturn({mask=[]}) = 12 | 17:46 |
freemangordon | cool, I have no clue what is this about :) | 17:47 |
uvos | not sure what you mean | 17:47 |
uvos | in pvr_k? | 17:47 |
freemangordon | in geberal | 17:47 |
freemangordon | *general | 17:47 |
uvos | pvr_k checks the version | 17:47 |
uvos | but it just gets it form some funciton | 17:48 |
uvos | i dont think the file name matters | 17:48 |
uvos | just what pvr_um reports | 17:48 |
freemangordon | no, I am talking about versions of the libs | 17:48 |
freemangordon | if I compile to lib.so.1.2.0 and later on rename to lib.so.1.2.3, does it change anything? | 17:48 |
freemangordon | besides symlinks, obviously | 17:49 |
uvos | pvr specificly? no | 17:50 |
uvos | other libs sure | 17:50 |
uvos | pretty sure i renamed some stuff while testing different variants | 17:51 |
freemangordon | "other libs sure" - what do you mean? | 17:51 |
uvos | wel obviously it can not be stated generally that compiling as 1.2.0 and renaming the lib later to something else is equivalent as passint something else to the build system | 17:52 |
uvos | since plenty of libs use the version string | 17:52 |
freemangordon | yes, but I am talking about revision, not version | 17:53 |
freemangordon | the '0' at the end | 17:53 |
uvos | same thing | 17:53 |
freemangordon | but, does this get included anywhere else, but in the name? | 17:53 |
freemangordon | basically this is the question | 17:54 |
uvos | question is essantally unawnserable since doing so would force me to prove a negative | 17:56 |
uvos | so no idea | 17:56 |
uvos | you certenly could do this | 17:56 |
freemangordon | yeah, my question was rather "do you know". | 17:57 |
freemangordon | no need to prove anything | 17:57 |
freemangordon | I'll do it to work, if we hit issues, well | 17:57 |
freemangordon | *make it to | 17:57 |
lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/leste-config/pull/28 (bionic and droid 3: add ts-buttons light to mce now that the kernel c…) | 18:19 |
buZz | oh nice, those work on droid4 too now? | 18:24 |
buZz | o | 18:24 |
buZz | i'll try ;) | 18:24 |
Wizzup | the sw is still building and only for -devel | 18:28 |
lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/mapphone-kexecboot-config/pull/1 (Add charge mode to all devices) | 18:32 |
Wizzup | uvos: I think sphone should go in the connectivity meta yeah | 18:34 |
lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/hildon-connectivity-meta/pull/1 (Update control) | 18:40 |
Wizzup | uvos: with adding charge-mode to hildon-meta, have we confirmed it works on the n900? | 18:41 |
buZz | welp, droid4 discharged itself while off again :P | 18:43 |
uvos | Wizzup: yes when you switch the runlevel switches to it | 18:43 |
lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/hildon-meta/pull/6 (add salutem, charge-mode and sphone to hildon-meta, siwtch pp to libinput) | 18:43 |
uvos | Wizzup: but dident try with the drm version | 18:43 |
Wizzup | uvos: do you mean kernel cmdline? | 18:43 |
uvos | no switch later | 18:43 |
uvos | also dosent matter, as long as its not in cmdline | 18:43 |
uvos | it dose nothing | 18:43 |
Wizzup | uvos: uh ok so now all devices lack fbdev emul but we just enabled chargemode for them | 18:43 |
uvos | no no | 18:44 |
uvos | i switch chargemode to drm | 18:44 |
Wizzup | ok | 18:44 |
uvos | *swiched | 18:44 |
uvos | so it works on mapphones (tested with drm verson) and n900 (tested only with older fbdev version) | 18:44 |
uvos | but really it likey works everywhere | 18:45 |
uvos | and it will only be active on mapphones | 18:45 |
uvos | since only they got the cmdline change | 18:45 |
Wizzup | ok | 18:45 |
Wizzup | I think I merged all the PRs and it's all building atm | 18:46 |
Wizzup | uvos: any I missed? | 18:48 |
uvos | no | 18:48 |
Wizzup | ok | 18:53 |
Wizzup | cool, ty | 18:53 |
uvos | [18:24] <buZz> oh nice, those work on droid4 too now? | 18:55 |
uvos | this has worked on d4 since a long time | 18:55 |
buZz | oh guess i just missed it | 18:57 |
Wizzup | they are off on mine | 18:58 |
uvos | right you disabled this on purpose | 18:59 |
Wizzup | mhm | 19:05 |
dsc_ | sicelo: OTP/2FA GUI for maemo (like Google Authenticator) | 19:11 |
dsc_ | do you know anything about that | 19:11 |
freemangordon | dsc_: there was some discussion on TMO a week or so ago | 19:13 |
dsc_ | I take it there is no 2FA app (like Google Authenticator) for leste currently? | 19:15 |
dsc_ | apart from `oathool` which is a CLI app | 19:16 |
dsc_ | (also the camera probably doesnt work yet :P) | 19:17 |
dsc_ | anyway, I made a 2FA app just checking if it already existed | 19:18 |
sicelo | dsc_: yes i know about it and i ported it to Leste | 19:18 |
dsc_ | sicelo: link? | 19:18 |
sicelo | https://github.com/maemo-leste-extras/maeotp | 19:18 |
sicelo | anyway, maybe yours will work better for new users | 19:19 |
dsc_ | mine can be described as a Google Authenticator clone | 19:20 |
dsc_ | GUI wise | 19:20 |
dsc_ | ill push it to git sometime and ping you I guess | 19:21 |
dsc_ | we can have both | 19:21 |
dsc_ | ヾ(⌐■_■)ノ♪ | 19:21 |
sicelo | yes, users will appreciate it | 19:21 |
sicelo | i'm not going to switch myself tbh ... because i already have years of keys in the format of this one :-) | 19:22 |
sicelo | it has a big limitation in that you have to convert the code first, so yes, for most new users it's a great PITA. i think yours will therefore be the better one | 19:23 |
dsc_ | https://plak.infrapuin.nl/selif/lber6pgj.png | 19:25 |
dsc_ | UI still far from done though just WIP | 19:25 |
dsc_ | it only supports TOTP | 19:26 |
dsc_ | base32 (QR) codes | 19:26 |
sicelo | cool. yes, only totp seems to be in use nowadays | 19:26 |
dsc_ | right | 19:26 |
dsc_ | I wondered that :P | 19:26 |
sicelo | dsc_: question though - why something from scratch? | 19:31 |
dsc_ | I tend to start projects without checking if it existed already :/ | 19:32 |
dsc_ | tbh I wanted to make a 2FA app anyway for my Ubuntu desktop :P | 19:33 |
dsc_ | and then I was like "I should port it to leste" | 19:33 |
dsc_ | been only working on this for a few days though... | 19:33 |
dsc_ | so regardless if its handy for leste, I want a Google Authenticator-like app for my Ubuntu laptop | 19:34 |
freemangordon | Wizzup: do you know how to mv in Makefile.am install-exec-hook? | 19:34 |
freemangordon | I mean - what is the 'canonical' way? | 19:34 |
Wizzup | sorry, don't know what you want exactly | 19:35 |
freemangordon | to rename a file | 19:35 |
sicelo | dsc_: sure, please port it :-) | 19:35 |
sicelo | i think i'm the only user of the one i ported, so effectively there isn't one for Leste | 19:36 |
dsc_ | sicelo: so turns out the options are kind of limited for OTP GUIs on linux, which surprised me. Granted, having 2FA codes on your desktop defeats the purpose, but still. | 19:36 |
Wizzup | dsc_: probably they all use android ;) | 19:37 |
sicelo | i see two GTK ones in sid | 19:37 |
sicelo | i think you're a Qt guy .. ;-) | 19:37 |
dsc_ | well as a user I wouldnt care | 19:37 |
dsc_ | you're right, `otpclient` seems to work fine | 19:38 |
sicelo | gnome-authenticator and otpclient ... i haven't used any of them | 19:38 |
sicelo | but don't get me wrong - i wasn't saying don't write one ... was just asking | 19:39 |
sicelo | i don't even know how these work on Leste (for obvious reasons) | 19:40 |
dsc_ | But, for example, this `otpclient` might look scary to new users, it's more of a power-user tool. We need to bring Linux to the desktop in 2022. All GUIs need to have 3D particle explosions to wow the crowd. | 19:40 |
dsc_ | therefor I will continue my efforts. | 19:41 |
dsc_ | therefore* | 19:41 |
bencoh | as long as the particle explosions can be disabled .... :) | 19:42 |
dsc_ | :D | 19:42 |
bencoh | I'm half-serious :) | 19:43 |
sicelo | 20:26 < dsc_> base32 (QR) codes ... you're saying it only takes QR codes? | 19:43 |
dsc_ | sicelo: Yeah QR code via webcam or desktop screenshot | 19:44 |
dsc_ | (or phone camera) | 19:45 |
sicelo | i hope you'll also support text entry (of the code/string) | 19:46 |
sicelo | because on Leste, for example, juggling a screenshot is less easier than copying the code onto clipboard, then pasting ;-) | 19:47 |
dsc_ | indeed, will do. Google Authenticator also supports this. So my app will at least be on-par regarding capabilities with that one | 19:47 |
dsc_ | but it wont be as feature rich as yours | 19:48 |
sicelo | heh, this one is quite bare, and no casual user is even able to make it work | 19:49 |
dsc_ | ill try yours in a bit | 19:50 |
sicelo | it's specifically for Hildon (and i didn't write it ... just ported it) | 19:51 |
dsc_ | cool | 19:51 |
dsc_ | yeah next time ill ask here before writing something lol | 19:51 |
freemangordon | uvos: no idea what did you do, but since yesterday leste refuses to charge here | 19:52 |
freemangordon | I am booting with cable connected to fastcharger (after power-down because of a low battery), it boots to h-d (maybe) and then instantly beeps and powers-down | 19:53 |
freemangordon | on d4 that is | 19:53 |
uvos | freemangordon: yes thats expected | 19:54 |
freemangordon | oh, now I feel better :D | 19:55 |
uvos | it was a temporary situation because the charge mode pr was merged later | 19:55 |
uvos | just boot emergency mode | 19:55 |
uvos | it will charge there | 19:55 |
freemangordon | I boot to android | 19:55 |
uvos | sure that works too | 19:55 |
uvos | this issue is now fixed | 19:55 |
freemangordon | and it charges there, but android says 15% full | 19:55 |
freemangordon | fixed how/where? | 19:55 |
uvos | with Wizzup merging the pr just now | 19:55 |
freemangordon | ah, ok | 19:55 |
freemangordon | what is the fix? | 19:56 |
uvos | enabling charge mode | 19:56 |
uvos | so that this works as designed | 19:56 |
freemangordon | hmm, android just boots | 19:56 |
uvos | ie stays in charge mode at least untill the battery is safe to boot | 19:56 |
uvos | hmm? | 19:56 |
uvos | it dosent boot to kexecboot? | 19:56 |
freemangordon | it boots and then I select 'android' | 19:57 |
freemangordon | and it boots there, which means battery has enough charge | 19:57 |
freemangordon | 15% | 19:57 |
freemangordon | some limit is not quite right | 19:57 |
uvos | no its fine | 19:57 |
freemangordon | how's that? | 19:57 |
uvos | its just more conservative than android | 19:57 |
uvos | beacuse 1. we take longer to boot 2. android takes the battery down to 3.0v | 19:58 |
uvos | which is pretty bad for it | 19:58 |
freemangordon | as I said it boots to h-d | 19:58 |
freemangordon | but refuses to charge and instead powers down | 19:58 |
uvos | and 3 we can only take 500mah form usb | 19:58 |
uvos | android can take 1.5A | 19:58 |
uvos | *500mA | 19:58 |
uvos | these 3 factors allow android to boot way sooner | 19:58 |
freemangordon | what do you mean "usb"? this is not USB but fastcharger | 19:58 |
uvos | dosent matter | 19:59 |
uvos | mainline kernel has no way to detect this | 19:59 |
freemangordon | wait, you are saying we are limited to 500 mA? | 19:59 |
uvos | or negotiate for high power device class | 19:59 |
uvos | yes we are | 19:59 |
freemangordon | omg | 19:59 |
uvos | even that is a hack | 19:59 |
freemangordon | this is useless, basically | 19:59 |
uvos | we dont negotiate for high power | 19:59 |
uvos | so we violate usb spec | 19:59 |
uvos | we should only take 500uA | 19:59 |
uvos | i would not call it useless | 20:00 |
uvos | it just takes longer | 20:00 |
freemangordon | no, because you cannot use your device for how many minutes? 10? | 20:00 |
uvos | no | 20:01 |
uvos | just 2 minutes or so | 20:01 |
freemangordon | also, you cannot use your device while charging with low battery | 20:01 |
freemangordon | as it drains the battery instead of charging it | 20:01 |
uvos | in my experiance you can | 20:01 |
uvos | as long as your not loading it hevly | 20:01 |
uvos | ie compiling is out | 20:01 |
freemangordon | yeah | 20:01 |
uvos | but webbrowsing is fine | 20:01 |
freemangordon | who should fix this charging thing? | 20:01 |
uvos | https://github.com/maemo-leste/bugtracker/issues/580 | 20:02 |
uvos | read this | 20:02 |
uvos | someone | 20:02 |
uvos | at some point :P | 20:02 |
freemangordon | :) | 20:02 |
uvos | the driver needs to negotiate over usb | 20:02 |
freemangordon | uvos: still, this is broken | 20:05 |
freemangordon | there are no low battery warnings at all | 20:06 |
uvos | it unimplemented, not broken | 20:06 |
freemangordon | at some point device just powers down | 20:06 |
uvos | there are low battery warnings | 20:06 |
uvos | no | 20:06 |
uvos | or yes | 20:06 |
freemangordon | no, there are not | 20:06 |
uvos | yes there are | 20:06 |
uvos | its just | 20:06 |
uvos | that due to how cpcap works | 20:06 |
uvos | you cant know what state of charge the battery is in | 20:06 |
uvos | unless you see the battery full during that boot | 20:06 |
uvos | and charge estimation from voltage in upower is terrible | 20:07 |
freemangordon | and what about upower? | 20:07 |
uvos | to the point of uselessness | 20:07 |
uvos | so it thinks the battery is at 40% charge while it has a resting voltage of 3.2 or something | 20:07 |
uvos | if there is adquate current | 20:07 |
freemangordon | useless or not, it is better to give 10 fake low battery warnings than no warning at all and power-down out of the blue | 20:07 |
uvos | upower needs the kernel to report charge staten wich cant unless you see the battery full during that boot | 20:08 |
uvos | or it needs to estimate | 20:08 |
uvos | witch it dose, very poorly | 20:08 |
uvos | freemangordon: your welcome to improve it :P | 20:08 |
freemangordon | yeah | 20:08 |
freemangordon | before latest change it was doing pretty much ok | 20:09 |
freemangordon | now this is useless | 20:09 |
freemangordon | it at least was allowing me to boot to h-d and charge | 20:09 |
freemangordon | and actually use the device | 20:09 |
freemangordon | now it does not | 20:09 |
uvos | "my latest change" ensures the battery dosent dicharged below 3v | 20:09 |
uvos | wich was routinly happening | 20:10 |
uvos | and runined one of my new batterys | 20:10 |
uvos | so yeah im not removing that | 20:10 |
uvos | it works fine | 20:10 |
sicelo | :) | 20:10 |
uvos | (with charge mode enabled) | 20:10 |
freemangordon | uvos: the easiest way to ensure that is to not turn on the device, no? | 20:12 |
uvos | you cant this is set by the bootloader | 20:12 |
freemangordon | sure i can, by simply not pressing the power buttonj | 20:13 |
uvos | i also can avoid geting into a car accident by handing myself | 20:13 |
freemangordon | anyway, I think we need to have a discussion soon on what quality we want to produce | 20:14 |
freemangordon | i.e. are we happy with things that works when the planets are aligned | 20:14 |
freemangordon | but only then | 20:14 |
uvos | this is a silly discussion to have | 20:15 |
* freemangordon is afk | 20:15 | |
uvos | no one wants these imperfect solutions | 20:15 |
uvos | its just a question of what you want to work on to improve | 20:15 |
Wizzup | freemangordon: do you know where the tp account manager info is stored in fremantle | 20:40 |
Wizzup | freemangordon: just mission control stuff I guess | 20:41 |
freemangordon | umm, in the same place as in upstream | 20:41 |
freemangordon | what in particular do you need? | 20:41 |
Wizzup | just want to look around, see what params are used for telepathy-idle on my fremantle n900 | 20:43 |
freemangordon | ah | 20:43 |
freemangordon | it should be in /usr/share/telepathy | 20:43 |
freemangordon | iirc | 20:43 |
Wizzup | user accounts? | 20:44 |
Wizzup | ok I didn't mean this, but this is also helpful | 20:45 |
sicelo | mc-tool list | 20:45 |
sicelo | then mc-tool show <account ...> | 20:46 |
Wizzup | freemangordon: as in it is not in .config | 20:46 |
freemangordon | hm,, it should be in .config | 20:46 |
freemangordon | is it not? | 20:46 |
Wizzup | sicelo: hm I don't have mc-tool | 20:46 |
Wizzup | freemangordon: well let me dig | 20:46 |
sicelo | oh, maybe you need to install it. i've always had it on my N900 and thought it came ootb | 20:47 |
freemangordon | Wizzup: .local/share? | 20:48 |
sicelo | mc-tool comes from libmissioncontrol-utils | 20:48 |
freemangordon | I forgot where addressbook was kept | 20:49 |
Wizzup | .rtcom-accounts | 20:49 |
Wizzup | seems more like nokia specific way of storing the info though | 20:50 |
Wizzup | as in I doubt that missioncontrol reads that | 20:51 |
freemangordon | I think those are not mc accounts | 20:52 |
freemangordon | this is different to mission-control, iiuc | 20:52 |
freemangordon | not sure though | 20:52 |
Wizzup | well mission-control is just account manager and channel dispatcher | 20:53 |
Wizzup | maybe you call account manager where to read accounts from or something | 20:54 |
Wizzup | maybe you can tell* | 20:54 |
freemangordon | no idea | 20:54 |
Wizzup | freemangordon: probably they parse it in rtcom binaries and just initiate Connection with those params from it | 20:57 |
Wizzup | at connmgr | 20:57 |
freemangordon | could be, yeah | 20:57 |
freemangordon | uvos: device just powered down after sitting almost idle on the charger since we talked. maybe you ramp-up patch doesn't play well with the charger I have here | 21:10 |
freemangordon | but it was wotking ok before | 21:10 |
Wizzup | it improved the situation for me (no flickering when I plug it into a device), but of course it might be different for different devices/cables/chargers | 21:11 |
uvos | was the green light on? | 21:11 |
freemangordon | no | 21:11 |
Wizzup | although the status not updating is annoying, since that impacts upower and also mce | 21:11 |
uvos | then it wasent charging | 21:11 |
freemangordon | yes | 21:11 |
freemangordon | it wasnt | 21:11 |
uvos | the green light is 100 hw indicator | 21:11 |
uvos | *100% | 21:11 |
freemangordon | sure | 21:12 |
freemangordon | it was turning green before | 21:12 |
uvos | the issue the ramp up fixes is pretty easy to see on a scope | 21:12 |
uvos | cpcap will turn off charging if the voltage ever dips below a certain threshold | 21:12 |
freemangordon | I don;t argue it it fixes issues or not | 21:13 |
uvos | with quite high bandwith | 21:13 |
freemangordon | nut since yesterday my device refuses to charge under leste | 21:13 |
uvos | so if it stoped charging this happend | 21:13 |
Wizzup | freemangordon: what is the problem you are seeing now, that it doesn't charge with new patches? | 21:13 |
freemangordon | yes, it does not charge | 21:13 |
freemangordon | oh, now it turned green | 21:13 |
freemangordon | (the light) | 21:13 |
freemangordon | after restart | 21:13 |
freemangordon | and I got "charging" yellow stripe | 21:14 |
freemangordon | no idea what's going on | 21:14 |
uvos | the patch has also been in kernel longer than yesterdat | 21:14 |
uvos | *day | 21:14 |
uvos | afaik | 21:14 |
uvos | but i dont use leste kernel | 21:14 |
freemangordon | and now there is indication in the status bar that it charges | 21:15 |
freemangordon | weird | 21:15 |
uvos | sure that usually works | 21:15 |
Wizzup | freemangordon: yeah so the delay there I think is a 30s one, which is when upower polls | 21:15 |
uvos | sometimes it fails tho | 21:15 |
freemangordon | not since yesterday | 21:15 |
freemangordon | till 2 minutes ago | 21:15 |
uvos | sometimes its immidately recognised | 21:15 |
freemangordon | it was not recognized at all | 21:15 |
freemangordon | but yeah, lets see | 21:16 |
freemangordon | maybe some HW weirdness | 21:16 |
freemangordon | uvos: could it be that android had put it in some weird state? | 21:18 |
uvos | mabye - probubly not | 21:40 |
Wizzup | freemangordon: so it looks like for tp we will need a program that starts tp connections on protocols/accounts. basic one is a ring connection for tel protocol | 21:43 |
Wizzup | but something must request the account for sms to come in | 21:43 |
Wizzup | I suppose whichever program requests it will also log? | 21:43 |
Wizzup | or do we want a separate account for logging | 21:43 |
Wizzup | I think nokia decided to combine these things | 21:44 |
Wizzup | so if I had to guess, rtcom-call-ui sets up tp account with channels for calls, and rtcom-messaging-ui sets up tp account with channels for text(s) | 21:44 |
Wizzup | and both do rtcom logging | 21:44 |
Wizzup | (that is, the ui processes) | 21:44 |
freemangordon | Wizzup: I am almost sure all this is explained on maemo.org wiki | 21:47 |
Wizzup | I am pretty sure I know how it works, it was a question for how we want to do it | 21:48 |
Wizzup | but if you want to link me maemo.org wiki pages, that'll be helpful I guess | 21:48 |
freemangordon | ah, it is fine, I mean - if you know how it works, ok | 21:49 |
Wizzup | I don't like the idea of requiring a GUI to log | 21:49 |
Wizzup | but it probably makes the most sense since we need something to 'request' telepathy to start the so-called connection managers | 21:49 |
Wizzup | (and connections on those connection managers) | 21:49 |
freemangordon | I think nokia did a good job there | 21:50 |
Wizzup | like, telepathy-ring is a connection manager and to receive smses (and have telepathy-ring run at all) we need to request an account on it with protocol 'tel' | 21:50 |
freemangordon | so maybe do it like they did | 21:50 |
Wizzup | k | 21:50 |
Wizzup | ok | 21:51 |
uvos | sphone can run without gui now btw, we could easly implment the logging as a sphone module and then spwan one non gui sphone process for logging or only one process with logging and ui loaded as desired | 21:53 |
uvos | as everything is a module you can pick an choose what process dose what | 21:53 |
Wizzup | right, but the fact that something must for example request a ring account means that whichever requests it can also do the logging | 21:53 |
Wizzup | we could separate the logging, but programs also need to request connections so that they can act on incoming messages | 21:53 |
Wizzup | or send messages | 21:54 |
Wizzup | i.e. even if conversations mostly just reads from a db now, it must be able to send message | 21:54 |
Wizzup | messages | 21:54 |
uvos | sure | 21:54 |
Wizzup | and to do it that it must talk to telepathy, request connections, and manage those connections, and create (or 'ensure') channels on those connections | 21:54 |
uvos | im just saying that sphones arch makes it easy to implement the "monlithic" nokia esque shortcut way now | 21:54 |
Wizzup | so we -could- have a module that just onlines/activates connections | 21:54 |
uvos | and implement something better later | 21:54 |
Wizzup | and another module that just does logging | 21:55 |
uvos | without throwing most of it out | 21:55 |
Wizzup | but it might not make sense that way | 21:55 |
Wizzup | uvos: sure, I'm still just understanding telepathy | 21:55 |
Wizzup | not making 'design decisions' in that sense yet | 21:55 |
Wizzup | tp also has different client types: observers, approvders and handlers | 21:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!