Friday, 2023-03-31

*** Danct12 is now known as Guest946805:10
T42<k1gen> mal: still no ideas with sound I assume?07:04
mal@k1gen I haven't had time to think about it much11:27
T42<k1gen> :(11:36
T42<elros34> I am not good at gdb but have you even tried to figure out this cryptic hex address at which pulseaudio segfault?11:53
T42<k1gen> I suppose this was addressed to mal, because I know nothing about that12:20
T42<elros34> no, he cannot do this and you can always learn.  You have device with running proccess, and /proc/<pa pid>/maps which you could use. No idea if that will be of any use but I think that is basic step to do when you gdb process and it crash at unknown place12:24
T42<elros34> Additionally your first gdb was totaly different so you could try to figure out what changed, nobody else can so this except you12:25
T42<elros34> Without any better ideas maybe it's worth to try  android_vendor_halium_hardware similar to fp4 I doubt it will help but..12:33
T42<k1gen> @elros34 thanks, I'll try that mount service12:36
T42<elros34> it's not just mount service you need to build that lib and enable back audioservice12:40
mal@elros34 I doubt the compat hal helps since there is 64-bit hal on the device already13:13
malunless of course it's broken13:13
malone possible way debug is to get some debug output from libhybris, could be some missing symbol hook13:14
mal@k1gen try running pulseaudio by added these before pulseaudio and its parameters: HYBRIS_LOGGING_LEVEL=debug HYBRIS_TRACE=1 HYBRIS_TRACE_HOOKED=1 HYBRIS_TRACE_UNHOOKED=1 HYBRIS_TRACE_DYNHOOKED=113:18
malit will generate a lot of output13:18
T42<k1gen> without gdb?13:19
malyes, no need to use gdb13:19
T42<k1gen> 834 megabytes of output :O13:34
T42<k1gen> -rw-rw-r--    1 defaultu defaultu  834.0M Mar 31 16:33 pulseaudio.debug13:34
T42<k1gen> mal: should I grep something you need or upload this to anonfiles/... ?13:36
T42<k1gen> that's the command: HYBRIS_LOGGING_LEVEL=debug HYBRIS_TRACE=1 HYBRIS_TRACE_HOOKED=1 HYBRIS_TRACE_UNHOOKED=1 HYBRIS_TRACE_DYNHOOKED=1 HYBRIS_ENABLE_LINKER_DEBUG_MAP=1 HYBRIS_USE_VENDOR_NAMESPACE=yes pulseaudio --daemonize=no -n --file=/etc/pulse/ -vvvvvvvvvv > pulseaudio.debug 2>&113:37
T42<k1gen> mal: wget
malhmm, why is it that big13:51
T42<k1gen> mal: is it even useful to you?14:32
malnot sure14:35
malwas it so that the gdb backtrace didn't change at all when you use HYBRIS_ENABLE_LINKER_DEBUG_MAP=1 ?14:36
T42<k1gen> let me run gdb with and without it. what other envs are needed?14:40
malonly the HYBRIS_USE_VENDOR_NAMESPACE=yes14:54
T42<k1gen> mal: with HYBRIS_ENABLE_LINKER_DEBUG_MAP=1:; without:
malso no difference15:08
T42<k1gen> as you can see15:09
T42<k1gen> what does this mean?15:09
malit just means that the actual issue is hidden for now15:11
T42<k1gen> even 834Mb log can't help you? that's sad15:13
T42<TheVancedGamer> is pulseaudio segfaulting?15:13
T42<k1gen> it is15:13
T42<TheVancedGamer> ```15:15
T42<TheVancedGamer> "/vendor/lib/hw/" is 32-bit instead of 64-bit```15:15
T42<TheVancedGamer> probably not fatal?15:15
T42<k1gen> ¯\_(ツ)_/¯15:15
mal@TheVancedGamer usually sound_trigger is not critical15:20
T42<k1gen> I have this lib in lib64 directory15:20
malyeah, hal library often has hardcoded paths to the 32-bit version15:21
T42<k1gen> mal: while you're here - should I try anything else? more envs or something like that15:23
malnot sure, I need to look at logcat more carefully15:25
T42<k1gen> thanks, I'll be waiting for ping15:27
malyou could try to look into the other issues on the device, wondering if you did something wrong with the vibrator or why does it not work15:28
T42<k1gen> well, I didn't do anything since last time you helped me with it15:30
malso it didn't work with the new configuration file to only set that one path?15:30
T42<k1gen> ready to provide anything that might help with debugging, as always15:30
T42<k1gen> mal: yeah, let me cat the file15:30
malfirst you need to make sure the permissions are correct for the path15:31
T42<k1gen> that's how I left things, ngfd user service starts fine, but no vibration15:33
malthat is not how I told you to change it, first of all permission of brightness is wrong, also config file should have "native.path          = /sys/class/leds/vibrator/brightness" and remove the activate_path from it15:55
malI mean group of brightness is wrong, it should be input group15:55
malnot sure if we need to define the activate_path to be empty15:57
malI think it's fine with just that one path15:57
T42<k1gen> mal: thanks for remarks on native.path, but I don't understand why brightness group is wrong, I have
maltry first to change it manually and then restart ngfd and test vibrator16:05
T42<k1gen> mal: I did as you suggested, now there is vibration, on highest power again, but this time there are interrupts. I test vibro on lockscreen with password input. before, once I pressed the first key, the device would not stop vibrating, but now when I press any key it stops for a milisecond, then continues, but it doesn't stop until echo 0 > /sys/class/leds/vibrator/brightness16:11
malare you saying to works the wrong way somehow?16:14
malwhat is the value of brightness? also check the value of duration path16:15
malalso check the activate path value16:16
malalso check debug output from ngfd16:17
T42<k1gen> value of brightness when it vibrates is 10, when it doesn't - 016:17
T42<k1gen> there is no activate or duration16:17
mal this says those paths are there16:18
T42<k1gen> well not anymore:
T42<k1gen> weird, right? :P16:19
*** phlixi is now known as Guest951016:19
*** phlixi_ is now known as phlixi16:19
T42<k1gen> yeah16:20
malso you are saying brightness doesn't become 0 by ngfd?16:20
T42<elros34> I think you should have some more parameters in /sys/class/leds/vibrator/device/ to make things even harder without proper user space driver16:20
T42<k1gen> @elros34 how did you know? :D16:21
T42<k1gen> mal: exactly16:22
malbut why16:22
T42<elros34> quick search on net, try yourself16:22
T42<elros34> and all of these params are in your driver:
mal@k1gen please get debug output from ngfd so we can see what it finds16:23
T42<k1gen> sure, give me some time, still haven't fixed these reboot problems. I should reboot first, right?16:24
malno need to reboot16:25
T42<k1gen> daemon specifies EnvironmentFile=-/etc/sysconfig/ngfd, but there is no /etc/sysconfig/ngfd16:25
malfirst "systemctl --user stop ngfd" and then as defaultuser run "ngfd --verbose"16:26
T42<k1gen> nothing but ERROR: tonegen-ausrv: ausrv: server connection failure: Connection refused16:28
T42<k1gen> there's also one WARNING: canberra: can't connect to canberra! Not available16:28
T42<k1gen> I tried triggering vibro, log doesn't show this, but it works just like last time16:29
malI'm more interested in the early messages to see what it finds16:29
T42<k1gen> same log under root16:30
maltry ngfd -vvvvvv16:31
T42<k1gen> sure, a second16:31
T42<k1gen> well that's better16:31
T42<k1gen> mal:
T42<k1gen> I entered the password mid-log, then did echo 0 > /sys/class/leds/vibrator/brightness in other ssh instance16:33
malstill not sure why it won't stop, does it start vibrating a second time if you do something?16:35
maljust to be sure, do the permissions of brightness path remain correct?16:36
T42<k1gen> didn't understand the question. do you mean that little pause on passcode key presses?16:36
T42<k1gen> -rw-rw-r--    1 system   input         4096 Mar 31 19:32 /sys/class/leds/vibrator/brightness16:37
malhow do you test the vibration?16:38
T42<k1gen> by inputting password on lockscreen16:39
T42<k1gen> didn't I explain this already? sorry, if it's my bad english16:40
malso if you press it once it will continue vibrating forever?16:47
T42<elros34> btw do you have /vendor/etc/init/android.hardware.vibra*rc or something like that?16:53
T42<k1gen> @elros3416:54
T42<k1gen> [defaultuser@flame ~]$ find 2>/dev/null /vendor/etc/init -iname android.hardware.vibra*rc16:54
T42<k1gen> /vendor/etc/init/android.hardware.vibrator-service.cs40l25.rc16:54
T42<elros34> so it has content?16:55
mal@elros34 I assume it's this
mal@elros34 wondering if there will be need to do a binder ngfd plugin at some point if we can't fix this16:58
T42<k1gen> mal: let me rephrase what I said earlier: when we started debugging vibro, vibration was constant after trigger-key, for example passcode key. no matter what I pressed after first key - device won't stop vibrating until reboot. now vibration stops when I press second, third and so on passcode keys, but it stops only for milisecond, and then continues until I execute echo 0 > /sys/class/leds/vibrator/brightness16:58
T42<elros34> I think the same but would be nice to get confirmation. Driver IC seems pretty sophisticated16:59
T42<k1gen> @elros34
mal@k1gen that is what is odd since ngfd writes 0 to that brightness path17:00
T42<TheVancedGamer> did they check it though?17:00
T42<k1gen> mal: it doesn't in my case, I checked17:01
T42<TheVancedGamer> maybe after clicking on passcode prompt check if its 0 or 117:01
T42<TheVancedGamer> oh17:01
T42<k1gen> it's 10 when vibrating17:01
malwell the code is supported to write 017:01
mal*supposed to17:01
T42<k1gen> let me check brighness permissions while device is vibrating17:01
T42<elros34> and there is no service running: pgrep -af vibra17:02
T42<k1gen> @elros34 no output17:02
T42<elros34> and you tested manual writing  to brightness without ngfd started17:02
T42<k1gen> yes, vibration strength is the same both on 1 and 1017:03
mal@elros34 that vibrator service I linked always writes 3 things when turning vibra on and one write to turn it off17:03
T42<k1gen> also, I get now where's that delay on keypress from, it happens when I write new value to brightness17:04
T42<k1gen> I feel it, it's the same length17:04
malthat brightness in that drives is on/off, no other options17:04
malso 0 should turn it off and any positive integer turns it on17:05
T42<k1gen> when device is vibrating, the permissions are the same17:05
T42<k1gen> system:input, rw rw17:05
malwondering if broken pulseaudio can do funny things17:05
malit the code in nfgd somehow it not working well in that case17:06
T42<k1gen> well it is mentioned in vvvvvv ngfd a couple times17:06
T42<k1gen> 16 times exactly17:06
malone thing to try is to patch ngfd droid plugin code to print when it's writing to those paths, not sure if that would really help though17:07
T42<k1gen> ¯\_(ツ)_/¯17:09
malcan you check what you have in /sys/class/leds/vibrator/device/cp_trigger_index17:15
T42<k1gen> 0 in rest17:16
T42<k1gen> and 0 while vibrating17:16
T42<k1gen> it's owned by system:system though17:16
T42<k1gen> @elros34 ?17:19
T42<elros34> it's from userspace driver17:19
maltry writing 32771 to that path17:20
T42<k1gen> nothing changed17:21
T42<k1gen> still max vibration that won't stop17:22
T42<elros34> how do you even test it?17:22
T42<elros34> how about you figure out how to handle it properly manually then you will use ngfd or any other service17:23
T42<elros34> If I get it right and according to driver activation looks like:  cp_trigger_index, duration, activate 1 and then to off activate 0.  WAVEFORM_LIGHT_TICK_INDEX = 9 looks like good candidate to test17:26
T42<k1gen> there is no duration file17:28
T42<elros34> it was before, maybe some mode changed17:28
T42<k1gen> do I have to follow that btw:
T42<b100dian> My understanding from the discussion above is that no existing pattern to control your device vibra matches a known one19:07
T42<b100dian> sorry, just *matches19:08
T42<k1gen> but it worked once, and worked flawlessly19:17
T42<k1gen> just like haptic touch on an iphone19:17
T42<k1gen> when I had that:
T42<k1gen> search for that link in chat history19:18
T42<k1gen> after that all attemps of making that success stay after rebooting failed19:19
T42<elros34> so if you have working configuration then what is the problem? seeting it at boot?19:26
T42<k1gen> it doesn't work anymore19:41
T42<k1gen> with exact same configuration files, it either vibrates non-stop on max power, or doesn't at all19:41
T42<b100dian> so you made some chowns before restarting ngfd?19:51
mal@k1gen that link to faq is old, native vibrator is use by default now20:01
T42<k1gen> mal: got it20:01
T42<k1gen> @b100dian: yeah, chown + chmod20:02
mal@k1gen one question about that working test you made, did your device have the android vibrator service running when it worked and could have been broken once you tried to setup the chmods and then also disabled the android side service, maybe it does some initialization?20:03
T42<k1gen> maybe. sorry, I don't remember, we debugged a lot of stuff since then20:05
malso try setting up that but don't disable the android service in the .rc, only have the chmods in .rc and then the configs for ngfd20:09
T42<k1gen> mal: it woks fine again when I: delete /usr/share/ngfd/plugins.d/60-droid-vibrator.ini; delete /usr/libexec/droid-hybris/system/etc/init/vibrator.rc; chmod g+rw /sys/devices/platform/soc/c94000.i2c/i2c-4/4-0043/leds/vibrator/activate; chmod g+rw /sys/devices/platform/soc/c94000.i2c/i2c-4/4-0043/leds/vibrator/duration; restart ngfd20:22
T42<k1gen> I didn't even know what .rc and disabled android service were you talking about, just did it by memory20:23
T42<k1gen> vibration works flawlessly now with just enough power and timings20:23
T42<k1gen> mal: once again: how do I persist this? :D20:25
malso try adding the .rc but with only the permission things20:26
malsomething like this but with correct paths and remove the last two lines
T42<k1gen> got it, lemme try20:28
T42<k1gen> only with activate and duration, right?20:29
malyes, those are enough20:29
T42<k1gen> mal: that works:
T42<k1gen> only sound and camera left!20:34
T42<k1gen> thank you for getting me this far, mal :D20:34
malremember to add the changes to config repo20:40
T42<k1gen> mal: by the way, when you said to add dummy_netd to patterns, did this mean adding something like20:54
T42<k1gen> # For cellular20:54
T42<k1gen> Requires: dummy_netd20:54
T42<k1gen> to both hybris/droid-configs/patterns/ and hybris/droid-configs/patterns/
malto like this
T42<k1gen> thanks21:03
malchecking fp4 repo can give some good ideas, same as the official devices like x10 III repos21:03
malalthough official repos have some things in a bit different way21:04
T42<k1gen> mal: can I wait for ping from you on sound if you have any ideas for me to try/test?21:04
mal@k1gen not sure when I will have new ideas for audio, I should also debug my own audio issues22:00
T42<k1gen> mal: do you know anyone else who can help me with pulseaudio segfault?22:02
mal@k1gen can you check in the folders under /lib/modules/ what .ko files there are?22:18
T42<k1gen> sure, in the morning. we live in the same timezone, you know it's late :)22:20

Generated by 2.17.1 by Marius Gedminas - find it at!