uvos | ugh | 00:10 |
---|---|---|
uvos | the maemo volume buttons switch between portrait and landscape | 00:10 |
uvos | without a config option | 00:11 |
uvos | terrible ux | 00:11 |
uvos | first rule of buttons: muscle memory works if they dont change function | 00:11 |
Wizzup | uvos: who intercepts this then? | 00:12 |
Wizzup | uvos: on the n900 this works really well fwiw | 00:12 |
uvos | android used to do this | 00:13 |
uvos | and i hated it | 00:13 |
uvos | anyhow | 00:13 |
uvos | its implmented in the volume applet | 00:13 |
uvos | btw the volume applet should work fine with the current ucm setup | 00:13 |
uvos | you should only have to change /usr/share/maemo-statusmenu-volume/volume_steps_update | 00:14 |
uvos | to point to the correct sink | 00:14 |
uvos | unfortionatly it dosent work atm | 00:14 |
uvos | but that just looks like a pa api change | 00:14 |
Wizzup | wait you have volume applet working? | 00:14 |
uvos | yes | 00:15 |
Wizzup | let me send you some beers :) | 00:15 |
uvos | heh | 00:15 |
Wizzup | with our existing pa setup? | 00:15 |
uvos | yes | 00:15 |
uvos | its just a tiny change | 00:15 |
uvos | and that config change | 00:15 |
uvos | but let me clean it up | 00:15 |
Wizzup | ok | 00:15 |
uvos | also the f7 f8 thing.. | 00:16 |
uvos | i just replaced that atm | 00:16 |
Wizzup | yeah, let's not get into that now but well noted | 00:16 |
uvos | heh | 00:16 |
uvos | what you dont want me flaming for 30 minutes about keymappings? | 00:16 |
Wizzup | well we've gone over that stuff a few times and realised that it is fubar no matter | 00:17 |
uvos | not really | 00:17 |
uvos | but ok | 00:17 |
uvos | not now | 00:17 |
Wizzup | :) | 00:17 |
uvos | correct sink is alsa_output.0.HiFi__hw_Audio_0__sink btw | 00:19 |
uvos | (should be on all devices) | 00:19 |
uvos | (except n900) | 00:19 |
Wizzup | we might need to make volume_steps_update a leste-config file then, or figure out how to deal with it | 00:20 |
Wizzup | maybe if we give n900 UCM file | 00:20 |
uvos | also not sure how to deal with hdmi audio | 00:21 |
uvos | the thing is somewhat unfortionatly hardcoded for 2 channels | 00:21 |
uvos | droid 4 might have up to 6 | 00:21 |
Wizzup | I plan to worry about hdmi and external screens quite a bit later down the road | 00:30 |
Wizzup | I'd have to check how the n900 deals with it, but I suspect it's probably on the headphone mapping | 00:30 |
uvos | sure | 00:30 |
Wizzup | (since on the n900 the external screen clone is through the hp jack) | 00:30 |
uvos | its also just 2 channels | 00:30 |
uvos | so theres nothing to handle | 00:30 |
Wizzup | hm, what other channels? | 00:30 |
uvos | n900 dosent have otg and dosent have hdmi | 00:31 |
uvos | ergo no audio output > 2 channels is possible | 00:31 |
uvos | ergo nokia dident care | 00:31 |
Wizzup | right | 00:32 |
Wizzup | my point was mostly that 'how do I control hdmi audio when I use an external screen, possible not even cloned' is not high on my priority/worry list | 00:32 |
Wizzup | anyhow I am happy currently because I think I understand telepathy well enough now | 00:32 |
uvos | granted | 00:32 |
Wizzup | of course my confidence will tank when I start writing the code, but I think I'll get through it | 00:33 |
Wizzup | :p | 00:33 |
Wizzup | freemangordon: you probably meant https://wiki.maemo.org/N900_Mission_Control | 00:37 |
Wizzup | sicelo: fwiw mc-tool is part of libmissioncontrol-utils | 00:38 |
uvos | he allready said that | 00:39 |
uvos | to you | 00:39 |
Wizzup | ok, must have missed it :) | 00:39 |
Wizzup | ah, I see it now | 00:40 |
Wizzup | hm, maybe we need to set tp ring to 'always on' as opposed to 'when requested' | 00:59 |
Wizzup | anyway, time for some sleep | 01:00 |
mighty17[m] | `configure: error: Package requirements (sgx-ddk-um randrproto renderproto videoproto xextproto) were not met:` | 05:47 |
mighty17[m] | `Package 'sgx-ddk-um', required by 'virtual:world', not found` | 05:47 |
mighty17[m] | i made sgx-ddk-um-dev and xorgproto-dev as well but still :( | 05:47 |
mighty17[m] | seems like files are in diff packages for alpine, so im asking what does it actually need | 05:50 |
mighty17[m] | commented out that line, pretty sure i have deps but now i get | 06:49 |
mighty17[m] | `In file included from drmmode_display.c:32:` | 06:49 |
mighty17[m] | `../config.h:4:10: fatal error: xorg-server.h: No such file or directory` | 06:49 |
mighty17[m] | https://pkgs.alpinelinux.org/contents?file=xorg-server.h&path=&name=&branch=edge i do have it | 06:58 |
mighty17[m] | Nvm fixed it :D will push to my fork soon | 07:34 |
freemangordon | uvos: f7<->f8 on rotation is very handy, it feels unnatural if you have to press lower button to increase volume(in portrait) or left button to increase (landscape) | 07:58 |
freemangordon | please restore that if you have removed it | 07:58 |
mighty17[m] | reverted https://github.com/maemo-leste/xf86-video-omap/commit/2308cdc7f42a3760b3fa2642c6a8011bd3d71b9a coz i dont have sgx-ddk-um-dev working | 08:03 |
mighty17[m] | and now it fails with `/usr/lib/gcc/armv7-alpine-linux-musleabihf/11.2.1/../../../../armv7-alpine-linux-musleabihf/bin/ld: cannot find -lsrv_um` | 08:03 |
mighty17[m] | `/usr/lib/gcc/armv7-alpine-linux-musleabihf/11.2.1/../../../../armv7-alpine-linux-musleabihf/bin/ld: cannot find -lpvr2d` | 08:03 |
mighty17[m] | freemangordon: https://github.com/maemo-leste/xf86-video-omap/commit/a0a47a73599c41346a6402d1d303f39fc664aac2 seems to be added by you, any clues | 08:08 |
freemangordon | what do you mean? | 08:09 |
freemangordon | ah, -lpvr2d? | 08:10 |
mighty17[m] | ` omap_pvr_drv_la_LIBADD = @XORG_LIBS@ -lsrv_um -lpvr2d` | 08:10 |
mighty17[m] | ye | 08:10 |
freemangordon | if you revert that, there will be no HW blit accelleration | 08:11 |
freemangordon | and in general this is not well tested soon | 08:11 |
mighty17[m] | im not reverting that, im reverting ` Depend on sgx-ddk-um-dev ` | 08:11 |
freemangordon | ah | 08:11 |
mighty17[m] | so that makes ` omap_pvr_drv_la_LIBADD = @XORG_LIBS@ @PVRSGX_LIBS@` -> ` omap_pvr_drv_la_LIBADD = @XORG_LIBS@ -lsrv_um -lpvr2d` after revert | 08:12 |
freemangordon | well, those 2 libs a re part of binary blobs package | 08:12 |
freemangordon | mhm | 08:12 |
mighty17[m] | <mighty17[m]> "and now it fails with `/usr/lib..." <- but it fails with this | 08:12 |
freemangordon | mighty17[m]: you need libsrv_um.so and libpvr2d.so | 08:13 |
mighty17[m] | freemangordon: source? | 08:14 |
freemangordon | those are in SGX binary blobs | 08:14 |
mighty17[m] | ah sgx-ddk-um | 08:15 |
freemangordon | mhm | 08:15 |
mighty17[m] | i wonder if i should just switch to your sgx-ddk-um | 08:15 |
freemangordon | better do | 08:16 |
freemangordon | as now I am REing dbm from there | 08:16 |
freemangordon | hopefully it will start supporting TILER allocated buffers and whatnot | 08:16 |
mighty17[m] | :D | 08:17 |
freemangordon | instead of blindly allocation dumb scanout only buffers as of now | 08:17 |
freemangordon | *allocating | 08:17 |
sicelo | I also find the vol up/down switching useful | 08:17 |
* mighty17[m] has no clue what that means, but is excited | 08:17 | |
freemangordon | yeah, we'll have that ;) | 08:17 |
freemangordon | mighty17[m]: or, even better, as we said - switch to leste :p | 08:18 |
mighty17[m] | hehe | 08:18 |
mighty17[m] | it'd be preferable that the work is used on all distros :P | 08:18 |
mighty17[m] | freemangordon: https://paste.debian.net/1226567/ mesa issue? | 09:40 |
mighty17[m] | https://paste.debian.net/1226568/ also is xf86-video-omap packaged properly? | 09:42 |
mighty17[m] | https://paste.debian.net/1226569/ this is without modesetting | 09:44 |
freemangordon | mighty17[m]: https://pastebin.com/v9SBparB | 09:49 |
freemangordon | and yes, looks like it is packaged properly | 09:49 |
freemangordon | but, you need to create xorg.conf for it | 09:50 |
freemangordon | see pastebin ^^^ | 09:50 |
mighty17[m] | Will try, tysm! | 09:53 |
uvos | freemangordon: i dident remove it | 11:31 |
uvos | freemangordon: i did make it a config option | 11:31 |
mighty17[m] | welp :( | 11:32 |
mighty17[m] | <freemangordon> "but, you need to create xorg...." <- `[ 101.485] (EE) Failed to load /usr/lib/xorg/modules/drivers/omap_drv.so: Error relocating /usr/lib/xorg/modules/drivers/omap_drv.so: InitPowerVREXA: symbol not found` | 11:32 |
uvos | must not be linked to pvr um | 11:41 |
freemangordon | uvos: no, that's another issue | 11:41 |
freemangordon | InitPowerVREXA is in pvr EXA module | 11:42 |
freemangordon | mighty17[m]: could you move omap_pvr_drv.so out of modules directory and retry? | 11:42 |
mighty17[m] | as in? | 11:44 |
freemangordon | mv omap_pvr_drv.so /root for example | 11:44 |
freemangordon | move it to another dir | 11:44 |
mighty17[m] | oh ok | 11:47 |
Wizzup | mighty17[m]: why revert `Depend on sgx-ddk-um-dev ` ? just make sure you have the pc file | 11:52 |
Wizzup | I made one | 11:52 |
mighty17[m] | Wizzup: i dont have it on alpine | 11:52 |
Wizzup | then make it! | 11:52 |
Wizzup | otherwise things won't work | 11:52 |
Wizzup | you need -everything- | 11:52 |
Wizzup | I am talking about the .pc file | 11:52 |
Wizzup | but if you think it's working, then ignore, just waking up | 11:53 |
Wizzup | it just doesn't seem like a good idea to remove stuff from autotools that we add | 11:53 |
Wizzup | they aren't just checks, they also translate to CFLAGS and linker actions | 11:53 |
freemangordon | correct | 11:55 |
mighty17[m] | <freemangordon> "mighty17: could you move..." <- https://paste.debian.net/1226595/ | 12:34 |
mighty17[m] | oh damn | 12:35 |
mighty17[m] | sorry wait | 12:35 |
mighty17[m] | freemangordon: https://paste.debian.net/1226598/ | 12:38 |
freemangordon | mighty17[m]: it is not correctly compiled | 12:39 |
mighty17[m] | i suppose i'll just use your sgx-ddk-um then | 12:40 |
freemangordon | no | 12:40 |
mighty17[m] | hm? | 12:40 |
freemangordon | it is not related | 12:40 |
mighty17[m] | oh ok, so wdym by not correctly compiled? | 12:41 |
freemangordon | your ld should not try to resolve InitPowerVREXA and fail if it does not find it | 12:41 |
freemangordon | this is more or less weak symbol | 12:41 |
mighty17[m] | freemangordon: so smth wrong in my xf86-video-omap right? | 12:44 |
freemangordon | yeah | 12:44 |
freemangordon | mighty17[m]: objdump -T /usr/lib/xorg/modules/drivers/omap_drv.so | grep EXA | 12:44 |
mighty17[m] | `00000000 D *UND* 00000000 InitPowerVREXA` | 12:45 |
mighty17[m] | `00004894 g DF .text 00000008 OMAPEXAPTR` | 12:45 |
mighty17[m] | so its undefined? :o | 12:45 |
freemangordon | no, it is fine | 12:46 |
freemangordon | hmm | 12:46 |
freemangordon | same here: 00000000 D *UND*00000000 InitPowerVREXA | 12:46 |
freemangordon | the question is why loader on alpine insists on resolving that | 12:47 |
Wizzup | mighty17[m]: are you using our specific sgx ddk and also the .pc file? | 12:47 |
Wizzup | just to check | 12:47 |
mighty17[m] | only thing i changed was dependency sgx-ddk-um and bring back the header files | 12:47 |
freemangordon | Wizzup: the issue is not with sgx libs | 12:47 |
freemangordon | but with xorg | 12:47 |
mighty17[m] | Wizzup: nope, https://github.com/MightyM17/xf86-video-omap/ | 12:47 |
freemangordon | for some reason ld.so on alpine tries to resolve symbols on loading | 12:48 |
Wizzup | ok, then I'll let fmg handle it because I think it's much better to build it the way tested it | 12:48 |
mighty17[m] | musl issues? | 12:48 |
freemangordon | yeah | 12:48 |
mighty17[m] | ugh.. :/ | 12:48 |
Wizzup | also reverting the header commit is a bad idea, now you might even have wrong version | 12:48 |
mighty17[m] | Wizzup: well from where can i get header files then? | 12:49 |
mighty17[m] | omap5-sgx-ddk-um-linux ? | 12:49 |
freemangordon | Wizzup: for sure this shall be fixe, but that's not the issue he is hitting now | 12:49 |
freemangordon | mighty17[m]: from our -dev package | 12:49 |
mighty17[m] | me has to package that for alpine | 12:49 |
mighty17[m] | but even with that, this issue would come | 12:49 |
Wizzup | yes, we worked hard to package it all properly so that people could just mimick the packaging and make it all work | 12:49 |
mighty17[m] | can we just define InitPowerVREXA to 0 or smth garbage? | 12:50 |
* mighty17[m] > <@Wizzup:libera.chat> yes, we worked hard to package it all properly so that people could just mimick the packaging and make it all work | 12:50 | |
* mighty17[m] has no clue how deb works | 12:50 | |
freemangordon | mighty17[m]: no | 12:50 |
Wizzup | that's the nice thing about it: it's self contained so people can just do their packaging stuff and as long as it's the same, they know they did it right | 12:50 |
freemangordon | this is dynamic linker's job to resolve symbols when they are needed | 12:51 |
Wizzup | mighty17[m]: I also don't know how APKBUILDs work or other .spec files for rpm but I had no trouble figuring them out | 12:51 |
* Wizzup afk | 12:51 | |
freemangordon | and this seems to be broken, somehow | 12:51 |
mighty17[m] | looks like we should ask in #alpine? | 12:51 |
freemangordon | see https://www.openwall.com/lists/musl/2013/05/17/6 | 12:51 |
freemangordon | "musl intentionally does not support > lazy binding." | 12:52 |
mighty17[m] | ugh... | 12:52 |
freemangordon | so, go ask on #alpine :) | 12:52 |
freemangordon | I can't help with that one | 12:52 |
mighty17[m] | alrighty! thanks a lot | 12:53 |
freemangordon | hmm, wait | 12:53 |
freemangordon | mighty17[m]: could you move omap_pvr_drv.so back to modules firectory? | 12:53 |
freemangordon | and then do LD_PRELOAD=/usr/lib/xorg/modules/drivers/omap_pvr_drv.so Xorg | 12:54 |
mighty17[m] | ok trying that | 12:55 |
freemangordon | hmm, see https://patchwork.openembedded.org/patch/91717/ | 12:55 |
mighty17[m] | ah well i use lightDM | 12:55 |
freemangordon | maybe you should add: | 12:57 |
freemangordon | Section "Module" | 12:57 |
freemangordon | Load "omap_pvr_drv" | 12:57 |
freemangordon | EndSection | 12:57 |
freemangordon | to xorg.conf filke | 12:57 |
freemangordon | *file | 12:57 |
mighty17[m] | freemangordon: this didnt work | 12:58 |
freemangordon | mighty17[m]: it should be omap_pvr, not nomap_pvr_drv | 12:58 |
freemangordon | it should | 12:59 |
Wizzup | the part about dlclose() being a no-op is kinda painful | 12:59 |
freemangordon | wait, what did not work? | 12:59 |
freemangordon | LD_PRELOAD? | 12:59 |
mighty17[m] | musl is painful | 12:59 |
mighty17[m] | LD_PRELOAD | 12:59 |
freemangordon | switch to leste :p | 12:59 |
mighty17[m] | i added a sh to /etc/profile.d | 12:59 |
freemangordon | try module one | 12:59 |
freemangordon | it should work | 12:59 |
mighty17[m] | ok | 12:59 |
freemangordon | Section "Module" | 12:59 |
freemangordon | Load "omap_pvr" | 12:59 |
freemangordon | EndSection | 12:59 |
uvos | the switch to leste thing | 13:00 |
uvos | would probubly hold more watter | 13:00 |
uvos | if hildon was a xdg_session | 13:00 |
mighty17[m] | <freemangordon> "EndSection" <- `[ 31.353] (EE) Failed to load module "omappvr" (module does not exist, 0)` | 13:05 |
mighty17[m] | why does it say omappvr and not omap_pvr | 13:05 |
freemangordon | no idea | 13:05 |
freemangordon | maybe try with omap-pvr | 13:05 |
mighty17[m] | `[ 200.300] (EE) Failed to load module "omap-pvr" (module does not exist, 0)` | 13:06 |
freemangordon | hmm, wait | 13:06 |
freemangordon | yeah, it should be omap_pvr | 13:07 |
mighty17[m] | `Section "Module"` | 13:08 |
mighty17[m] | ` Load "omap_pvr"` | 13:08 |
mighty17[m] | `EndSection` | 13:08 |
freemangordon | this is crazy :( | 13:10 |
freemangordon | it seems xoreg strips underscores | 13:10 |
mighty17[m] | exactly what i was about to say | 13:10 |
mighty17[m] | so a sneaky rename/linking? :P | 13:11 |
freemangordon | mighty17[m]: please edit https://github.com/maemo-leste/xf86-video-omap/blob/757479eb1e3943cc2067bec3752f7757f7598a7d/src/omap_exa.h#L89 and remove underscore | 13:11 |
freemangordon | also https://github.com/maemo-leste/xf86-video-omap/blob/757479eb1e3943cc2067bec3752f7757f7598a7d/src/omap_exa_pvr.c#L1158 | 13:11 |
freemangordon | rebuild/reinstall | 13:11 |
mighty17[m] | oh damn | 13:11 |
mighty17[m] | alrighty | 13:12 |
mighty17[m] | <freemangordon> "rebuild/reinstall" <- `[ 196.864] (EE) Failed to load module "omappvr" (module does not exist, 0)` hm? | 13:37 |
mighty17[m] | so it didnt work at all? | 13:39 |
mighty17[m] | https://paste.debian.net/1226611/ | 13:41 |
freemangordon | mighty17[m]: do you have ldd /usr/lib/xorg/modules/omap_pvr_drv.so ? | 13:43 |
freemangordon | do you have /usr/lib/xorg/modules/omap_pvr_drv.so ? | 13:44 |
mighty17[m] | ldd? :P | 13:44 |
freemangordon | yeah, next thing to do | 13:44 |
mighty17[m] | `/usr/lib/xorg/modules/omap_pvr_drv.so` yes | 13:44 |
freemangordon | and what about ldd on it? | 13:44 |
mighty17[m] | freemangordon: you'll not like it https://paste.debian.net/1226612/ | 13:45 |
freemangordon | yeah, this will not work | 13:45 |
freemangordon | we have circular dependencies | 13:45 |
mighty17[m] | fun | 13:46 |
freemangordon | omap_drv wants symbols from omap_pvr_drv | 13:46 |
freemangordon | and omap_pvr_drv want symbols from omap_drv | 13:46 |
freemangordon | ask on #alpine or on #musl :) | 13:46 |
mighty17[m] | mhm | 13:47 |
mighty17[m] | i cant join alpine somehow | 13:47 |
mighty17[m] | i do have registered nick | 13:47 |
Wizzup | I'm waiting for the "don't use X" answer :) | 13:47 |
freemangordon | :D | 13:47 |
mighty17[m] | Wizzup: wayland works fine :P | 13:47 |
freemangordon | does it? | 13:47 |
freemangordon | please rotate to landscap[e and tell me what FPS is | 13:48 |
freemangordon | for glmark2, for example | 13:48 |
freemangordon | and then we can discuss "works fine" ;) | 13:48 |
uvos | es2_gears is the best benchmark for this | 13:49 |
Wizzup | parazyd: looks like most of our image builds are failing: https://phoenix.maemo.org/view/Images/job/leste-image-pinephone/82/console | 13:49 |
uvos | since it dosent take mutch time to render it frame | 13:49 |
uvos | *tis | 13:49 |
uvos | *its | 13:49 |
uvos | jeez | 13:49 |
freemangordon | yeah, but it is 300x300 window | 13:49 |
mighty17[m] | freemangordon: default is landscape :) | 13:49 |
freemangordon | and SW blit is not like 960x540 | 13:49 |
mighty17[m] | uvos: ok gimme a sec then | 13:49 |
freemangordon | mighty17[m]: doesn;t not matter | 13:49 |
uvos | freemangordon: resize the window then :P | 13:50 |
freemangordon | compare fps for native VS rotated orientation | 13:50 |
freemangordon | uvos: on gears? | 13:50 |
freemangordon | how? | 13:50 |
freemangordon | I know you can rotate, but resize? | 13:50 |
mighty17[m] | freemangordon: what benchmark do you want? | 13:50 |
uvos | freemangordon: just drag the window | 13:50 |
uvos | freemangordon: border | 13:50 |
uvos | freemangordon: like any window... | 13:50 |
uvos | freemangordon: hes using openbox | 13:51 |
uvos | or start i3 | 13:51 |
freemangordon | mighty17[m]: ok, do as uvos said | 13:51 |
mighty17[m] | gears? | 13:51 |
freemangordon | mhm | 13:51 |
freemangordon | but resize as much as you can | 13:51 |
uvos | and i3 as vm | 13:51 |
uvos | or maximise the window | 13:52 |
freemangordon | though I would prefer glmark --fullscreen | 13:52 |
freemangordon | but lets see gears first | 13:52 |
mighty17[m] | if it would work :P | 13:54 |
mighty17[m] | `Error: couldn't get an RGB, Double-buffered visual` | 13:54 |
freemangordon | works fine, yeah :p | 13:54 |
uvos | you dident run glxgears right | 13:55 |
freemangordon | why glx? | 13:55 |
freemangordon | it should be es2_gears | 13:55 |
uvos | because thats the error message it potsts | 13:55 |
uvos | on pvr | 13:55 |
uvos | `Error: couldn't get an RGB, Double-buffered visual` | 13:55 |
freemangordon | does not matter, we want es2_gears | 13:55 |
uvos | i know | 13:56 |
freemangordon | not glxgears | 13:56 |
uvos | im asking if mighty17[m] made this mistake... | 13:56 |
freemangordon | ah | 13:56 |
mighty17[m] | as in? | 13:56 |
Wizzup | I think we all need telepathy | 13:56 |
Wizzup | pun intended | 13:56 |
mighty17[m] | pvr-pathy | 13:56 |
uvos | mighty17[m]: what did you run | 13:56 |
mighty17[m] | glxgears | 13:57 |
uvos | right thats wrong | 13:57 |
uvos | glx _canot_ work on pvr | 13:57 |
uvos | you want es2gears | 13:57 |
mighty17[m] | then what should i do | 13:57 |
uvos | es2gears | 13:57 |
mighty17[m] | https://pkgs.alpinelinux.org/packages?name=*es2gears*&branch=edge fun | 13:58 |
freemangordon | mesa-tools-extra or somesuch is the package | 13:58 |
Wizzup | es2_gears for the record | 13:58 |
Wizzup | iirc | 13:58 |
freemangordon | or mesa-utils-extra | 13:58 |
freemangordon | yea | 13:58 |
freemangordon | it is with underscore | 13:59 |
freemangordon | but still unknown to alpine | 13:59 |
mighty17[m] | mesa-demos in alpine | 13:59 |
freemangordon | ok | 13:59 |
mighty17[m] | `samsung-espresso3g:~$ sudo apk search es2gears` | 13:59 |
uvos | Wizzup: no $ which es2gears /usr/bin/es2gears | 13:59 |
mighty17[m] | `mesa-demos-8.4.0-r1` | 13:59 |
Wizzup | uvos: weird | 13:59 |
freemangordon | oh, no underscore | 14:00 |
freemangordon | anyway | 14:00 |
freemangordon | mighty17[m]: you want es2gears_wayland | 14:00 |
mighty17[m] | `/usr/bin/es2gears_x11` well shit | 14:00 |
mighty17[m] | so thats out of question | 14:02 |
* Wizzup wishes there were golang bindings for telepathy im | 14:02 | |
uvos | why go | 14:02 |
uvos | alll of our frontends are c(++) | 14:02 |
mighty17[m] | glmark2 now? | 14:03 |
Wizzup | uvos: oh, I don't mean for frontend | 14:03 |
uvos | mighty17[m]: they dident compile es2gears_wayland? | 14:03 |
Wizzup | uvos: I meant for a connection manager | 14:03 |
mighty17[m] | uvos: nope :/ | 14:03 |
Wizzup | uvos: for example, here only go and python libs are offered: https://signald.org/articles/libraries/ | 14:03 |
uvos | lol | 14:03 |
Wizzup | why are we even doing this perf test on wayland btw? | 14:04 |
Wizzup | we already know that perf is suboptimal without the extra work we did | 14:04 |
freemangordon | because mighty17[m] is not convinced | 14:04 |
freemangordon | :) | 14:04 |
uvos | perf is suboptimal | 14:04 |
uvos | but was fine | 14:04 |
uvos | in my tests | 14:04 |
Wizzup | no, I just made a joke about the excuse musl devs would come up with and it turned into this discussion :) | 14:04 |
uvos | its just a couple of fps | 14:04 |
uvos | like 5 or so | 14:05 |
freemangordon | on what device? | 14:05 |
uvos | droid4 | 14:05 |
uvos | so same chip | 14:05 |
freemangordon | try on n900 and we'll comment again | 14:05 |
mighty17[m] | 5 fps on glxgears? wha-? | 14:05 |
uvos | mighty17[m]: 5 fps loss | 14:05 |
mighty17[m] | with older mesa i ran it once and it was def more than 5 | 14:05 |
uvos | i doubt mighty17[m] cares about omap4 | 14:05 |
freemangordon | mighty17[m]: 5 fps difference on es2gears | 14:05 |
uvos | *i doubt mighty17[m] cares about omap3 | 14:05 |
mighty17[m] | oh :derp: | 14:05 |
freemangordon | uvos: sure | 14:05 |
mighty17[m] | uvos: i mean, i do | 14:06 |
freemangordon | but that does not mean perf is fine | 14:06 |
freemangordon | mighty17[m]: you care for omap3? | 14:06 |
mighty17[m] | anyways i'll go trouble musl devs, got sidetracked a lot | 14:06 |
freemangordon | yeah | 14:06 |
mighty17[m] | freemangordon: why not? | 14:06 |
freemangordon | ok | 14:08 |
mighty17[m] | https://paste.debian.net/1226616/ glmark2-es2-drm also stopped working? | 14:08 |
uvos | hmm | 14:09 |
uvos | havend tried it in a while | 14:09 |
uvos | maybe | 14:09 |
freemangordon | you have another drm master running | 14:09 |
freemangordon | most -probably | 14:09 |
freemangordon | runse just fine | 14:10 |
freemangordon | *runs | 14:10 |
freemangordon | OS error code 13: Permission denied | 14:10 |
freemangordon | or bad user | 14:10 |
mighty17[m] | sudo? :o | 14:11 |
uvos | depends on how drm is configured | 14:12 |
mighty17[m] | or should i stop phosh and run? | 14:12 |
uvos | xorg drops master on vt switch | 14:12 |
uvos | maybe phosh dosent | 14:12 |
uvos | (yay wayland behavior fragmentation) | 14:12 |
mighty17[m] | too much craziness | 14:19 |
freemangordon | ok, I think I have REed libgbm | 14:24 |
freemangordon | umm, libdbm that is | 14:24 |
uvos | if you where reing libgbm your would be wasting your time :P | 14:26 |
freemangordon | yea :) | 14:26 |
freemangordon | a typo | 14:26 |
Wizzup | uvos: btw, lmk if there is some volume-applet thing I can package or build | 14:29 |
uvos | Wizzup: its almost done | 14:29 |
uvos | Wizzup: but i ended up having to do quite a bit | 14:29 |
uvos | to make everything work | 14:29 |
uvos | (ie vol keys used by applications, vol keys while locked, different states etc) | 14:29 |
freemangordon | hmm, and it seems to work :) | 14:31 |
uvos | everything works now, except call volume, it probubly works, but i cant test if i have the right stream since it dosent work on d4 | 14:31 |
uvos | in kernel | 14:31 |
uvos | freemangordon: sweet | 14:33 |
uvos | freemangordon: altho i forgot why we needed to change libgbm | 14:33 |
uvos | er dbm | 14:34 |
uvos | :P | 14:34 |
freemangordon | because it uses dumb_buffers to allocate GBM BOs, and dumb buffers cannot be TILER allocated | 14:38 |
freemangordon | also, they are always allocated as scanout | 14:38 |
freemangordon | which means that 1. modesetting cannot rotate through HW and 2. we'll soon we'll run out of tiler/dmm/cma space | 14:39 |
freemangordon | also, we have one less blob | 14:39 |
freemangordon | I am not going to change that now, ofc | 14:39 |
freemangordon | uvos: https://pastebin.com/tdheKDmh | 14:50 |
freemangordon | ok, lemme push what I have done so far | 14:52 |
freemangordon | https://github.com/maemo-leste/sgx-ddk-um/commit/b6e48b2ad4f41a2fd34d2a25790f2be8bf448c0e | 14:59 |
freemangordon | also, let me fix this lame code https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L126 | 15:00 |
lel | IMbackK opened a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste) | 15:03 |
uvos | Wizzup: ^^^^ | 15:03 |
lel | IMbackK edited a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste) | 15:04 |
Wizzup | ty will check in a bit | 15:05 |
lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste) | 15:14 |
uvos | Wizzup: also move /usr/share/maemo-statusmenu-volume/sinks.ini to leste-config when able | 15:20 |
Wizzup | uvos: right | 16:02 |
Wizzup | uvos: so pkill status should work? | 16:29 |
Wizzup | ah ok required mce restart | 16:30 |
Wizzup | lol it looks tiny on droid4 :p | 16:31 |
Wizzup | uvos: it looks like the volume for the hp and speaker are shared | 16:33 |
uvos | yes they share a volume in ucm | 16:33 |
Wizzup | they don't share the volume in actual playback | 16:33 |
uvos | only different ucm profiles have sperate volume | 16:33 |
Wizzup | if I unplug the volume is clearly much louder | 16:33 |
Wizzup | but the applet doesn't realise when it gets changed I think | 16:34 |
Wizzup | so it tries to revert to the wrong state | 16:34 |
uvos | it dosent get changed | 16:34 |
uvos | at least should not | 16:34 |
Wizzup | so playing something in mpv (or w/e) and set volume to max on speaker, plug in hp, set volume to min, remove hp, and then adjust volume a bit | 16:35 |
Wizzup | speaker will go to almost min | 16:35 |
Wizzup | (from previous max) | 16:35 |
uvos | yeah its true | 16:35 |
uvos | the volume slider dosent update from external at all | 16:35 |
Wizzup | don't know if it is intended, but it's not how it works on the n900 at least | 16:35 |
uvos | but this is probubly ucm bug | 16:35 |
uvos | the volume slider dosent updateing from external at all us a legacy bug, or rather nokia just dident care and the implementation is very bad | 16:36 |
Wizzup | are you sure it doesn't rely on ohm and those plugins? | 16:36 |
uvos | yes | 16:36 |
Wizzup | because it clearly works | 16:36 |
Wizzup | on n900 | 16:37 |
uvos | it cant update from external | 16:37 |
Wizzup | well it might read different streams/sinks? | 16:37 |
uvos | and it dose the volumes itself | 16:37 |
uvos | for different states | 16:37 |
Wizzup | oh, you mean it doesn't care for user manually changing it with alsamixer | 16:37 |
uvos | no | 16:37 |
uvos | it dosent care for anything else changing the stream | 16:37 |
uvos | pavucontrol etc | 16:37 |
Wizzup | the behaviour I described above works ok on fremantle/n900 though | 16:38 |
uvos | ucm is probubly set to duck the volume on hp by accient | 16:38 |
uvos | its broken | 16:38 |
uvos | it just works because it claims all changes for itself | 16:38 |
uvos | so ucm i probubly set to duck the volume on hp by accident | 16:38 |
Wizzup | then it must be aware that something changes in audio setup | 16:38 |
Wizzup | uvos: I don't think so, try to toy around with it a bit | 16:38 |
uvos | and the slider dosent update when pa changes it | 16:38 |
Wizzup | I'm pretty sure this is an unrelated bug | 16:39 |
Wizzup | uvos: try the inverse: set speaker to 0, then plug in hp, set hp to max, then unplug hp, note that it is silent (correct) and then press volume up or down and see speaker jump to max | 16:46 |
uvos | i dont have to | 16:47 |
uvos | you can see the problem in pavucontrol-qt | 16:47 |
uvos | anyhow it will get fixed once the slider follows pa events | 16:47 |
uvos | it has to anyhow | 16:47 |
freemangordon | it should do already | 16:50 |
Wizzup | freemangordon: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 | 16:50 |
freemangordon | yes, what I see here is most of the code has been removed | 16:51 |
freemangordon | no wonder it does not work | 16:51 |
freemangordon | btw, who is supposed to set the in-call volume ? | 16:52 |
uvos | the slider dose | 16:52 |
freemangordon | how? | 16:53 |
uvos | it waits for mce to send the incall event | 16:53 |
uvos | and then restores the stream and sets it | 16:53 |
freemangordon | where does it get the volume to set from? | 16:53 |
uvos | the restore feature is gohne | 16:53 |
freemangordon | why? | 16:53 |
uvos | becaus ucm dose so allready | 16:53 |
uvos | its redundant | 16:53 |
freemangordon | but does ucm have separate volumes for separate roles? | 16:54 |
uvos | yes | 16:54 |
uvos | for eatch profile | 16:54 |
freemangordon | *roles*? | 16:54 |
uvos | profiles are roles in ucm | 16:54 |
uvos | a profile is a configuration for some application | 16:54 |
uvos | ie music noticifacion call etc | 16:54 |
Wizzup | right, but the volume applet doesn't act on profile changes whereas the previous code did, so that's why this bug now exists I think | 16:54 |
uvos | right beacuse it dosent restore itself | 16:54 |
Wizzup | Looking at the deleted set_volume_timeout | 16:54 |
uvos | bet it never acted on external event | 16:54 |
freemangordon | maybe applet shall subscribe somehow to profile change events? | 16:55 |
freemangordon | sure it did | 16:55 |
uvos | no it didnt | 16:55 |
uvos | your missreading it | 16:55 |
freemangordon | uvos: I am using it | 16:55 |
uvos | anyhow yes it shal subscribe | 16:55 |
freemangordon | on fremantle | 16:55 |
uvos | it works beacuse it restores its OWN volumes | 16:55 |
uvos | not external ones | 16:55 |
uvos | jees | 16:55 |
freemangordon | ok | 16:55 |
uvos | so now something else restores the volume | 16:56 |
uvos | the slider just has to update | 16:56 |
freemangordon | ok | 16:56 |
Wizzup | it has to follow what restores it | 16:56 |
freemangordon | I think you can subscribe to module-restore | 16:56 |
uvos | you dont have to | 16:56 |
uvos | you can just suscribe to the volume of the stream in question | 16:56 |
freemangordon | well, you shoud subscribe to something to receive events :) | 16:57 |
uvos | right | 16:57 |
rafael2k | happy 2022! | 16:57 |
Wizzup | rafael2k: hey | 16:57 |
Wizzup | happy new year | 16:57 |
rafael2k | hi there! | 16:57 |
freemangordon | hi! | 16:57 |
rafael2k | bought my pp keyboard today! | 16:57 |
Wizzup | neat, I also bought one but I probably won't get it before I leave home for weeks | 16:58 |
rafael2k | my birthday present to myself... eheheheh | 16:58 |
Wizzup | rafael2k: I was wondering why you changed kernel package name from linux-image-pine64 to linux-image-5.15.10 | 16:58 |
rafael2k | just because without it, packaging failed here | 16:58 |
Wizzup | so we need to fix the mobian packaging to use our name I think | 16:58 |
Wizzup | I figured that was the case | 16:59 |
rafael2k | uhum... I just copied over our debian/ | 16:59 |
rafael2k | may be I could have started using mobian debian/ folder... | 16:59 |
Wizzup | rafael2k: that seems unlikely | 16:59 |
Wizzup | maybe you can explain how you build it locally | 16:59 |
rafael2k | debuild -uc -us | 16:59 |
rafael2k | just create the tarball with the source by hand | 17:00 |
Wizzup | I mean from what branches, etc | 17:01 |
Wizzup | since you said you 'copied the debian folder' | 17:01 |
rafael2k | https://github.com/rafael2k/pine64-kernel/commit/cf1c86ff04eaa7850087d561ad7a51cb97731a4e | 17:02 |
rafael2k | from beowulf-devel | 17:03 |
rafael2k | sorry, I forked over | 17:03 |
rafael2k | :P | 17:03 |
rafael2k | https://github.com/rafael2k/pine64-kernel/tree/maemo/beowulf-devel | 17:03 |
Wizzup | I don't know what you mean | 17:04 |
rafael2k | kernel from here: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.15 | 17:04 |
Wizzup | ok, so you clone the mobian-5.15 branch and place our debian dir in there | 17:04 |
rafael2k | but we could fetch the source from upstream, in gitlab | 17:04 |
rafael2k | yes! | 17:04 |
Wizzup | are you sure debian/patches/0001-maemo-leste-quirks.patch is being a[pplied? | 17:05 |
Wizzup | because: | 17:05 |
Wizzup | -packagename=linux-image-$version | 17:05 |
Wizzup | +packagename=linux-image-pine64 | 17:05 |
rafael2k | yes | 17:05 |
rafael2k | I tested | 17:06 |
Wizzup | I think the answer is "no", otherwise you would not need cf1c86ff04eaa7850087d561ad7a51cb97731a4e | 17:06 |
Wizzup | ? | 17:06 |
Wizzup | on your maemo/beowulf-devel the patch does not seem to exist | 17:06 |
rafael2k | https://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/maemo/0214-battery_level_hack.patch | 17:06 |
Wizzup | that is not the same patch | 17:06 |
rafael2k | ^ | 17:06 |
Wizzup | https://github.com/maemo-leste/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/0001-maemo-leste-quirks.patch | 17:07 |
rafael2k | yes it does | 17:07 |
Wizzup | does that look the same to you? :P | 17:07 |
rafael2k | did not know about that | 17:07 |
rafael2k | in my kernel it is applied | 17:07 |
rafael2k | from my branch | 17:07 |
Wizzup | it is in debian/patches/series in our maemo/beowulf-devel | 17:07 |
Wizzup | I checked out your branch and it is not in the patches/series file | 17:08 |
Wizzup | it doesn't exist | 17:08 |
rafael2k | maemo/0214-battery_level_hack.patch | 17:08 |
rafael2k | yes it is | 17:08 |
Wizzup | *stop* | 17:08 |
rafael2k | https://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/series | 17:08 |
Wizzup | the battery level thing you mention is completely unrelated | 17:08 |
Wizzup | I linked a different patch | 17:08 |
Wizzup | please open the link :) | 17:08 |
rafael2k | ah ok | 17:08 |
rafael2k | sorry | 17:08 |
Wizzup | np | 17:08 |
Wizzup | this link: https://github.com/maemo-leste/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/0001-maemo-leste-quirks.patch | 17:08 |
rafael2k | come back later | 17:08 |
rafael2k | ma birthday today | 17:08 |
rafael2k | ; )) | 17:08 |
Wizzup | oh, shit :) | 17:09 |
Wizzup | happy bday | 17:09 |
Wizzup | I think I will add this patch back in | 17:09 |
Wizzup | and then revert the other one | 17:09 |
Wizzup | then see if it builds | 17:09 |
rafael2k | yay! | 17:09 |
rafael2k | cheers! | 17:09 |
Wizzup | sure, thanks | 17:09 |
Wizzup | later I have some other questiosn | 17:09 |
Wizzup | but enjoy | 17:09 |
Wizzup | freemangordon: what do you say about the volume applet changes? I think we can merge this now, build it, and then look at adding notifier | 17:10 |
Wizzup | s/notifier/listener/ | 17:10 |
freemangordon | well, I am not sure this will work correctly with libplayback and with this https://github.com/maemo-leste/hildon-plugins-notify-sv/blob/master/lib/nsv-pulse-context.c | 17:15 |
freemangordon | removing stream-restore basically means that all maemo audio infra will not function | 17:17 |
freemangordon | including ohm policies and whatnot | 17:17 |
Wizzup | right | 17:18 |
freemangordon | this is nto about updating the slider, but about lots more | 17:19 |
freemangordon | so, what I think shall be done is: get module-stream-restore(or whetever the name is) from nemo and make it work, then port the applet to use it | 17:20 |
Wizzup | I think I have this packaged | 17:20 |
freemangordon | it would have been good if we can integrate with ucm though | 17:21 |
freemangordon | but lets look at that after we finish all the onther things we're on atm | 17:21 |
Wizzup | yes, ohm and pa stuff is going to require quite some brainpower and time | 17:21 |
freemangordon | mhm | 17:21 |
Wizzup | right, so do we merge this and later revert some stuff? | 17:21 |
Wizzup | right now we have no volume control | 17:21 |
freemangordon | up to you | 17:22 |
Wizzup | I think I like the other changes, so I'd say yes, but maybe get the code commented rather than removed | 17:22 |
freemangordon | maybe create a separate branch with that merged | 17:22 |
Wizzup | or a branch for the code we want to keep | 17:22 |
freemangordon | I wonder if we can create our own ucm parser, if ucm properties are not already available somehow | 17:23 |
freemangordon | but lets not get into that now :) | 17:23 |
uvos | ucm is alsa | 17:23 |
uvos | pa is not nesscary at all | 17:23 |
uvos | and yes you can read it from alsa | 17:23 |
freemangordon | as I think getting audio properly will be the most complicated task we'll face | 17:24 |
uvos | on everything except the n900 | 17:24 |
uvos | everything should work allready | 17:24 |
uvos | except notification volume | 17:24 |
uvos | witch is pretty easy to add | 17:24 |
uvos | functionality wise | 17:25 |
freemangordon | uvos: no, look at libplayback | 17:25 |
uvos | ofc using the upstream alsa stuff makes api work differenly | 17:25 |
freemangordon | everything maemo uses that | 17:25 |
freemangordon | if there is upstream functionality that matches, well, maybe we can rewrite libplayback to use it. but I doubt | 17:26 |
freemangordon | uvos: a simple example: you listen to music and sms comes. what happens? music gets paused, 'new sms' sound played and music resumed. or. sms sounds get mixed with music? or...? | 17:27 |
uvos | yes | 17:27 |
uvos | sound pauses | 17:27 |
mighty17[m] | we had a public history right? | 17:27 |
uvos | because the profile is switched pa suspends the sink | 17:28 |
uvos | this causes pause | 17:28 |
mighty17[m] | ie chat logs | 17:28 |
freemangordon | uvos: "sound paused" is not the same as "playback pauses" | 17:28 |
uvos | then it plays at some volume set for the new stream | 17:28 |
uvos | playback pauses | 17:28 |
freemangordon | how? | 17:28 |
uvos | if the application is implemented correctly | 17:28 |
uvos | gets a pa event | 17:28 |
freemangordon | it is, by using libplyback | 17:28 |
uvos | this works in mpv and mpd | 17:28 |
uvos | and all desktop applications generally | 17:28 |
freemangordon | who sets the priorities and classes? | 17:29 |
uvos | then the sms notification sound is played at whatever volume of the new stream | 17:29 |
uvos | and the stream switches back | 17:29 |
freemangordon | look at this https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain | 17:29 |
freemangordon | and https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Policy_Subsystem | 17:30 |
freemangordon | I doubt upstream matches this | 17:30 |
freemangordon | and I can assure you this work extremely well in maemo | 17:30 |
uvos | if its implemend as well as the volume slider | 17:30 |
uvos | hahahahahahaha | 17:30 |
uvos | so right now sphone dose its own switching, this is bad we would need soemthing to do so | 17:30 |
uvos | yes this needs to take priority into acount | 17:31 |
freemangordon | well, you may find it funny, but it really works wvery well | 17:31 |
uvos | but this is the only pice we need | 17:31 |
freemangordon | not really | 17:31 |
uvos | and its very small compeard to takeing the eintere legacy stack | 17:31 |
uvos | yes it is | 17:31 |
freemangordon | uvos: I am not going to argue | 17:31 |
freemangordon | but, to the extend it depends on me, I will resist to turning maemo-leste to a pale shadow of fremantle | 17:33 |
Wizzup | sailfish also uses libplayback I think | 17:34 |
uvos | thinking that just because implementaion differeng it being a "pale shadow" is the hight of folly | 17:34 |
uvos | libplayback is not the issue here | 17:34 |
uvos | since we can easly port it to whatever | 17:34 |
Wizzup | what is the issue? | 17:34 |
uvos | everything else | 17:34 |
uvos | :P | 17:34 |
Wizzup | I don't get it | 17:34 |
sicelo | btw, according to someone who toyed on N900, maybe it's not *that* difficult to deal with the 200+ controls ... apparently not all of them are connected | 17:34 |
sicelo | they prolly just exist in the chip, and driver exports them, but that's all | 17:35 |
uvos | the n900 is a bit different | 17:35 |
uvos | so it needs soemthing to redirect streams | 17:35 |
uvos | since the cpu needs to copy samples about form device to device | 17:35 |
uvos | something has to do that | 17:35 |
uvos | this is indeed a bit more work | 17:35 |
uvos | but it dosent tranlate at all to mapphones or pp | 17:35 |
freemangordon | uvos: you mean calls? | 17:35 |
uvos | yeah, also bt | 17:36 |
freemangordon | my example was not about that, but anyway | 17:36 |
uvos | right im just saying upstream has nothing for this | 17:36 |
uvos | afaik | 17:36 |
Wizzup | so what do we not want to pick from fremantle? I am confused | 17:37 |
Wizzup | the sink roles definitely seemed to make sense to me | 17:37 |
uvos | well the pa setup in general, ohm mostly | 17:37 |
uvos | dont worry | 17:37 |
uvos | ill do it | 17:37 |
freemangordon | uvos: please don;t | 17:37 |
uvos | sigh watever | 17:38 |
uvos | *whatever | 17:38 |
Wizzup | freemangordon: uvos: let's be constructive here, and I would really appreciate uvos' help with the ohm stuff | 17:38 |
freemangordon | uvos: even if we are to do that (remove ohm etc)... | 17:39 |
freemangordon | I think we shall discuss what we want to achieve, no? | 17:39 |
freemangordon | Wizzup: sure | 17:39 |
uvos | well not now | 17:39 |
Wizzup | we do, and we did discuss that too, I think | 17:39 |
Wizzup | but not now | 17:39 |
Wizzup | yeah | 17:39 |
Wizzup | :D | 17:39 |
uvos | im done with this for now | 17:39 |
freemangordon | yeah, not now | 17:39 |
uvos | merge the volume slider if you like whatever | 17:39 |
Wizzup | can you fix the comment I left? | 17:40 |
sicelo | https://gist.github.com/NikkSaan/b8dec1ddb368e0d8ea7b413d8533e2ef#file-nokia-n900-dev-journal-L143 | 17:51 |
freemangordon | who's that guy? | 17:55 |
freemangordon | looks like enthusiastic one :) | 17:55 |
sicelo | he made some interesting ui in qml a couple of years ago, but wasn't keen on making the source public | 17:56 |
freemangordon | ah, I remember I saw something on youtube | 17:57 |
freemangordon | some kind of media player os something | 17:57 |
freemangordon | *or | 17:57 |
sicelo | yes | 17:58 |
sicelo | that's he | 17:58 |
sicelo | https://www.youtube.com/watch?v=_sqjKsTh1zY | 17:59 |
lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste) | 18:16 |
uvos | Wizzup: sure | 18:16 |
Wizzup | thanks | 18:22 |
Wizzup | I'll look at merging this tonight, waiting for the new pine64 kernel to build | 18:22 |
freemangordon | Wizzup: failed | 19:15 |
Wizzup | freemangordon: wtf I thought I removed that | 19:17 |
* Wizzup pushes and reruns | 19:18 | |
freemangordon | tmlind: fyi https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c | 20:14 |
tmlind | freemangordon: nice, i noticed :) maybe that also allows fixing the wlroots issue | 20:25 |
freemangordon | what issue? | 20:41 |
tmlind | the errors trying to use render nodes | 20:43 |
freemangordon | ah | 20:43 |
freemangordon | https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L540 | 20:44 |
freemangordon | :) | 20:44 |
tmlind | is that the part that xcracer had to patch for exynos? | 20:45 |
freemangordon | no idea | 20:46 |
freemangordon | I don;t remember what he had to patch | 20:46 |
tmlind | oh i see, you suggest that's why the failure is happening with the render node :) | 20:46 |
freemangordon | mhm | 20:46 |
tmlind | hehe ok | 20:46 |
tmlind | so for exynos, there's some binary patching for omapdrm.. probably the same place | 20:47 |
freemangordon | maybe | 20:47 |
tmlind | i'll give it a try for sure with wlroots | 20:47 |
freemangordon | umm... the only thing that I fixed is some lame buffer allocation | 20:48 |
freemangordon | so it will fail too | 20:48 |
tmlind | ok, but now it can be patched | 20:48 |
freemangordon | ah, ok | 20:48 |
tmlind | as opposed to adding non-standard hacks to wlroots | 20:48 |
tmlind | well at least that's what i hope :) | 20:49 |
freemangordon | yeah | 20:49 |
freemangordon | going afk, ttyl | 20:50 |
tmlind | yeah me too ttyl | 20:50 |
Wizzup | does anyone know how to provide mc-tool with parameters when adding an account? | 23:07 |
Wizzup | ah, got it.... | 23:07 |
Wizzup | is merproject git down? | 23:33 |
Wizzup | https://git.merproject.org/mer-core/nemo-qml-plugin-messages | 23:33 |
uvos | SSL_ERROR_NO_CYPHER_OVERLAP | 23:37 |
uvos | GnuTLS: A packet with illegal was received. | 23:38 |
uvos | Wizzup: huh | 23:38 |
rafael2k | this is not ok? https://github.com/sailfishos/nemo-qml-plugin-messages/ | 23:38 |
Wizzup | oh they moved it again | 23:48 |
Wizzup | rafael2k: btw dang that pine64 kernel builds takes a long time, how many modules did they enable | 23:49 |
Wizzup | it's already going for over 4 hours | 23:49 |
Wizzup | I'm pretty sure we didn't have that much enabled | 23:49 |
Wizzup | rafael2k: it would be good to get that down a bit in size imho | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!