| lel | IMbackK opened a pull request: https://github.com/maemo-leste/mapphone-kexecboot-config/pull/1 (Add charge mode to all devices) | 00:00 |
|---|---|---|
| lel | IMbackK opened 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) | 00:02 |
| Wizzup | uvos: ok, can do tomorrow eve | 01:06 |
| * Wizzup zz | 01:10 | |
| Wizzup | uvos darn we missed huckg, I guess he'll be back | 01:10 |
| sicelo | I am now on my 3rd charge cycle with droid 4 and still battery isn't calibrated. What am I missing? I charge the device to full, then allow it to run empty, without any reboot or charging in between | 03:00 |
| mighty17[m] | <freemangordon> "ant then ./configure" <- same thing https://paste.debian.net/1226369/ | 07:56 |
| freemangordon | mighty17[m]: try https://www.systutorials.com/docs/linux/man/1-autoupdate/ | 08:18 |
| freemangordon | never used that, so no idea if it will going to help | 08:19 |
| mighty17[m] | `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)` fails here | 08:19 |
| freemangordon | hmm, maybe you are missing some -dev package | 08:20 |
| freemangordon | libxrandr-dev | 08:20 |
| freemangordon | and x11proto-randr-dev | 08:20 |
| freemangordon | mighty17[m]: what OS you're trying to compile on? | 08:21 |
| freemangordon | mighty17[m]: https://github.com/merge/xf86-input-tslib/issues/9 | 08:22 |
| mighty17[m] | freemangordon: alpine | 08:23 |
| freemangordon | yeah, all signs point that yiy're missing xorg-dev | 08:23 |
| freemangordon | *you're | 08:23 |
| mighty17[m] | i do have xorg-dev | 08:23 |
| mighty17[m] | https://pkgs.alpinelinux.org/package/edge/main/armv7/libx11-dev | 08:23 |
| freemangordon | xorg-dev != libx11-dev | 08:25 |
| mighty17[m] | but the error is missing ) | 08:25 |
| mighty17[m] | freemangordon: what does xorg-dev have? | 08:26 |
| freemangordon | sec, lemme boot my d4 | 08:26 |
| freemangordon | mighty17[m]: /usr/share/aclocal/xorg-server.m4 | 08:29 |
| freemangordon | check which package provides that on alpine | 08:30 |
| freemangordon | xorg-server-dev | 08:30 |
| mighty17[m] | https://pkgs.alpinelinux.org/contents?branch=v3.3&name=xorg-server-dev&arch=x86&repo=main | 08:30 |
| freemangordon | mhm | 08:30 |
| freemangordon | install that | 08:30 |
| mighty17[m] | already installed | 08:30 |
| freemangordon | ok, what is on line 20131 in configure? | 08:31 |
| freemangordon | also, what shell is that? bash? | 08:31 |
| mighty17[m] | freemangordon: ash | 08:33 |
| mighty17[m] | <mighty17[m]> "`XORG_DRIVER_CHECK_EXT(RANDR..." <- This is the line | 08:33 |
| * mighty17[m] uploaded an image: (11KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/LcTKzsJZNfLXSVlPIcWUaoAx/image.png > | 08:34 | |
| mighty17[m] | Its underlined in red? Why so | 08:34 |
| freemangordon | it seems it cannot find XORG_DRIVER_CHECK_EXT | 08:34 |
| freemangordon | are you sure you have /usr/share/aclocal/xorg-server.m4 ? | 08:35 |
| mighty17[m] | I'll check again | 08:36 |
| mighty17[m] | freemangordon: I somehow don't :o | 08:39 |
| mighty17[m] | alocal doesn't exist | 08:40 |
| mighty17[m] | Nvm I do | 08:40 |
| mighty17[m] | its aclocal not alocal😅 | 08:40 |
| freemangordon | well, no idea then. bbl in 20 miutes | 08:41 |
| mighty17[m] | I'll comment it :P | 08:42 |
| mighty17[m] | Now it fails to find sgx-ddk-um which I definitely have | 08:46 |
| mighty17[m] | https://gitlab.com/postmarketOS/pmaports/-/tree/master/non-free/sgx-ddk-um | 08:47 |
| freemangordon | you need -dev package | 08:59 |
| freemangordon | mighty17[m]: https://github.com/maemo-leste/sgx-ddk-um | 09:00 |
| freemangordon | this is what you need in terms of headers etc | 09:01 |
| freemangordon | but, I am not sure it will build outside of debian | 09:01 |
| freemangordon | is alpine .deb based? | 09:02 |
| sicelo | no :-) | 09:02 |
| sicelo | he'll have to repackage it alpine's way (.apk) | 09:03 |
| freemangordon | yeah, I see | 09:03 |
| freemangordon | mhm | 09:03 |
| freemangordon | mighty17[m]: also, I think you are mistaking pkgconfig for apk packages | 09:05 |
| freemangordon | the fact that you have sgx-ddk-um installed does not mean you have sgx-ddk-um.pc file installed on the system | 09:05 |
| freemangordon | also, I would recommend ascing on some #alpine or such channel why is XORG_DRIVER_CHECK_EXT not found | 09:06 |
| freemangordon | this looks like autotools are either broken on alpine or you need to insatll some additional packages | 09:06 |
| freemangordon | *asking | 09:07 |
| * mighty17[m] wonders if it's just better to switch to leste | 09:18 | |
| mighty17[m] | <freemangordon> "this looks like autotools are..." <- Yeah it seems like I need to package more things | 09:18 |
| freemangordon | mighty17[m]: sure it is better (switch to leste) :) | 09:19 |
| mighty17[m] | But /me doesn't want quite like the ui (no offense) | 09:20 |
| freemangordon | you'll get used to it :p | 09:20 |
| sicelo | haha, what don't you like about it? not offended :p | 09:21 |
| freemangordon | uvos: oh, on 5.11 we have some prv hacks that seem to deal with GEM buffers | 09:24 |
| freemangordon | https://github.com/maemo-leste/droid4-linux/commit/4d2ded9ec09ded4ab1f08faff9ee6a7ad04f35f9#diff-9b3c6ba4dcbd05c07bafe254dd7bc5fd1ac42fede2f7d43aa8250a20c31eecb3 | 09:24 |
| freemangordon | so, that's why we only have one TILER buffer | 09:27 |
| freemangordon | I'll have to port that or similar logic | 09:28 |
| mighty17[m] | <sicelo> "haha, what don't you like..." <- Well it just feels different 😅 | 09:31 |
| tmlind | freemangordon: just please don't add back the custom ioctl proxying stuff.. | 09:35 |
| freemangordon | no | 09:37 |
| freemangordon | I am going to fix dma_buf support | 09:37 |
| freemangordon | and move away from omap_bo | 09:37 |
| tmlind | ok nice | 09:37 |
| freemangordon | tmlind: do you have couple of minutes to discuss what I plan to do? | 09:37 |
| freemangordon | I may be missing something, need to talk about that and see | 09:38 |
| tmlind | freemangordon: sure, glad to help if i can :) | 09:38 |
| freemangordon | ok, so the plan: | 09:39 |
| freemangordon | 1. implement full dma_buf (gbm.h) flags support in omap_gem_dumb_create so: | 09:39 |
| freemangordon | - GBM_BO_USE_SCANOUT buffers are always allocated through TILER (and vrfb if we support for it someday) | 09:40 |
| freemangordon | that way I hope there will be no need to reallocate buffers on rotation | 09:41 |
| freemangordon | - if GBM_BO_USE_LINEAR is not passed, allocate ordinary dma memory (I think this is called SHMEM in omapdrm) | 09:41 |
| freemangordon | - GBM_BO_USE_RENDERING is simply ignored as we can always render | 09:42 |
| freemangordon | tmlind: ^^^ | 09:42 |
| freemangordon | do I miss something? | 09:42 |
| freemangordon | oh, in addition: | 09:43 |
| freemangordon | non-scanout, but GBM_BO_USE_LINEAR buffers are allocated through DMM/CMA | 09:43 |
| freemangordon | (omap4/omap3) | 09:43 |
| freemangordon | 2. remove omap_bo usage from omap DDX and replace it with gbm BOs | 09:44 |
| tmlind | ok sounds like a plan to me :) | 09:45 |
| freemangordon | https://github.com/robclark/libgbm/blob/master/gbm.h | 09:45 |
| freemangordon | for reference | 09:45 |
| freemangordon | BTW, I think if I manage to implement that, modesetting will be happy too | 09:45 |
| freemangordon | so, do I miss something? | 09:46 |
| tmlind | seems like the hardware with tiler/vrfb could always use tiler/vrfb for allocations? | 09:46 |
| freemangordon | what do you mean? | 09:47 |
| tmlind | so do you even need to consider GBM_BO_USE_LINEAR at all? | 09:47 |
| freemangordon | yes | 09:47 |
| freemangordon | because TILER and DMM are basically the same thing | 09:47 |
| tmlind | ok, and i guess tiler allocations are never linear :) | 09:47 |
| freemangordon | and using DMM for every buffer leads to TILER/DMM memory space become fragmented | 09:48 |
| tmlind | ok | 09:48 |
| freemangordon | and eventually (and we see that in practice) we end-up with not big enough space for the net TILER allocation | 09:48 |
| freemangordon | and -16 | 09:48 |
| tmlind | ok | 09:48 |
| freemangordon | DDK 1.9 uses only one TILER buffer | 09:49 |
| tmlind | so few things i noticed again while testing your fix yesterday | 09:49 |
| freemangordon | averything is faster? :p | 09:49 |
| freemangordon | *everything | 09:49 |
| tmlind | have not started removing my hacks yet.. but looks like omapdrm EGL_EXT_image_dma_buf_import_modifiers implementation is incomplete | 09:49 |
| tmlind | it's missing the implementation for buffer formats and count or something like that | 09:50 |
| freemangordon | do you use latest mesa? | 09:50 |
| tmlind | yeah your latest mesa branch | 09:50 |
| freemangordon | 'your' like leste? | 09:50 |
| freemangordon | tmlind: this https://github.com/maemo-leste-upstream-forks/mesa/commits/maemo/beowulf-devel | 09:51 |
| freemangordon | you should use that, there is a fix for EGL_EXT_image_dma_buf_import_modifiers being announced as supported | 09:52 |
| freemangordon | it is not | 09:52 |
| freemangordon | this is the patch, basically https://github.com/maemo-leste-upstream-forks/mesa/commit/a57505743270bbfeb33a2c8a863f596fe58a556c | 09:52 |
| tmlind | ah ok great, will try, i was seeing wlroots fail for eglQueryDmaBufFormatsEXT | 09:53 |
| freemangordon | yeah, we were reporting wring DRI_IMAGE version to mesa | 09:53 |
| tmlind | ok | 09:53 |
| freemangordon | which was implying EGL_EXT_image_dma_buf_import_modifiers is supported | 09:53 |
| tmlind | ok. so the other thing i noticed is again the use of render nodes | 09:53 |
| freemangordon | please use leste mesa | 09:54 |
| tmlind | yup will update | 09:54 |
| tmlind | so for trying to use the render nodes, it's the sgx blobs that fail for basic operations | 09:54 |
| freemangordon | BTW, keep in mind I touched DRM/MESA/$whatever code few months ago :) | 09:54 |
| tmlind | yup | 09:55 |
| freemangordon | so I am not sure I really know how is this supposed to work | 09:55 |
| freemangordon | tmlind: basic operations like? | 09:55 |
| freemangordon | aren;t render node calls end in PVR driver? | 09:56 |
| tmlind | yeah just fyi.. there's some unnecessary or broken fd filtering in the sgx blobs libdbm it seems | 09:56 |
| freemangordon | I pushed that to IDA back then and it seems it mostly calls omapdrm driver, not pvr | 09:56 |
| tmlind | hmm ok | 09:57 |
| freemangordon | but didn;t dig deep into it | 09:57 |
| tmlind | let me dig up the error on trying to use the render nodes | 09:57 |
| freemangordon | ok, those failures, do we have problem with them like mesa fails or what? | 09:58 |
| tmlind | first error is PVR:(Error): PVRDisplayBufferCreate: Failed to create display buffer (err=13) [0, ] | 09:58 |
| tmlind | yup | 09:58 |
| freemangordon | oh, wait | 09:58 |
| freemangordon | this is not supported | 09:58 |
| freemangordon | or, this is mesa? | 09:58 |
| tmlind | so i think libdbm dbm_buffer_create fails? | 09:58 |
| freemangordon | yeah, could be | 09:59 |
| freemangordon | what kernel is that? | 09:59 |
| tmlind | seems like dbm_buffer_create does some pointless fd path checks or something | 09:59 |
| tmlind | this is with v5.15 based patches, current wlroots | 09:59 |
| freemangordon | tmlind: omapdrm was refusing to export non-liear buffers | 09:59 |
| freemangordon | *non-linear | 10:00 |
| tmlind | hmm | 10:00 |
| tmlind | so are you saying it's a omapdrm bug? | 10:00 |
| freemangordon | do you have https://github.com/maemo-leste/droid4-linux/commit/f56836db3ec4210c5cfaf40fa721a6e21cd7730e | 10:01 |
| tmlind | i don't understand why mesa could not just manage the /dev/dri directly, why is the libdbm needed there at all? | 10:01 |
| tmlind | freemangordon: no i don't have that patch yet, sounds like i should try with it | 10:01 |
| freemangordon | yes | 10:02 |
| tmlind | ok | 10:02 |
| freemangordon | tmlind: also, make sure to revert 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be and get fences patch | 10:03 |
| freemangordon | or, just use leste kernel tree :) | 10:03 |
| tmlind | yup, 6dd1aad1d0c4716944098b7b0f2abdd3a26cc0be should not be needed any longer at all after your fix | 10:03 |
| freemangordon | mhm | 10:03 |
| freemangordon | I wonder if we shall create a new branch/repo with all those obsolete patches not applied on the first place | 10:04 |
| tmlind | yup let's do that after v5.16 is tagged | 10:04 |
| freemangordon | ok, deal | 10:05 |
| tmlind | and backport your two fixes | 10:05 |
| freemangordon | backport? thay are done against 5.15 :) | 10:05 |
| freemangordon | also, I think they are more than two | 10:05 |
| freemangordon | at least 3 in omapdrm and 2 in pvr | 10:06 |
| tmlind | ok well backport as in these won't hit the mainline kernel until at v5.16-rc1 :) | 10:06 |
| freemangordon | ah, yeah | 10:06 |
| freemangordon | 5.17-rc1 I guess | 10:06 |
| freemangordon | anyway, this is not important | 10:06 |
| tmlind | i need to also update my pending omapdrm fix, and then we need to make sure the vblank patch does not cause performance loss at least for xorg | 10:07 |
| tmlind | ah right v5.17-rc1 :) too many tags. | 10:07 |
| tmlind | . | 10:07 |
| freemangordon | tmlind: I think someone shall spend time on TE support in omapdrm | 10:07 |
| freemangordon | this will make vblank patch obsolete too | 10:07 |
| freemangordon | as it is a kind of hack IIUC | 10:07 |
| tmlind | afaik te is not available on droid4 | 10:08 |
| freemangordon | sure it is | 10:08 |
| tmlind | where do you see it? there's no te gpio | 10:08 |
| freemangordon | I looked at android vendor code | 10:08 |
| freemangordon | yes, there is no gpio | 10:08 |
| freemangordon | but that does not mean there is no TE | 10:08 |
| freemangordon | sec | 10:08 |
| tmlind | note that the stock kernel has support for multiple displays where some may have te | 10:09 |
| freemangordon | yes, I know | 10:10 |
| tmlind | something would need to produce a te interrupt from the panel, right? | 10:10 |
| freemangordon | yes | 10:10 |
| freemangordon | and this is DSI controller ;) | 10:10 |
| tmlind | oh | 10:10 |
| freemangordon | gimme a minute to find TRM page for you | 10:11 |
| tmlind | yup if the dsi te interrupt works, no need for the vblank emulation | 10:11 |
| freemangordon | according to board_mapphone.c it works | 10:12 |
| tmlind | so for v5.17-rc1 based branch, i want to fix up " | 10:12 |
| tmlind | drm/omap: Fix shmem write-combined buffer handling" patch a bit, there's another cosmetic fix related to it | 10:12 |
| tmlind | let's leave out the vblank for now then | 10:12 |
| freemangordon | do we need that still? IIRC this was causing N900 to not boot | 10:13 |
| tmlind | hmm i think i fixed it for n900 | 10:13 |
| freemangordon | hmm, ok | 10:13 |
| freemangordon | we'll see | 10:13 |
| tmlind | afaik droid4 won't work with the paging code without it | 10:13 |
| tmlind | needs to be verified again sounds like though :) | 10:14 |
| freemangordon | see "10.3.4.4.9.2 Tearing Effect" | 10:15 |
| freemangordon | "There are two types of TE triggers:..." | 10:15 |
| freemangordon | mapphones use DSI PHY TE trigger | 10:15 |
| freemangordon | but I guess panel has to be programmed correctly for this to work | 10:16 |
| freemangordon | I tried to fix support in omapdrm (to see that TE intr is generated), but it was not generated | 10:17 |
| freemangordon | but I think it was not my code at fault (I was basically setting couple of bits in DSI regs, the same way vendor kernel does it), but lack of some magic commands that panel driver issues in vendor kernel | 10:18 |
| freemangordon | but, I won;t have time to look at that soon | 10:18 |
| tmlind | ok cool, i'll take a look at that | 10:22 |
| tmlind | hmm we have something with DSI_CATCH_MISSING_TE for that | 10:23 |
| freemangordon | lemme see if I stashed the changes | 10:23 |
| freemangordon | yes I did :) | 10:23 |
| tmlind | maybe we don't have dsi_te0 pin muxed right.. | 10:24 |
| freemangordon | we don;t need it at all | 10:25 |
| freemangordon | IIUC | 10:25 |
| freemangordon | this is needed only if you use te gpio, iiuc | 10:25 |
| tmlind | ok | 10:26 |
| freemangordon | tmlind: https://pastebin.com/Uff5A9QF | 10:26 |
| tmlind | ok, did you get the te to trigger? | 10:27 |
| freemangordon | no | 10:28 |
| tmlind | heh | 10:28 |
| freemangordon | but, if you look at vendor kernel panel code, there are lots of commands send to the panel itself | 10:28 |
| tmlind | yeah | 10:28 |
| tmlind | i'll take a look, seems i can test this with my rack based setup easily | 10:28 |
| tmlind | to get te to trigger that is | 10:29 |
| tmlind | need to get going now though, ttyl | 10:29 |
| freemangordon | and I suspect there is where the dog is buried in | 10:29 |
| freemangordon | ttyl | 10:29 |
| freemangordon | omg, those guys are crazy! SGX blobs libdbm does: | 20:42 |
| freemangordon | realloc(ptr, handle * sizeof(handle)); | 20:42 |
| freemangordon | obviously the want to track all GEM handles they use, but the do so by allocating array of size of biggest handle number! | 20:43 |
| freemangordon | how hard is to use lists, dammit | 20:43 |
| freemangordon | or even hash tables, if we are to track 1000s of BOs | 20:44 |
| Wizzup | heh | 20:44 |
| Wizzup | I'm going to look at the pine64 kernel stuff again now | 20:44 |
| Wizzup | I'll maybe just rename and see what happens | 20:44 |
| freemangordon | hmm, something wrong with 'y' symbol on my kbd? | 20:44 |
| freemangordon | y y y | 20:45 |
| freemangordon | looks fine :) | 20:45 |
| freemangordon | Wizzup: don;t really know what to do with the issues we have with omapdrm | 20:45 |
| freemangordon | one one hand I don;t want to waste any more time on that | 20:46 |
| freemangordon | on the other - it crashes | 20:46 |
| freemangordon | and I know why | 20:46 |
| Wizzup | is this the fragmentation problem? | 20:46 |
| freemangordon | yes | 20:46 |
| freemangordon | also, somehow we have issue on n900, that in theory we should not have | 20:47 |
| freemangordon | I don;t think scanout (so CMA) buffers are reallocated at all | 20:47 |
| freemangordon | so, why we hit that CMA error is not clear to me | 20:47 |
| freemangordon | Wizzup: a simple hack on d4 will solve the issue most-probably | 20:48 |
| freemangordon | like: never allocate buffers from DMM | 20:49 |
| uvos | i mean its any buffer right | 20:49 |
| freemangordon | yes | 20:49 |
| uvos | (gets allocated on dmm on current omapdrm) | 20:49 |
| freemangordon | *every | 20:49 |
| uvos | but dident on 5.11 | 20:49 |
| uvos | so bisect maybe | 20:49 |
| freemangordon | besides rotated scanout | 20:49 |
| uvos | and complain to whomever did the commit | 20:49 |
| freemangordon | uvos: no need | 20:49 |
| freemangordon | this needs to be fixed IMO | 20:50 |
| freemangordon | but, the fix should be smart, like: allocate all scanout buffers from TILER | 20:50 |
| uvos | sure but im saying its a new problem introduced in between 5.11 and 5.15 indpendantly from sgx into omapdrm, aka mainline | 20:50 |
| uvos | so complaining to the author seams resonable | 20:50 |
| freemangordon | it is not that simple, as part of the solution in 5.11 are the so-called 'omapdrm' hacks | 20:51 |
| uvos | ok | 20:51 |
| freemangordon | so upstream code was broken | 20:51 |
| uvos | ok | 20:51 |
| uvos | i gues your quick fix is just reapplying the hack | 20:52 |
| freemangordon | also, I see a general issue in GBM BO stuff/DRM dumb buffers | 20:52 |
| freemangordon | we have various flags when creating GBO BOs (like GBM_BO_USE_SCANOUT etc) | 20:52 |
| freemangordon | however, there is no way those to be passed to kernel | 20:53 |
| uvos | ok | 20:53 |
| freemangordon | drm_mode_create_dumb has flags member | 20:53 |
| freemangordon | but: noone uses that | 20:53 |
| uvos | ok | 20:53 |
| uvos | so how about: reapply/reimplement old hack, complain about problem on omap ml, and drm ml, do something else, home someone fixes the problem by the time your done with "sonehing else", otherwise look at problem again. | 20:54 |
| uvos | s/home/hope | 20:54 |
| freemangordon | so, in order to fix dri3 on pvr, I will have to RE libdbm and replace DRM_IOCTL_MODE_CREATE_DUMB with omap_bo_create_xxx I wanted to get rid of | 20:55 |
| freemangordon | noone will fix it, as obviously noone uses that for anything sane besides us | 20:55 |
| freemangordon | if I complain to Tony, I can bet he will start talking about omapdrm not being general memory allocator etc | 20:57 |
| freemangordon | sorry, to Tomy | 20:57 |
| freemangordon | OTOH we are using blobs that (abuse)use omapdrm - there is a check if fd of drm device being passed is fd of omapdrm | 20:58 |
| freemangordon | -22 if not | 20:58 |
| freemangordon | -19 actually | 20:59 |
| freemangordon | "OS error code 19: No such device" | 20:59 |
| freemangordon | I mean: this is full with hacks all over the place :( | 20:59 |
| uvos | this should not be that suprising | 21:00 |
| freemangordon | I was hoping at least open parts to be looking better | 21:00 |
| freemangordon | but actually they are worse | 21:00 |
| freemangordon | I hate to tell it, but blobs/pvr driver follow specs way better than open parts | 21:01 |
| freemangordon | will exit rant mode soon, I promise :) | 21:01 |
| sicelo | :-) | 21:01 |
| freemangordon | ok, plan for tomorrow: hack omapdrm to *not* allocate DMM buffers, unless those are scanout | 21:02 |
| freemangordon | hack DDX to always allocate scanout buffers as TILER buffers | 21:03 |
| freemangordon | I hope this will fix it at least on d4 | 21:04 |
| Wizzup | freemangordon: understood | 21:18 |
| Wizzup | freemangordon: maybe we can get tomi involved somehow, since we seem to be one of the more sophisticated users that also actually use powervr | 21:19 |
| Wizzup | tmlind: did we send tomi a droid4, do you remember? | 21:19 |
| freemangordon | that would be great, at least for discussing on what would be accepted upstream and what not | 21:24 |
| Wizzup | freemangordon: I don't know how to do it, maybe we make a video of the current state and maybe link that on the ml or something | 21:31 |
| freemangordon | what do you mean by "current state"? | 21:31 |
| Wizzup | droid4 -devel with maemo | 21:33 |
| freemangordon | ok, but what to show there? the progress? | 21:34 |
| freemangordon | I don't understand the point, please elaborate | 21:34 |
| Wizzup | I just mean show off how well it works now, and maybe he will be interested in solving the existing problems | 21:34 |
| freemangordon | ah, ok | 21:34 |
| Wizzup | just to motivate or grab attention, I don't know :) | 21:34 |
| freemangordon | yeah, why not | 21:35 |
| freemangordon | will you do that? Your d4 is way more in "end user" state than mine | 21:35 |
| Wizzup | yeah, maybe we can just make one for the news update and include this | 21:36 |
| freemangordon | you do the PR stuff, I will do problems description in a follow-up letter | 21:36 |
| freemangordon | yeah, why not | 21:36 |
| freemangordon | having 5.15 i snews, no? | 21:36 |
| Wizzup | I was kind of waiting for this to hit -stable to do news post, but maybe we can just tout about it when it is in -devel too | 21:36 |
| Wizzup | freemangordon: yes, we will have news update soon | 21:36 |
| freemangordon | ok, lets see if I will be able to fix DMM issues tomorrow | 21:37 |
| Wizzup | ok, I hope to have a python or C telepathy client for irc or sms before I go to sleep | 21:37 |
| Wizzup | command line but still | 21:37 |
| freemangordon | and RE libdbm today | 21:38 |
| uvos | implementing a sphone module for its chat/sms system is probubly less than a command line client from scratch | 22:13 |
| uvos | Wizzup: just saying :P | 22:13 |
| uvos | *less work | 22:13 |
| Wizzup | it's more about using tp api than creating a cli prog | 22:20 |
| Wizzup | ofc any cli thing I make is just to test | 22:20 |
| uvos | sure i know | 22:20 |
| jk_ | hello Leste's! :) | 23:22 |
| jk_ | great work! really! I admire all the people involved behind the scenes in and for this free and ethical platform! | 23:23 |
| freemangordon | Wizzup: I think I have a patch for DMM fragmentation, unfortunately batter went flat and I am unable to charge it - as soon as h-d starts, device shuts down because of low battery despite being on fastcharger :( | 23:24 |
| freemangordon | jk_: :) | 23:24 |
| jk_ | I have a Droid4 and it is looking pretty ripe! got leste on it arround may 2019 | 23:24 |
| Wizzup | freemangordon: I can apply and test if you want, if you boot with cable plugged in I think you should get the charge-mode? | 23:25 |
| Wizzup | jk_: hi :) | 23:25 |
| jk_ | it helped me go deeper in the command-line. I have learned so much! | 23:25 |
| freemangordon | Wizzup: charged through android, it told me 15% | 23:25 |
| freemangordon | yeah, not it booted | 23:26 |
| Wizzup | jk_: the next update will contain a lot more cool stuff :) | 23:27 |
| freemangordon | yeah, this is better :) https://pastebin.com/gnEqy4jZ | 23:28 |
| freemangordon | Wizzup: going to push, please make new kernel release in few minutes | 23:28 |
| jk_ | Wizzup: that's great! | 23:28 |
| jk_ | so, I have one little problem with my Droid4: using a USB-DAC. ometimes it works, but most of the time the device crashes when I plug it in | 23:29 |
| Wizzup | freemangordon: ok, will do | 23:31 |
| Wizzup | jk_: so this is usb host mode with a usb audio card, do I understand correctly? | 23:31 |
| jk_ | yes | 23:32 |
| jk_ | and the card is an ODAC or "objective DAC" an open hardware device | 23:33 |
| jk_ | ... creative commons license, I believe | 23:33 |
| Wizzup | I have not toyed around that much with usb host mode on the droid4 I have to admit, it is possible that our new 5.15 based kernel will work better | 23:33 |
| Wizzup | I think the best thing to do is test that when we push it out (real soon) and then if it still crashes see if you can find anything in /var/log/ | 23:34 |
| freemangordon | Wizzup: pushed | 23:34 |
| Wizzup | freemangordon: I'll do tag and rebuild | 23:34 |
| freemangordon | thanks! | 23:34 |
| freemangordon | please test and report if it still crashes | 23:34 |
| jk_ | Wizzup: ok, fair enough, I can wait for that :) | 23:34 |
| freemangordon | hmm, device turned off again :( | 23:35 |
| Wizzup | freemangordon: will do, it might take 1-2 days for me to report on that, although I can try some stress tests | 23:35 |
| jk_ | I am using the DAC designed by this guy: https://nwavguy.blogspot.com/ | 23:35 |
| Wizzup | freemangordon: there is code in mce now to shut down on low battery afaik, maybe you are hitting that | 23:35 |
| jk_ | oh, yes... for completion: DAC = digital to analog converter | 23:36 |
| Wizzup | jk_: cool, what are you using it for btw? | 23:36 |
| Wizzup | yeah I know :) | 23:36 |
| freemangordon | yeah, seems this is what I am hitting | 23:36 |
| freemangordon | but, battery is @ 20 % | 23:36 |
| Wizzup | freemangordon: should not happen if you keep cable plugged in, right? | 23:36 |
| freemangordon | and device connected on charger | 23:36 |
| freemangordon | mhm | 23:36 |
| Wizzup | I don't think it should trigger then | 23:36 |
| Wizzup | uvos^^ | 23:36 |
| Wizzup | freemangordon: are you sure you're hitting this? that should be noted in /var/log I think | 23:37 |
| freemangordon | hmm, android shows 5% | 23:37 |
| Wizzup | mce is based on voltage I think | 23:37 |
| freemangordon | well, cannot boot now | 23:37 |
| Wizzup | not upower reporting | 23:37 |
| Wizzup | new kernel is building | 23:37 |
| freemangordon | will let it charge for a while | 23:37 |
| Wizzup | btw, my plan for today/tomorrow is to at least get the pine kernel and ofono stuff done, and the tp test client | 23:38 |
| Wizzup | I really hope we can get enunez to help us :) | 23:38 |
| jk_ | the DAC? for supreme quality music ^^ ... just a month ago i discovered the pianobar package which is a pandora-radio client. and I am a pandora subscriber... eventhough it is only available in the US and I am in Germany, I can Torify it and use my old account that I had in 2004 while in my hometown in Mexico | 23:38 |
| Wizzup | heh :D | 23:38 |
| freemangordon | sounds complicated :) | 23:38 |
| jk_ | so, using the console to listen to online radio leaves the CPU and MEM pretty low, and that's the future! | 23:39 |
| Wizzup | how long can you do that on battery? | 23:39 |
| freemangordon | well, on leste we are already low on MEM and CPU, even with GUI running IMO | 23:39 |
| jk_ | battery? well, long enough, one hour or two. I have not exhausted it yet... could do a full test once the DAC works ^^ | 23:40 |
| Wizzup | I think probably usb host uses quite some power | 23:41 |
| jk_ | freemangordon: yeah! that's amazing! | 23:41 |
| Wizzup | I can listen to music on leste for ~13 hours or so on a full battery with mpv | 23:41 |
| freemangordon | 5.15? | 23:41 |
| jk_ | yeah, 5V... some Watts... but there are hubs with charging ports! | 23:41 |
| Wizzup | freemangordon: yes | 23:42 |
| Wizzup | jk_: yes, I wonder if that works | 23:42 |
| jk_ | Wizzup: damn! that's a good quota! | 23:42 |
| Wizzup | yeah wondering if we can get that up further if we make the audio buffer larger (if at all possible) so that device can sleep until the buffer is played back | 23:43 |
| Wizzup | but no idea how that actually works :p | 23:43 |
| jk_ | Wizzup: it should hehe, there are also some special OTG cables with power input and USB host... i think some resistor is builtin to deal with the frequencies or something like that. I saw a DIY video tutorial once, but I went for a ready one from ebay | 23:43 |
| jk_ | AND... there is this dock: https://i.ytimg.com/vi/mehKi6-tVYE/maxresdefault.jpg | 23:45 |
| uvos | jk_: hmm usb host works fine for me | 23:45 |
| uvos | i use it often to use a kbd with bionic | 23:45 |
| uvos | freemangordon: this is becasue charge mode is currently not enabled by default | 23:45 |
| uvos | what should happen is with cable plugged in you enter charge mode untill the user presses power and the battery is charged enough to boot fully | 23:46 |
| uvos | the battery percentage is a total lie on d4 ignore it btw | 23:46 |
| uvos | https://github.com/maemo-leste/mapphone-kexecboot-config/pull/1 fixes this problem | 23:47 |
| uvos | (by enableing charge mode and making all this work as intended) | 23:47 |
| freemangordon | uvos: maybe there is some issue with the kernel I boot, batter icon does not animate | 23:48 |
| Wizzup | uvos: oh yeah let me take a look at the PRs in a moment | 23:48 |
| freemangordon | and it does not say it is charging | 23:48 |
| Wizzup | freemangordon: upower not updating with charge state is a recent issues with one of uvos new patches | 23:48 |
| Wizzup | as in, since last week since I pulled the patches | 23:49 |
| freemangordon | ah | 23:49 |
| jk_ | uvos: oh! about the battery | 23:49 |
| Wizzup | freemangordon: but it in general makes charging more stable | 23:49 |
| freemangordon | but, does it charge? | 23:49 |
| uvos | freemangordon: Wizzup: yeah not sure about that one | 23:49 |
| jk_ | uvos: yes, host works, but this DAC doesn't | 23:49 |
| uvos | Wizzup: udev and sysfs report the state correctly | 23:49 |
| uvos | idk why udev dosent | 23:49 |
| freemangordon | as I bootd @ 46% battery | 23:49 |
| freemangordon | now it is 43@ | 23:49 |
| freemangordon | *42 | 23:49 |
| uvos | its a total lie | 23:49 |
| uvos | forget it | 23:49 |
| freemangordon | :) | 23:49 |
| uvos | unless the device saw full charge that boot | 23:50 |
| uvos | it dosent know | 23:50 |
| freemangordon | oh, now it started to move! | 23:50 |
| freemangordon | WTF? | 23:50 |
| freemangordon | anyways | 23:50 |
| uvos | its the refresh intervall | 23:50 |
| freemangordon | uvos: see pastebin ^^^ with dmm patch | 23:50 |
| uvos | so for some reason upower dosent pickup the uevent | 23:50 |
| freemangordon | this is with several windows opened | 23:50 |
| uvos | but it polls at soem interval | 23:50 |
| Wizzup | uvos: if udev doesn't then it's a kernel problem I think | 23:50 |
| uvos | so it picks it up later | 23:50 |
| uvos | udev dose | 23:50 |
| uvos | its also in uevent | 23:51 |
| Wizzup | uvos: maybe you are just missing a notifier then, or upower doesn't understand the notified | 23:51 |
| freemangordon | BTW this DMM/TILER patch should also fix ants problem | 23:51 |
| Wizzup | we fixed this for the n900 some time ago | 23:51 |
| Wizzup | freemangordon: is that the random small corruption? | 23:51 |
| Wizzup | (in corners) | 23:51 |
| uvos | no idea i have to check the diff in the events | 23:51 |
| freemangordon | yes | 23:51 |
| Wizzup | cool | 23:51 |
| Wizzup | uvos: ok, I can try to help figure it out later if you want, but not atm | 23:51 |
| jk_ | Wizzup: the ~13 hours mpv-play is with local music, local files? with wireless off? | 23:52 |
| uvos | Wizzup: i think its soem timeing issue | 23:53 |
| uvos | since it picks it up sometimes | 23:53 |
| uvos | and after the patch | 23:53 |
| uvos | the usb power plugin comes some time before the chargeing status notification | 23:53 |
| uvos | before they came at the same time | 23:53 |
| uvos | so maybe upower checks battery state when it gets a usb plug in | 23:53 |
| uvos | and the battery isent charging yet | 23:54 |
| uvos | (because of the slow ramp) | 23:54 |
| uvos | just a theory | 23:54 |
| Wizzup | uvos: quite possible | 23:54 |
| Wizzup | jk_: local files yes | 23:55 |
| Wizzup | jk_: it might be less, like 8 hours, depending on how good your battery is | 23:55 |
| Wizzup | jk_: and that is using the normal hp port | 23:55 |
| uvos | Wizzup: btw if you rebuild the kernel again | 23:55 |
| uvos | Wizzup: please drop the fbdev patch | 23:55 |
| uvos | Wizzup: to see if it has power implications like freemangordon suggests | 23:55 |
| uvos | we dont need it as of newest charge mode after all | 23:56 |
| * freemangordon is zzz | 23:56 | |
| freemangordon | night guys! | 23:56 |
| Wizzup | gn | 23:56 |
| Wizzup | uvos: I think if it did we would see it in the wakeups | 23:56 |
| jk_ | Wizzup: excellent! go Leste! :) | 23:57 |
| Wizzup | :) | 23:57 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
