libera/#maemo-leste/ Monday, 2022-01-10

uvosugh00:10
uvosthe maemo volume buttons switch between portrait and landscape00:10
uvoswithout a config option00:11
uvosterrible ux00:11
uvosfirst rule of buttons: muscle memory works if they dont change function00:11
Wizzupuvos: who intercepts this then?00:12
Wizzupuvos: on the n900 this works really well fwiw00:12
uvosandroid used to do this00:13
uvosand i hated it00:13
uvosanyhow00:13
uvosits implmented in the volume applet00:13
uvosbtw the volume applet should work fine with the current ucm setup00:13
uvosyou should only have to change /usr/share/maemo-statusmenu-volume/volume_steps_update00:14
uvosto point to the correct sink00:14
uvosunfortionatly it dosent work atm00:14
uvosbut that just looks like a pa api change00:14
Wizzupwait you have volume applet working?00:14
uvosyes00:15
Wizzuplet me send you some beers :)00:15
uvosheh00:15
Wizzupwith our existing pa setup?00:15
uvosyes00:15
uvosits just a tiny change00:15
uvosand that config change00:15
uvosbut let me clean it up00:15
Wizzupok00:15
uvosalso the f7 f8 thing..00:16
uvosi just replaced that atm00:16
Wizzupyeah, let's not get into that now but well noted00:16
uvosheh00:16
uvoswhat you dont want me flaming for 30 minutes about keymappings?00:16
Wizzupwell we've gone over that stuff a few times and realised that it is fubar no matter00:17
uvosnot really00:17
uvosbut ok00:17
uvosnot now00:17
Wizzup:)00:17
uvoscorrect sink is alsa_output.0.HiFi__hw_Audio_0__sink btw00:19
uvos(should be on all devices)00:19
uvos(except n900)00:19
Wizzupwe might need to make volume_steps_update a leste-config file then, or figure out how to deal with it00:20
Wizzupmaybe if we give n900 UCM file00:20
uvosalso not sure how to deal with hdmi audio00:21
uvosthe thing is somewhat unfortionatly hardcoded for 2 channels00:21
uvosdroid 4 might have up to 600:21
WizzupI plan to worry about hdmi and external screens quite a bit later down the road00:30
WizzupI'd have to check how the n900 deals with it, but I suspect it's probably on the headphone mapping00:30
uvossure00:30
Wizzup(since on the n900 the external screen clone is through the hp jack)00:30
uvosits also just 2 channels00:30
uvosso theres nothing to handle00:30
Wizzuphm, what other channels?00:30
uvosn900 dosent have otg and dosent have hdmi00:31
uvosergo no audio output > 2 channels is possible00:31
uvosergo nokia dident care00:31
Wizzupright00:32
Wizzupmy 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 list00:32
Wizzupanyhow I am happy currently because I think I understand telepathy well enough now00:32
uvosgranted00:32
Wizzupof course my confidence will tank when I start writing the code, but I think I'll get through it00:33
Wizzup:p00:33
Wizzupfreemangordon: you probably meant https://wiki.maemo.org/N900_Mission_Control00:37
Wizzupsicelo: fwiw mc-tool is part of libmissioncontrol-utils00:38
uvoshe allready said that00:39
uvosto you00:39
Wizzupok, must have missed it :)00:39
Wizzupah, I see it now00:40
Wizzuphm, maybe we need to set tp ring to 'always on' as opposed to 'when requested'00:59
Wizzupanyway, time for some sleep01: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 need05:50
mighty17[m]commented out that line, pretty sure i have deps but now i get06: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 it06:58
mighty17[m]Nvm fixed it :D will push to my fork soon07:34
freemangordonuvos: 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
freemangordonplease restore that if you have removed it07:58
mighty17[m]reverted https://github.com/maemo-leste/xf86-video-omap/commit/2308cdc7f42a3760b3fa2642c6a8011bd3d71b9a coz i dont have sgx-ddk-um-dev working08: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 clues08:08
freemangordonwhat do you mean?08:09
freemangordonah, -lpvr2d?08:10
mighty17[m]` omap_pvr_drv_la_LIBADD = @XORG_LIBS@ -lsrv_um -lpvr2d`08:10
mighty17[m]ye08:10
freemangordonif you revert that, there will be no HW blit accelleration08:11
freemangordonand in general this is not well tested soon08:11
mighty17[m]im not reverting that, im reverting ` Depend on sgx-ddk-um-dev `08:11
freemangordonah08: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 revert08:12
freemangordonwell, those 2 libs a re part of binary blobs package08:12
freemangordonmhm08:12
mighty17[m]<mighty17[m]> "and now it fails with `/usr/lib..." <- but it fails with this08:12
freemangordonmighty17[m]: you need libsrv_um.so and libpvr2d.so08:13
mighty17[m]freemangordon: source?08:14
freemangordonthose are in SGX binary blobs08:14
mighty17[m]ah sgx-ddk-um08:15
freemangordonmhm08:15
mighty17[m]i wonder if i should just switch to your sgx-ddk-um08:15
freemangordonbetter do08:16
freemangordonas now I am REing dbm from there08:16
freemangordonhopefully it will start supporting TILER allocated buffers and whatnot08:16
mighty17[m]:D08:17
freemangordoninstead of blindly allocation dumb scanout only buffers as of now08:17
freemangordon*allocating08:17
siceloI also find the vol up/down switching useful08:17
* mighty17[m] has no clue what that means, but is excited08:17
freemangordonyeah, we'll have that ;)08:17
freemangordonmighty17[m]: or, even better, as we said - switch to leste :p08:18
mighty17[m]hehe08:18
mighty17[m]it'd be preferable that the work is used on all distros :P08: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 modesetting09:44
freemangordonmighty17[m]: https://pastebin.com/v9SBparB09:49
freemangordonand yes, looks like it is packaged properly09:49
freemangordonbut, you need to create xorg.conf for it09:50
freemangordonsee pastebin ^^^09:50
mighty17[m]Will try, tysm!09:53
uvosfreemangordon: i dident remove it11:31
uvosfreemangordon: i did make it a config option11: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
uvosmust not be linked to pvr um11:41
freemangordonuvos: no, that's another issue11:41
freemangordonInitPowerVREXA is in pvr EXA module11:42
freemangordonmighty17[m]: could you move omap_pvr_drv.so out of modules directory and retry?11:42
mighty17[m]as in?11:44
freemangordonmv omap_pvr_drv.so /root for example11:44
freemangordonmove it to another dir11:44
mighty17[m]oh ok11:47
Wizzupmighty17[m]: why revert  `Depend on sgx-ddk-um-dev ` ? just make sure you have the pc file11:52
WizzupI made one11:52
mighty17[m]Wizzup: i dont have it on alpine11:52
Wizzupthen make it!11:52
Wizzupotherwise things won't work11:52
Wizzupyou need -everything-11:52
WizzupI am talking about the .pc file11:52
Wizzupbut if you think it's working, then ignore, just waking up11:53
Wizzupit just doesn't seem like a good idea to remove stuff from autotools that we add11:53
Wizzupthey aren't just checks, they also translate to CFLAGS and linker actions11:53
freemangordoncorrect11:55
mighty17[m]<freemangordon> "mighty17: could you move..." <- https://paste.debian.net/1226595/12:34
mighty17[m]oh damn12:35
mighty17[m]sorry wait12:35
mighty17[m]freemangordon: https://paste.debian.net/1226598/12:38
freemangordonmighty17[m]: it is not correctly compiled12:39
mighty17[m]i suppose i'll just use your sgx-ddk-um then12:40
freemangordonno12:40
mighty17[m]hm?12:40
freemangordonit is not related12:40
mighty17[m]oh ok, so wdym by not correctly compiled?12:41
freemangordonyour ld should not try to resolve InitPowerVREXA and fail if it does not find it12:41
freemangordonthis is more or less weak symbol12:41
mighty17[m]freemangordon: so smth wrong in my xf86-video-omap right?12:44
freemangordonyeah12:44
freemangordonmighty17[m]: objdump -T /usr/lib/xorg/modules/drivers/omap_drv.so | grep EXA12: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? :o12:45
freemangordonno, it is fine12:46
freemangordonhmm12:46
freemangordonsame here: 00000000      D  *UND*00000000              InitPowerVREXA12:46
freemangordonthe question is why loader on alpine insists on resolving that12:47
Wizzupmighty17[m]: are you using our specific sgx ddk and also the .pc file?12:47
Wizzupjust to check12:47
mighty17[m]only thing i changed was dependency sgx-ddk-um and bring back the header files12:47
freemangordonWizzup: the issue is not with sgx libs12:47
freemangordonbut with xorg12:47
mighty17[m]Wizzup: nope, https://github.com/MightyM17/xf86-video-omap/12:47
freemangordonfor some reason ld.so on alpine tries to resolve symbols on loading12:48
Wizzupok, then I'll let fmg handle it because I think it's much better to build it the way tested it12:48
mighty17[m]musl issues?12:48
freemangordonyeah12:48
mighty17[m]ugh.. :/12:48
Wizzupalso reverting the header commit is a bad idea, now you might even have wrong version12:48
mighty17[m]Wizzup: well from where can i get header files then?12:49
mighty17[m]omap5-sgx-ddk-um-linux ?12:49
freemangordonWizzup: for sure this shall be fixe, but that's not the issue he is hitting now12:49
freemangordonmighty17[m]: from our -dev package12:49
mighty17[m]me has to package that for alpine12:49
mighty17[m]but even with that, this issue would come12:49
Wizzupyes, we worked hard to package it all properly so that people could just mimick the packaging and make it all work12: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 work12:50
* mighty17[m] has no clue how deb works12:50
freemangordonmighty17[m]: no12:50
Wizzupthat'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 right12:50
freemangordonthis is dynamic linker's job to resolve symbols when they are needed12:51
Wizzupmighty17[m]: I also don't know how APKBUILDs work or other .spec files for rpm but I had no trouble figuring them out12:51
* Wizzup afk12:51
freemangordonand this seems to be broken, somehow12:51
mighty17[m]looks like we should ask in #alpine?12:51
freemangordonsee https://www.openwall.com/lists/musl/2013/05/17/612:51
freemangordon"musl intentionally does not support > lazy binding."12:52
mighty17[m]ugh...12:52
freemangordonso, go ask on #alpine :)12:52
freemangordonI can't help with that one12:52
mighty17[m]alrighty! thanks a lot12:53
freemangordonhmm, wait12:53
freemangordonmighty17[m]: could you move omap_pvr_drv.so back to modules firectory?12:53
freemangordonand then do LD_PRELOAD=/usr/lib/xorg/modules/drivers/omap_pvr_drv.so Xorg12:54
mighty17[m]ok trying that12:55
freemangordonhmm, see https://patchwork.openembedded.org/patch/91717/12:55
mighty17[m]ah well i use lightDM12:55
freemangordonmaybe you should add:12:57
freemangordonSection "Module"12:57
freemangordon    Load "omap_pvr_drv"12:57
freemangordonEndSection12:57
freemangordonto xorg.conf filke12:57
freemangordon*file12:57
mighty17[m]freemangordon: this didnt work12:58
freemangordonmighty17[m]: it should be omap_pvr, not nomap_pvr_drv12:58
freemangordonit should12:59
Wizzupthe part about dlclose() being a no-op is kinda painful12:59
freemangordonwait, what did not work?12:59
freemangordonLD_PRELOAD?12:59
mighty17[m]musl is painful12:59
mighty17[m]LD_PRELOAD12:59
freemangordonswitch to leste :p12:59
mighty17[m]i added a sh to /etc/profile.d12:59
freemangordontry module one12:59
freemangordonit should work12:59
mighty17[m]ok12:59
freemangordonSection "Module"12:59
freemangordon    Load "omap_pvr"12:59
freemangordonEndSection12:59
uvosthe switch to leste thing13:00
uvoswould probubly hold more watter13:00
uvosif hildon was a xdg_session13: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_pvr13:05
freemangordonno idea13:05
freemangordonmaybe try with omap-pvr13:05
mighty17[m]`[   200.300] (EE) Failed to load module "omap-pvr" (module does not exist, 0)`13:06
freemangordonhmm, wait13:06
freemangordonyeah, it should be omap_pvr13:07
mighty17[m]`Section "Module"`13:08
mighty17[m]`    Load "omap_pvr"`13:08
mighty17[m]`EndSection`13:08
freemangordonthis is crazy :(13:10
freemangordonit seems xoreg strips underscores13:10
mighty17[m]exactly what i was about to say13:10
mighty17[m]so a sneaky rename/linking? :P13:11
freemangordonmighty17[m]: please edit https://github.com/maemo-leste/xf86-video-omap/blob/757479eb1e3943cc2067bec3752f7757f7598a7d/src/omap_exa.h#L89 and remove underscore13:11
freemangordonalso https://github.com/maemo-leste/xf86-video-omap/blob/757479eb1e3943cc2067bec3752f7757f7598a7d/src/omap_exa_pvr.c#L115813:11
freemangordonrebuild/reinstall13:11
mighty17[m]oh damn13:11
mighty17[m]alrighty13: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
freemangordonmighty17[m]: do you have  ldd /usr/lib/xorg/modules/omap_pvr_drv.so ?13:43
freemangordondo you have  /usr/lib/xorg/modules/omap_pvr_drv.so ?13:44
mighty17[m]ldd? :P13:44
freemangordonyeah, next thing to do13:44
mighty17[m]`/usr/lib/xorg/modules/omap_pvr_drv.so` yes13:44
freemangordonand what about ldd on it?13:44
mighty17[m]freemangordon: you'll not like it https://paste.debian.net/1226612/13:45
freemangordonyeah, this will not work13:45
freemangordonwe have circular dependencies13:45
mighty17[m]fun13:46
freemangordonomap_drv wants symbols from omap_pvr_drv13:46
freemangordonand omap_pvr_drv want symbols from omap_drv13:46
freemangordonask on #alpine or on #musl :)13:46
mighty17[m]mhm13:47
mighty17[m]i cant join alpine somehow13:47
mighty17[m]i do have registered nick13:47
WizzupI'm waiting for the "don't use X" answer :)13:47
freemangordon:D13:47
mighty17[m]Wizzup: wayland works fine :P13:47
freemangordondoes it?13:47
freemangordonplease rotate to landscap[e and tell me what FPS is13:48
freemangordonfor glmark2, for example13:48
freemangordonand then we can discuss "works fine" ;)13:48
uvoses2_gears is the best benchmark for this13:49
Wizzupparazyd: looks like most of our image builds are failing: https://phoenix.maemo.org/view/Images/job/leste-image-pinephone/82/console13:49
uvossince it dosent take mutch time to render it frame13:49
uvos*tis13:49
uvos*its13:49
uvosjeez13:49
freemangordonyeah, but it is 300x300 window13:49
mighty17[m]freemangordon: default is landscape :)13:49
freemangordonand SW blit is not like 960x54013:49
mighty17[m]uvos: ok gimme a sec then13:49
freemangordonmighty17[m]: doesn;t not matter13:49
uvosfreemangordon: resize the window then :P13:50
freemangordoncompare fps for native VS rotated orientation13:50
freemangordonuvos: on gears?13:50
freemangordonhow?13:50
freemangordonI know you can rotate, but resize?13:50
mighty17[m]freemangordon: what benchmark do you want?13:50
uvosfreemangordon: just drag the window13:50
uvosfreemangordon: border13:50
uvosfreemangordon: like any window...13:50
uvosfreemangordon: hes using openbox13:51
uvosor start i313:51
freemangordonmighty17[m]: ok, do as uvos said13:51
mighty17[m]gears?13:51
freemangordonmhm13:51
freemangordonbut resize as much as you can13:51
uvosand i3 as vm13:51
uvosor maximise the window13:52
freemangordonthough I would prefer glmark --fullscreen13:52
freemangordonbut lets see gears first13:52
mighty17[m]if it would work :P13:54
mighty17[m]`Error: couldn't get an RGB, Double-buffered visual`13:54
freemangordonworks fine, yeah :p13:54
uvosyou dident run glxgears right13:55
freemangordonwhy glx?13:55
freemangordonit should be es2_gears13:55
uvosbecause thats the error message it potsts13:55
uvoson pvr13:55
uvos`Error: couldn't get an RGB, Double-buffered visual`13:55
freemangordondoes not matter, we want es2_gears13:55
uvosi know13:56
freemangordonnot glxgears13:56
uvosim asking if mighty17[m] made this mistake...13:56
freemangordonah13:56
mighty17[m]as in?13:56
WizzupI think we all need telepathy13:56
Wizzuppun intended13:56
mighty17[m]pvr-pathy13:56
uvosmighty17[m]: what did you run13:56
mighty17[m]glxgears13:57
uvosright thats wrong13:57
uvosglx _canot_ work on pvr13:57
uvosyou want es2gears13:57
mighty17[m]then what should i do13:57
uvoses2gears13:57
mighty17[m]https://pkgs.alpinelinux.org/packages?name=*es2gears*&branch=edge fun13:58
freemangordonmesa-tools-extra or somesuch is the package13:58
Wizzupes2_gears for the record13:58
Wizzupiirc13:58
freemangordonor mesa-utils-extra13:58
freemangordonyea13:58
freemangordonit is with underscore13:59
freemangordonbut still unknown to alpine13:59
mighty17[m]mesa-demos in alpine13:59
freemangordonok13:59
mighty17[m]`samsung-espresso3g:~$ sudo apk search es2gears`13:59
uvosWizzup: no $ which es2gears /usr/bin/es2gears13:59
mighty17[m]`mesa-demos-8.4.0-r1`13:59
Wizzupuvos: weird13:59
freemangordonoh, no underscore14:00
freemangordonanyway14:00
freemangordonmighty17[m]: you want es2gears_wayland14:00
mighty17[m]`/usr/bin/es2gears_x11` well shit14:00
mighty17[m]so thats out of question14:02
* Wizzup wishes there were golang bindings for telepathy im14:02
uvoswhy go14:02
uvosalll of our frontends are c(++)14:02
mighty17[m]glmark2 now?14:03
Wizzupuvos: oh, I don't mean for frontend14:03
uvosmighty17[m]: they dident compile es2gears_wayland?14:03
Wizzupuvos: I meant for a connection manager14:03
mighty17[m]uvos: nope :/14:03
Wizzupuvos: for example, here only go and python libs are offered: https://signald.org/articles/libraries/14:03
uvoslol14:03
Wizzupwhy are we even doing this perf test on wayland btw?14:04
Wizzupwe already know that perf is suboptimal without the extra work we did14:04
freemangordonbecause mighty17[m] is not convinced14:04
freemangordon:)14:04
uvosperf is suboptimal14:04
uvosbut was fine14:04
uvosin my tests14:04
Wizzupno, I just made a joke about the excuse musl devs would come up with and it turned into this discussion :)14:04
uvosits just a couple of fps14:04
uvoslike 5 or so14:05
freemangordonon what device?14:05
uvosdroid414:05
uvosso same chip14:05
freemangordontry on n900 and we'll comment again14:05
mighty17[m]5 fps on glxgears? wha-?14:05
uvosmighty17[m]: 5 fps loss14:05
mighty17[m]with older mesa i ran it once and it was def more than 514:05
uvosi doubt mighty17[m] cares about omap414:05
freemangordonmighty17[m]: 5 fps difference on es2gears14:05
uvos*i doubt mighty17[m] cares about omap314:05
mighty17[m]oh :derp:14:05
freemangordonuvos: sure14:05
mighty17[m]uvos: i mean, i do14:06
freemangordonbut that does not mean perf is fine14:06
freemangordonmighty17[m]: you care for omap3?14:06
mighty17[m]anyways i'll go trouble musl devs, got sidetracked a lot14:06
freemangordonyeah14:06
mighty17[m]freemangordon: why not?14:06
freemangordonok14:08
mighty17[m]https://paste.debian.net/1226616/ glmark2-es2-drm also stopped working?14:08
uvoshmm14:09
uvoshavend tried it in a while14:09
uvosmaybe14:09
freemangordonyou have another drm master running14:09
freemangordonmost -probably14:09
freemangordonrunse just fine14:10
freemangordon*runs14:10
freemangordonOS error code  13:  Permission denied14:10
freemangordonor bad user14:10
mighty17[m]sudo? :o14:11
uvosdepends on how drm is configured14:12
mighty17[m]or should i stop phosh and run?14:12
uvosxorg drops master on vt switch14:12
uvosmaybe phosh dosent14:12
uvos(yay wayland behavior fragmentation)14:12
mighty17[m]too much craziness14:19
freemangordonok, I think I have REed libgbm14:24
freemangordonumm, libdbm that is14:24
uvosif you where reing libgbm your would be wasting your time :P14:26
freemangordonyea :)14:26
freemangordona typo14:26
Wizzupuvos: btw, lmk if there is some volume-applet thing I can package or build14:29
uvosWizzup: its almost done14:29
uvosWizzup: but i ended up having to do quite a bit14:29
uvosto make everything work14:29
uvos(ie vol keys used by applications, vol keys while locked, different states etc)14:29
freemangordonhmm, and it seems to work :)14:31
uvoseverything works now, except call volume, it probubly works, but i cant test if i have the right stream since it dosent work on d414:31
uvosin kernel14:31
uvosfreemangordon: sweet14:33
uvosfreemangordon: altho i forgot why we needed to change libgbm14:33
uvoser dbm14:34
uvos:P14:34
freemangordonbecause it uses dumb_buffers to allocate GBM BOs, and dumb buffers cannot be TILER allocated14:38
freemangordonalso, they are always allocated as scanout14:38
freemangordonwhich means that 1. modesetting cannot rotate through HW and 2. we'll soon we'll run out of tiler/dmm/cma space14:39
freemangordonalso, we have one less blob14:39
freemangordonI am not going to change that now, ofc14:39
freemangordonuvos: https://pastebin.com/tdheKDmh14:50
freemangordonok, lemme push what I have done so far14:52
freemangordonhttps://github.com/maemo-leste/sgx-ddk-um/commit/b6e48b2ad4f41a2fd34d2a25790f2be8bf448c0e14:59
freemangordonalso, let me fix this lame code https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L12615:00
lelIMbackK opened a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste)15:03
uvosWizzup: ^^^^15:03
lelIMbackK edited a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste)15:04
Wizzupty will check in a bit15:05
lelIMbackK synchronize a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste)15:14
uvosWizzup: also move /usr/share/maemo-statusmenu-volume/sinks.ini to leste-config when able15:20
Wizzupuvos: right16:02
Wizzupuvos: so pkill status should work?16:29
Wizzupah ok required mce restart16:30
Wizzuplol it looks tiny on droid4 :p16:31
Wizzupuvos: it looks like the volume for the hp and speaker are shared16:33
uvosyes they share a volume in ucm16:33
Wizzupthey don't share the volume in actual playback16:33
uvosonly different ucm profiles have sperate volume16:33
Wizzupif I unplug the volume is clearly much louder16:33
Wizzupbut the applet doesn't realise when it gets changed I think16:34
Wizzupso it tries to revert to the wrong state16:34
uvosit dosent get changed16:34
uvosat least should not16:34
Wizzupso 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 bit16:35
Wizzupspeaker will go to almost min16:35
Wizzup(from previous max)16:35
uvosyeah its true16:35
uvosthe volume slider dosent update from external at all16:35
Wizzupdon't know if it is intended, but it's not how it works on the n900 at least16:35
uvosbut this is probubly ucm bug16:35
uvosthe volume slider dosent updateing from external at all us a legacy bug, or rather nokia just dident care and the implementation is very bad16:36
Wizzupare you sure it doesn't rely on ohm and those plugins?16:36
uvosyes16:36
Wizzupbecause it clearly works16:36
Wizzupon n90016:37
uvosit cant update from external16:37
Wizzupwell it might read different streams/sinks?16:37
uvosand it dose the volumes itself16:37
uvosfor different states16:37
Wizzupoh, you mean it doesn't care for user manually changing it with alsamixer16:37
uvosno16:37
uvosit dosent care for anything else changing the stream16:37
uvospavucontrol etc16:37
Wizzupthe behaviour I described above works ok on fremantle/n900 though16:38
uvosucm is probubly set to duck the volume on hp by accient16:38
uvosits broken16:38
uvosit just works because it claims all changes for itself16:38
uvosso ucm i probubly set to duck the volume on hp by accident16:38
Wizzupthen it must be aware that something changes in audio setup16:38
Wizzupuvos: I don't think so, try to toy around with it a bit16:38
uvosand the slider dosent update when pa changes it16:38
WizzupI'm pretty sure this is an unrelated bug16:39
Wizzupuvos: 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 max16:46
uvosi dont have to16:47
uvosyou can see the problem in pavucontrol-qt16:47
uvosanyhow it will get fixed once the slider follows pa events16:47
uvosit has to anyhow16:47
freemangordonit should do already16:50
Wizzupfreemangordon: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/116:50
freemangordonyes, what I see here is most of the code has been removed16:51
freemangordonno wonder it does not work16:51
freemangordonbtw, who is supposed to set the in-call  volume ?16:52
uvosthe slider dose16:52
freemangordonhow?16:53
uvosit waits for mce to send the incall event16:53
uvosand then restores the stream and sets it16:53
freemangordonwhere does it get the volume to set from?16:53
uvosthe restore feature is gohne16:53
freemangordonwhy?16:53
uvosbecaus ucm dose so allready16:53
uvosits redundant16:53
freemangordonbut does ucm have separate volumes for separate roles?16:54
uvosyes16:54
uvosfor eatch profile16:54
freemangordon*roles*?16:54
uvosprofiles are roles in ucm16:54
uvosa profile is a configuration for some application16:54
uvosie music noticifacion call etc16:54
Wizzupright, but the volume applet doesn't act on profile changes whereas the previous code did, so that's why this bug now exists I think16:54
uvosright beacuse it dosent restore itself16:54
WizzupLooking at the deleted set_volume_timeout16:54
uvosbet it never acted on external event16:54
freemangordonmaybe applet shall subscribe somehow to profile change events?16:55
freemangordonsure it did16:55
uvosno it didnt16:55
uvosyour missreading it16:55
freemangordonuvos: I am using it16:55
uvosanyhow yes it shal subscribe16:55
freemangordonon fremantle16:55
uvosit works beacuse it restores its OWN volumes16:55
uvosnot external ones16:55
uvosjees16:55
freemangordonok16:55
uvosso now something else restores the volume16:56
uvosthe slider just has to update16:56
freemangordonok16:56
Wizzupit has to follow what restores it16:56
freemangordonI think you can subscribe to module-restore16:56
uvosyou dont have to16:56
uvosyou can just suscribe to the volume of the stream in question16:56
freemangordonwell, you shoud subscribe to something to receive events :)16:57
uvosright16:57
rafael2khappy 2022!16:57
Wizzuprafael2k: hey16:57
Wizzuphappy new year16:57
rafael2khi there!16:57
freemangordonhi!16:57
rafael2kbought my pp keyboard today!16:57
Wizzupneat, I also bought one but I probably won't get it before I leave home for weeks16:58
rafael2kmy birthday present to myself... eheheheh16:58
Wizzuprafael2k: I was wondering why you changed kernel package name from linux-image-pine64 to linux-image-5.15.1016:58
rafael2kjust because without it, packaging failed here16:58
Wizzupso we need to fix the mobian packaging to use our name I think16:58
WizzupI figured that was the case16:59
rafael2kuhum... I just copied over our debian/16:59
rafael2kmay be I could have started using mobian debian/ folder...16:59
Wizzuprafael2k: that seems unlikely16:59
Wizzupmaybe you can explain how you build it locally16:59
rafael2kdebuild -uc -us16:59
rafael2kjust create the tarball with the source by hand17:00
WizzupI mean from what branches, etc17:01
Wizzupsince you said you 'copied the debian folder'17:01
rafael2khttps://github.com/rafael2k/pine64-kernel/commit/cf1c86ff04eaa7850087d561ad7a51cb97731a4e17:02
rafael2kfrom beowulf-devel17:03
rafael2ksorry, I forked over17:03
rafael2k:P17:03
rafael2khttps://github.com/rafael2k/pine64-kernel/tree/maemo/beowulf-devel17:03
WizzupI don't know what you mean17:04
rafael2kkernel from here: https://github.com/rafael2k/sunxi64-linux/tree/mobian-5.1517:04
Wizzupok, so you clone the mobian-5.15 branch and place our debian dir in there17:04
rafael2kbut we could fetch the source from upstream, in gitlab17:04
rafael2kyes!17:04
Wizzupare you sure debian/patches/0001-maemo-leste-quirks.patch is being a[pplied?17:05
Wizzupbecause:17:05
Wizzup-packagename=linux-image-$version17:05
Wizzup+packagename=linux-image-pine6417:05
rafael2kyes17:05
rafael2kI tested17:06
WizzupI think the answer is "no", otherwise you would not need cf1c86ff04eaa7850087d561ad7a51cb97731a4e17:06
Wizzup?17:06
Wizzupon your maemo/beowulf-devel the patch does not seem to exist17:06
rafael2khttps://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/maemo/0214-battery_level_hack.patch17:06
Wizzupthat is not the same patch17:06
rafael2k^17:06
Wizzuphttps://github.com/maemo-leste/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/0001-maemo-leste-quirks.patch17:07
rafael2kyes it does17:07
Wizzupdoes that look the same to you? :P17:07
rafael2kdid not know about that17:07
rafael2kin my kernel it is applied17:07
rafael2kfrom my branch17:07
Wizzupit is in debian/patches/series in our maemo/beowulf-devel17:07
WizzupI checked out your branch and it is not in the patches/series file17:08
Wizzupit doesn't exist17:08
rafael2kmaemo/0214-battery_level_hack.patch17:08
rafael2kyes it is17:08
Wizzup*stop*17:08
rafael2khttps://github.com/rafael2k/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/series17:08
Wizzupthe battery level thing you mention is completely unrelated17:08
WizzupI linked a different patch17:08
Wizzupplease open the link :)17:08
rafael2kah ok17:08
rafael2ksorry17:08
Wizzupnp17:08
Wizzupthis link: https://github.com/maemo-leste/pine64-kernel/blob/maemo/beowulf-devel/debian/patches/0001-maemo-leste-quirks.patch17:08
rafael2kcome back later17:08
rafael2kma birthday today17:08
rafael2k; ))17:08
Wizzupoh, shit :)17:09
Wizzuphappy bday17:09
WizzupI think I will add this patch back in17:09
Wizzupand then revert the other one17:09
Wizzupthen see if it builds17:09
rafael2kyay!17:09
rafael2kcheers!17:09
Wizzupsure, thanks17:09
Wizzuplater I have some other questiosn17:09
Wizzupbut enjoy17:09
Wizzupfreemangordon: what do you say about the volume applet changes? I think we can merge this now, build it, and then look at adding notifier17:10
Wizzups/notifier/listener/17:10
freemangordonwell, 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.c17:15
freemangordonremoving stream-restore basically means that all maemo audio infra will not function17:17
freemangordonincluding ohm policies and whatnot17:17
Wizzupright17:18
freemangordonthis is nto about updating the slider, but about lots more17:19
freemangordonso, 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 it17:20
WizzupI think I have this packaged17:20
freemangordonit would have been good if we can integrate with ucm though17:21
freemangordonbut lets look at that after we finish all the onther things we're on atm17:21
Wizzupyes, ohm and pa stuff is going to require quite some brainpower and time17:21
freemangordonmhm17:21
Wizzupright, so do we merge this and later revert some stuff?17:21
Wizzupright now we have no volume control17:21
freemangordonup to you17:22
WizzupI think I like the other changes, so I'd say yes, but maybe get the code commented rather than removed17:22
freemangordonmaybe create a separate branch with that merged17:22
Wizzupor a branch for the code we want to keep17:22
freemangordonI wonder if we can create our own ucm parser, if ucm properties are not already available somehow17:23
freemangordonbut lets not get into that now :)17:23
uvosucm is alsa17:23
uvospa is not nesscary at all17:23
uvosand yes you can read it from alsa17:23
freemangordonas I think getting audio properly will be the most complicated task we'll face17:24
uvoson everything except the n90017:24
uvoseverything should work allready17:24
uvosexcept notification volume17:24
uvoswitch is pretty easy to add17:24
uvosfunctionality wise17:25
freemangordonuvos: no, look at libplayback17:25
uvosofc using the upstream alsa stuff makes api work differenly17:25
freemangordoneverything maemo uses that17:25
freemangordonif there is upstream functionality that matches, well, maybe we can rewrite libplayback to use it. but I doubt17:26
freemangordonuvos: 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
uvosyes17:27
uvossound pauses17:27
mighty17[m]we had a public history right?17:27
uvosbecause the profile is switched pa suspends the sink17:28
uvosthis causes pause17:28
mighty17[m]ie chat logs17:28
freemangordonuvos: "sound paused" is not the same as "playback pauses"17:28
uvosthen it plays at some volume set for the new stream17:28
uvosplayback pauses17:28
freemangordonhow?17:28
uvosif the application is implemented correctly17:28
uvosgets a pa event17:28
freemangordonit is, by using libplyback17:28
uvosthis works in mpv and mpd17:28
uvosand all desktop applications generally17:28
freemangordonwho sets the priorities and classes?17:29
uvosthen the sms notification sound is played at whatever volume of the new stream17:29
uvosand the stream switches back17:29
freemangordonlook at this https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain17:29
freemangordonand https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain#Policy_Subsystem17:30
freemangordonI doubt upstream matches this17:30
freemangordonand I can assure you this work extremely well in maemo17:30
uvosif its implemend as well as the volume slider17:30
uvoshahahahahahaha17:30
uvosso right now sphone dose its own switching, this is  bad we would need soemthing to do so17:30
uvosyes this needs to take priority into acount17:31
freemangordonwell, you may find it funny, but it really works wvery well17:31
uvosbut this is the only pice we need17:31
freemangordonnot really17:31
uvosand its very small compeard to takeing the eintere legacy stack17:31
uvosyes it is17:31
freemangordonuvos: I am not going to argue17:31
freemangordonbut, to the extend it depends on me, I will resist to turning maemo-leste to a pale shadow of fremantle17:33
Wizzupsailfish also uses libplayback I think17:34
uvosthinking that just because implementaion differeng it being a "pale shadow" is the hight of folly17:34
uvoslibplayback is not the issue here17:34
uvossince we can easly port it to whatever17:34
Wizzupwhat is the issue?17:34
uvoseverything else17:34
uvos:P17:34
WizzupI don't get it17:34
sicelobtw, 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 connected17:34
sicelothey prolly just exist in the chip, and driver exports them, but that's all17:35
uvosthe n900 is a bit different17:35
uvosso it needs soemthing to redirect streams17:35
uvossince the cpu needs to copy samples about form device to device17:35
uvossomething has to do that17:35
uvosthis is indeed a bit more work17:35
uvosbut it dosent tranlate at all to mapphones or pp17:35
freemangordonuvos: you mean calls?17:35
uvosyeah, also bt17:36
freemangordonmy example was not about that, but anyway17:36
uvosright im just saying upstream has nothing for this17:36
uvosafaik17:36
Wizzupso what do we not want to pick from fremantle? I am confused17:37
Wizzupthe sink roles definitely seemed to make sense to me17:37
uvoswell the pa setup in general, ohm mostly17:37
uvosdont worry17:37
uvosill do it17:37
freemangordonuvos: please don;t17:37
uvossigh watever17:38
uvos*whatever17:38
Wizzupfreemangordon: uvos: let's be constructive here, and I would really appreciate uvos' help with the ohm stuff17:38
freemangordonuvos: even if we are to do that (remove ohm etc)...17:39
freemangordonI think we shall discuss what we want to achieve, no?17:39
freemangordonWizzup: sure17:39
uvoswell not now17:39
Wizzupwe do, and we did discuss that too, I think17:39
Wizzupbut not now17:39
Wizzupyeah17:39
Wizzup:D17:39
uvosim done with this for now17:39
freemangordonyeah, not now17:39
uvosmerge the volume slider if you like whatever17:39
Wizzupcan you fix the comment I left?17:40
sicelohttps://gist.github.com/NikkSaan/b8dec1ddb368e0d8ea7b413d8533e2ef#file-nokia-n900-dev-journal-L14317:51
freemangordonwho's that guy?17:55
freemangordonlooks like enthusiastic one :)17:55
sicelohe made some interesting ui in qml a couple of years ago, but wasn't keen on making the source public17:56
freemangordonah, I remember I saw something on youtube17:57
freemangordonsome kind of media player os something17:57
freemangordon*or17:57
siceloyes17:58
sicelothat's he17:58
sicelohttps://www.youtube.com/watch?v=_sqjKsTh1zY17:59
lelIMbackK synchronize a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste)18:16
uvosWizzup: sure18:16
Wizzupthanks18:22
WizzupI'll look at merging this tonight, waiting for the new pine64 kernel to build18:22
freemangordonWizzup: failed19:15
Wizzupfreemangordon: wtf I thought I removed that19:17
* Wizzup pushes and reruns19:18
freemangordontmlind: fyi https://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c20:14
tmlindfreemangordon: nice, i noticed :) maybe that also allows fixing the wlroots issue20:25
freemangordonwhat issue?20:41
tmlindthe errors trying to use render nodes20:43
freemangordonah20:43
freemangordonhttps://github.com/maemo-leste/sgx-ddk-um/blob/master/dbm/dbm.c#L54020:44
freemangordon:)20:44
tmlindis that the part that xcracer had to patch for exynos?20:45
freemangordonno idea20:46
freemangordonI don;t remember what he had to patch20:46
tmlindoh i see, you suggest that's why the failure is happening with the render node :)20:46
freemangordonmhm20:46
tmlindhehe ok20:46
tmlindso for exynos, there's some binary patching for omapdrm.. probably the same place20:47
freemangordonmaybe20:47
tmlindi'll give it a try for sure with wlroots20:47
freemangordonumm... the only thing that I fixed is some lame buffer allocation20:48
freemangordonso it will fail too20:48
tmlindok, but now it can be patched20:48
freemangordonah, ok20:48
tmlindas opposed to adding non-standard hacks to wlroots20:48
tmlindwell at least that's what i hope :)20:49
freemangordonyeah20:49
freemangordongoing afk, ttyl20:50
tmlindyeah me too ttyl20:50
Wizzupdoes anyone know how to provide mc-tool with parameters when adding an account?23:07
Wizzupah, got it....23:07
Wizzupis merproject git down?23:33
Wizzuphttps://git.merproject.org/mer-core/nemo-qml-plugin-messages23:33
uvos SSL_ERROR_NO_CYPHER_OVERLAP23:37
uvosGnuTLS: A packet with illegal was received.23:38
uvosWizzup: huh23:38
rafael2kthis is not ok? https://github.com/sailfishos/nemo-qml-plugin-messages/23:38
Wizzupoh they moved it again23:48
Wizzuprafael2k: btw dang that pine64 kernel builds takes a long time, how many modules did they enable23:49
Wizzupit's already going for over 4 hours23:49
WizzupI'm pretty sure we didn't have that much enabled23:49
Wizzuprafael2k: it would be good to get that down a bit in size imho23:59

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!