Mister_Magister | woohoo i'm back from ban :P | 06:32 |
---|---|---|
*** Mister_Magister is now known as Guest25229 | 06:35 | |
*** Mister_Magister_ is now known as Mister_Magister | 06:50 | |
jusa | PSA: if someone is using pulseaudio-modules-droid-hidl please note that I split the package to two separate packages, audiosystem-passthrough (https://github.com/mer-hybris/audiosystem-passthrough) and pulseaudio-modules-droid-hidl (https://github.com/mer-hybris/pulseaudio-modules-droid-hidl) with latter depending on the former. | 09:06 |
Mister_Magister | jusa: hi btw got problem when calling on different device. on loudspeaker mode person can hear himself | 09:09 |
Mister_Magister | ofc i should give u logs righte | 09:09 |
T42 | <Martensite %lastname%> (Document) https://irc.thaodan.de/.imgstore/alU50Q8pkv.mp4 | 09:47 |
T42 | <IAmPony288> Any1 have pixel 3 ? Some1 made post asking for port for 350$ | 09:52 |
T42 | <IAmPony288> https://forum.xda-developers.com/pixel-3-xl/help/dev-free-time-d-custom-rom-t3988049 | 09:52 |
Thaodan | jusa: is this a replacement for audiofingerlue? | 10:34 |
jusa | Thaodan: yes | 10:46 |
jusa | does the same thing, just a bit differently | 10:47 |
Thaodan | But better? | 10:47 |
Thaodan | I hope nothing changed for android 10 | 10:47 |
jusa | well, simpler. easier to build than audioflingerglue | 10:48 |
jusa | so if adaptation already works with audioflingerglue no point in changing but new adaptations should be easier | 10:48 |
jusa | and for QC devices with android >= 9 most likely one needs to use the new implementation anyway | 10:48 |
mal | I built the audiosystem-passthrough on nemo:devel:hw:common https://build.merproject.org/package/show/nemo:devel:hw:common/audiosystem-passthrough | 11:15 |
mal | Mister_Magister: which device was it that needed vendor.qti.hardware.camera.device@1.0 in droidmedia? fxtec? | 11:28 |
Mister_Magister | mal: i have no idea | 11:31 |
mal | Mister_Magister: you are the one who talked about that in channel logs | 11:32 |
Mister_Magister | i have no memory of that | 11:33 |
Mister_Magister | camera is working fine for us and i didn't fixed it so… yeah… | 11:34 |
mal | 14:44 < Mister_Magister> abranson: can i add vendor.qti.hardware.camera.device@1.0 to minimedia Android.mk? | 11:36 |
Mister_Magister | there was something broken with build | 11:38 |
mal | just wondering which device | 11:39 |
Mister_Magister | ah fxtec yes | 11:39 |
Mister_Magister | so hybris16 base | 11:39 |
mal | is the device repo for that somewhere? | 11:39 |
Mister_Magister | nope | 11:40 |
Mister_Magister | i mean it is on fxtec servers :P | 11:40 |
mal | I was just curious if there were any qti/camera related defines in device repo that could be used to determine if that additional lib is needed | 11:40 |
Mister_Magister | mal: like BOARD_QTI_CAMERA_32BIT_ONLY? | 11:42 |
Mister_Magister | can't see anything else | 11:43 |
mal | maybe | 11:43 |
Thaodan | jusa: is the droid side of audiofingerglue still needed? | 12:36 |
jusa | Thaodan: either use pulseaudio-modules-droid-glue+audioflingerglue OR use pulseaudio-modules-droid-hidl+audiosystem-passthrough | 12:52 |
mal | jusa: and which one to use depends on which android base is used if I understood correctly | 12:54 |
Thaodan | and which device is targeted | 12:54 |
mal | yes | 13:00 |
jusa | yes, only qcom devices need those for voice call to function | 15:54 |
jusa | Thaodan: https://github.com/mer-hybris/audiosystem-passthrough/blob/master/README.md | 15:55 |
Thaodan | jusa does it want to reuse the cross compiler that is used during kernel builds? | 15:58 |
Thaodan | https://github.com/mer-hybris/audiosystem-passthrough/blob/master/Makefile#L24 | 15:58 |
jusa | Thaodan: it's built with normal sdk compiler | 16:01 |
Thaodan | CROSSCOMPILE is a variable used for building the kernel with a cosscompiler that why I asked | 16:02 |
Thaodan | which is why it tried to build using my cross compiler that I used for the kernel build | 16:05 |
T42 | <DylanVanAssche> mal: Have you already done something for the QMI modem? Just to avoid to do the same work. | 16:32 |
T42 | <DylanVanAssche> I gave the modem a spin again, seems that SMS works fine (cmd line), calling is broken though. | 16:32 |
mal | @DylanVanAssche not yet, sorry | 16:32 |
T42 | <DylanVanAssche> mal: No need to be sorry :) Just checking in to make sure that we don't do the same work twice as with the V4L stuff ;) | 16:33 |
mal | @DylanVanAssche are you going to that the qmi work? | 16:41 |
T42 | <DylanVanAssche> mal: Maybe in the next couple of days. The Pine devices are ported except for LIMA & modem (SMS, calling, data) | 16:42 |
T42 | <DylanVanAssche> GPS is also in the modem, but we got that working already in the past | 16:42 |
mal | @DylanVanAssche just to be sure you verified the latest version of that iio code on device? | 16:44 |
T42 | <DylanVanAssche> mal: It's working fine :) Waiting for review on git.sailfishos.org | 16:44 |
mal | @DylanVanAssche ok, I started to think about the define naming again but maybe that is too much nitpicking, one of those if for input (from iio) and other is for output from sensorfw | 16:45 |
mal | just wondering if there can be confusion because of that and the naming | 16:46 |
T42 | <DylanVanAssche> mal: I think it's clear enough by prefixing it with PROXIMITY_. You know that's about the proximity sensor. | 16:47 |
T42 | <DylanVanAssche> We can improve it if the code can be cleaned up? | 16:48 |
T42 | <DylanVanAssche> when we clean up the code* | 16:48 |
mal | sure | 16:48 |
mal | @DylanVanAssche merged and tagged | 17:02 |
deathmist | mal: can you check my PR #165 for hybris-boot from late July this year? I've updated cheeseburger (OnePlus 5) mountpoints for treble & hybris >=15.1 bases (and just a moment ago added dumpling a.k.a OnePlus 5T to use same mountpoints) which both are confirmed to work on mine and others devices :) | 17:27 |
mal | deathmist: ok, does the device really have such complicates partition structure? | 17:27 |
deathmist | yep, that's all the partitions listed under "ls -l /dev/block/bootdevice/by-name/", I've thought about cleaning it up too | 17:28 |
rodrigosolari | help me | 17:29 |
mal | deathmist: sorry to bug you but could squash the commits in that pull request to one | 17:31 |
mal | deathmist: or actually maybe two is ok, at least remove the merge commit | 17:32 |
deathmist | mal: how would I do that properly? I've tried it on a test branch and succeeded in fully removing the commits from the branch with an interactive rebase and dropping the commits I merged from master earlier, but wouldn't this also remove them from the upstream master repo? I've not done something like this before so I just want to make sure I don't | 17:48 |
deathmist | mess things up :) | 17:48 |
mal | deathmist: "git rebase -i HEAD~3" and then change the two latter commits from pick to squash and then once you save the edit then it will ask for new commit message for the combined commit, I think one commit is enough in this case | 17:50 |
deathmist | sure, but what about the merge commit(s) from upstream/master? should I drop them or? | 17:51 |
mal | if you do the squash like I said it will also be gone, or should be | 17:52 |
mal | wait a moment, I will clone that and test | 17:54 |
mal | deathmist: hmm, looks like your way was a bit ugly, trying to see how to fix it | 17:55 |
mal | deathmist: usually rebasing is preferred over merging | 17:55 |
deathmist | yeah I accidentally merged from upstream and realized later that it was the PR branch :/ | 17:56 |
mal | deathmist: run "git rebase upstream/master" | 17:56 |
mal | that will make the merge commit go away | 17:57 |
deathmist | mal: I tested on another branch and it seems to be exactly what we need! now when I push to "origin cheeseburger-treble" instead tho it wants me to pull, should I just force push? | 18:03 |
mal | git push --force | 18:04 |
deathmist | aand it's gone! I'm learning slowly to master git as well :D | 18:05 |
mal | git can be confusing sometimes | 18:05 |
vknecht | saw that recently, might help some day: https://ohshitgit.com/ :-) | 18:05 |
mal | nice :D | 18:07 |
deathmist | mal: I assume the PR is now in a good state and we don't need to merge the treble update and dumpling commit into one? :p | 18:15 |
mal | deathmist: merged | 18:24 |
deathmist | mal: awesome, thanks! another thing I just remembered is droidmedia PR #11 (conditional AudioPolicyService startup), which my and many others devices have needed for a long while was approved by abranson a few days ago but still not merged yet | 18:53 |
Mister_Magister | deathmist: i use that website a lot :P | 19:00 |
mal | deathmist: I forgot to merge that droidmedia PR | 19:11 |
mal | deathmist: droidmedia is also merged and tagged now | 19:17 |
Thaodan | talking about droidmedia: is MiniSurfaceFlihnger an abstract class? | 19:44 |
Thaodan | I'm getting this error while building libminisf: allocating an object of abstract class type 'MiniSurfaceFlinger' | 19:46 |
Thaodan | return sm->addService(String16(SERVICE::getServiceName()), new SERVICE(), allowIsolated, | 19:46 |
mal | Thaodan: you mean for android 10? you need to add suitable services file, you can find the old ones in services folder | 19:53 |
mal | in case you haven't done it already, just copy the android 9 version and then adapt to API changes | 19:53 |
Thaodan | mal: found my error missed to implement some new services | 19:54 |
Thaodan | eh methods | 19:54 |
mal | yes, usually some methods needs to be added or modified | 19:55 |
Thaodan | is there a reason argument names missing or this there some kind of generator? Its just C&P and removing the argument names adds extra work. | 19:55 |
mal | this is the first time in a long time when I'm not the one adapting to new android base | 19:55 |
Thaodan | is that a good thing? :D | 19:56 |
mal | well in a way it might have been faster if I did it since I have quite much experience | 19:56 |
mal | Thaodan: what do you mean? the file was made manually | 19:56 |
Thaodan | feels like a deep dive through SFOSs inner workings. | 19:56 |
mal | always just the previous android version service file is taken as the base and modified where needed | 19:57 |
Thaodan | I means generating this file since its pretty much just taking the header and adding something like return 0 | 19:57 |
mal | Thaodan: mostly yes but it has many classes there | 19:58 |
mal | and some are not just return 0, most are, easier to copy than make a script | 19:58 |
T42 | <adampigg> Well, that was a digital detox kinda day, accidentally left my phone at home! | 19:59 |
mal | Thaodan: do you have those changes somewhere in your github? | 20:01 |
Thaodan | mal: I got them on github | 20:14 |
Thaodan | I forked the mer/sailfishos repos I needed to edit. | 20:14 |
T42 | <DylanVanAssche> Mal: thanks! | 20:57 |
mal | @DylanVanAssche were those all for now, I'll remove sensorfw from dontbeevil repo because I added that new version to native-common | 21:00 |
T42 | <adampigg> Neat | 21:02 |
T42 | <DylanVanAssche> mal: all sensors are working now, we can use them from the common repo for now :) | 21:05 |
mal | @DylanVanAssche what sensors does it have? do we need to implement compass in sensorfw using sensor fusion or something | 21:11 |
T42 | <DylanVanAssche> mal: Compass is already in there (magnetometer). The scaling is wrong according to the kernel ABI docs and my own measurements from the Xperia X. The PinePhone has: accelerometer, gyroscope, magnetometer, als and proximity sensor. If you count GPS also as a sensor, then also GPS | 21:17 |
mal | @DylanVanAssche actual compass direction is usually calculated from magnetometer, accelerometer and gyroscope (if available) | 21:19 |
mal | @DylanVanAssche if you look at some compass app that is available in store then you can see that compass is probably not seen for your device | 21:20 |
mal | @DylanVanAssche I have such a virtual sensor on my endless todo list | 21:21 |
T42 | <DylanVanAssche> Oooh I haven't tested that yet, will do. But that's not urgent, the modem is since withoit sms/calling/data I can't use it as daily driver | 21:21 |
Thaodan | mal: this are my changes to droidmedia | 21:35 |
Thaodan | https://github.com/Thaodan/droidmedia/tree/android_10 | 21:35 |
mal | looks reasonable | 21:48 |
mal | Thaodan: some inconsistency, you still make 10 include libmediaextractor folder but don't add that as lib, is the include needed? | 21:51 |
mal | of course the include might not cause any problems | 21:52 |
Thaodan | mal: doesn't cause problems but I removed it. | 22:05 |
Thaodan | the last error is this: frameworks/native/include/android/looper.h:47:16: error: reference to 'ALooper' is ambiguous | 22:08 |
Thaodan | triggered by including in #include <sensor/Sensor.h> included in the android 10 services file | 22:08 |
Thaodan | should it be the stagefright variant or the stagefright variant of that type? | 22:10 |
Thaodan | Apperantly stagefright implements its own ALooper overring the struct from looper.h | 23:11 |
mal | maybe you need to include something else then | 23:13 |
MSameer | wow! droidmedia is still alive after all those years? :) | 23:16 |
mal | MSameer: it is :) | 23:17 |
Thaodan | mal: the issue is that other stagefright headers are included that may include ALooper | 23:17 |
MSameer | mal: seems so :) | 23:18 |
Thaodan | from stagefright | 23:18 |
mal | MSameer: for newer android bases there could be optional ways to do it using direct binder communication using libgbinder | 23:18 |
Thaodan | On android 8+? | 23:20 |
MSameer | mal: you are the expert here. we did not have those long ago (or I did not know). but of course if there is better usable API then it'd be better | 23:21 |
Thaodan | I'm not the expert here after seen the other changes the way using those interfaces via binder is less invasive | 23:22 |
Thaodan | Because the binder interfaces are public interfaces that don't change so much compared to building directly on top | 23:23 |
MSameer | it is always a trade off. easier/public interfaces vs code size | 23:25 |
mal | MSameer: that new way came with the treble feature in android, so a stable API for many things | 23:25 |
MSameer | code size loaded in ram | 23:25 |
MSameer | +1 :) | 23:26 |
mal | MSameer: we use those binder interfaces already for things like modem, gps, sensors etc | 23:26 |
mal | for android 8+ devices | 23:27 |
mal | from the main hw features audio and camera/codecs are the ones left not using that | 23:27 |
Thaodan | I hope that more features get mainlined and uses less binder services if possible. | 23:28 |
MSameer | mal: media code is not small unfortunately. not that easy to port | 23:29 |
MSameer | or not that trivial rather | 23:30 |
mal | MSameer: yes, that is the reason why we haven't tried that yet | 23:30 |
MSameer | but you are doing a great job :) | 23:30 |
MSameer | the problem is backward compatibility | 23:32 |
MSameer | that's if you still need to support jolla1 phone :P | 23:32 |
Thaodan | For Android <8 yes | 23:32 |
Thaodan | Im interrested in seeing more changes | 23:33 |
mal | MSameer: yep, we need to keep droidmedia quite long time for the current devices | 23:46 |
Thaodan | mal: do you have an idea? https://invent.kde.org/snippets/506 | 23:46 |
mal | Thaodan: not right now, it's quite late already | 23:48 |
Thaodan | thats ok, I know its late. Sometimes it hard to stop when you onto something and time goes by :D | 23:53 |
mal | I know :) | 23:54 |
Thaodan | what keeps you up? | 23:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!