Thursday, 2022-06-30

T42<edp_17> @elros34 : I wasn't sure, so I tried both (KERNEL and KERNELS). The result is the same, after reboot permission still system:system06:54
T42<elros34> If we assume rule works (you could try to write some tmp file in that rule to be sure) then something overwrites this behavior. Have you checked init*rc files in /system or /vendor?06:56
T42<edp_17> Yes, I've checked /system and /vendor, there is no init*rc file in there. I'll try that you suggested (tmp file).07:01
T42<elros34> here is service file I used to debug race on my device together with systemd-analyse plot > boot.svg , there is probably better way to do this..:
T42<edp_17> Thank you!07:04
T42<edp_17> tmp file wasn't created, so that udev rule didn't make effect.07:07
T42<elros34> so use that service file, it will generate flood of messages but at least you will be sure what events you got07:07
T42<edp_17> Does it matter how I name the rule? Is that number at the end of name is an order to run it?07:08
T42<edp_17> I'll use the service now.07:08
T42<elros34> I think name shouldn't matter for your case, you are not overriding any other rule07:10
T42<edp_17> I see, thanks.07:15
T42<edp_17> udev_monitor.log :
T42<edp_17> I also used systemd-analyze plot > /boot.svg07:18
T42<elros34> see timed_output appears somewhere at 24s, maybe try only: SUBSYSTEM=="timed_output", TAG+="systemd" and then RUN commands. After that generate plot07:20
T42<edp_17> There is another one around 22s07:22
T42<elros34> ah I see you use 102- in file name, IFAIK this will not work like you expect, please use 99 for example07:30
T42<edp_17> Do you know why doesn't work with file name 102-?07:39
T42<edp_17> I also have other rules with name 100-* and 100-* and they do work.07:39
T42<elros34> I meant that AFAIK they are not parsed after 99-rules but before, this can cause issues but most likely not in your case07:40
T42<edp_17> Ah, ok, I see. Good to know when I add a new rule. :)07:41
T42<elros34> so did you generate plot after adding systemd tag?07:42
T42<edp_17> No, it was before. Since then I am renaming the rules for getting the tmp file generated. No luck so far.07:46
T42<edp_17> Yeah, it doesn't matter if I named the rules 99*, they do not generate files.07:47
T42<edp_17> These are the rules:
T42<elros34> so even with simple rule like: 'SUBSYSTEM=="timed_output", TAG+="systemd"' you do not have anything in : systemctl | grep timed? THis is not shell I am not sure  redirection will work >07:50
T42<elros34> echo also might not work, must be /bin/echo. That is why I told you to add systemd tag then it would be obvious in plot or systemct output07:51
T42<edp_17> Oh, I see. this is systemctl | grep timed :
T42<edp_17> So, files cannot be created this way. how about using touch? Would that work better?07:53
T42<elros34> touch is always the best way for debugging. So if there was no sys-devices-virtual-timed_output-vibrator.device previously then rule works, please show now plit07:54
T42<elros34> plot*07:54
T42<edp_17> It is 190kb, don't think I can upload it to paste.ubuntu. How can I share it with you?07:56
T42<edp_17> I'll load them up to github. Give me a second.07:58
T42<elros34> ok I need to go so please compare plot with ngfd start time. You should see when devices-virtual-timed_output-vibrator.device appears and with some systemctl-user magic you need to find out when ngfd starts07:59
T42<edp_17> No worries. Thanks for your help.08:01
T42<edp_17> I've uploaded the plots, boot.svg before TAG+ was added and boot2.svg after.
T42<edp_17> sys-devices-virtual-timed_output-vibrator.device appears a bit before 25s08:07
T42<edp_17> Once you back please tell me about the systemctl-user magic you were referring to. :)08:07
T42<elros34> so looks like it's way before user session (and ngfd) starts so make sure rules works and change permissions08:38
T42<edp_17> Interestingly, rules does work as when added touch, it generated the tmp file. However, it doesn't change the permission to system:input or something else changes that back to system:system later.09:43
T42<edp_17> I have this rule but permission remains system:system after reboot:09:43
T42<edp_17> SUBSYSTEM=="timed_output", TAG+="systemd",  RUN+="/bin/chown system:input /sys/class/timed_output/vibrator/enable"09:43
T42<nephros> You could try to replace the RUN+= with a script in which you do more stuff like test for existence, ls -l etc, and log it to a file.10:09
T42<edp_17> @nephros : Thanks for the idea.11:07
T42<edp_17> It seems something changes permission to system:system later in the start process.11:07
T42<edp_17> I've created a script that logs the permission, changes it to system:input, then logs it again. In that 99* rule, instead of the chmod I run this script. After boot I've found two permissions in the log file.11:10
T42<edp_17> 1. root:root11:10
T42<edp_17> 2. system:input11:10
T42<edp_17> So, the rule (and script worked). However, if I check the permission now, it is system:system.11:10
T42<edp_17> So, there is something else that runs after that rule and changes the permission.11:11
T42<Spidey24Z> Could you please send a package? (re @nephros: I have built qpa-sur...)11:17
T42<Spidey24Z> @elros34 I patch MCE but didn't help11:17
T42<nephros> Can't build at the moment, there might be one on OBS though. Let me check. (re @Spidey24Z: Could you please sen...)11:39
T42<nephros> no idea if it is useful though11:41
T42<edp_17> Okay, I've found the way to restart all those services. :) I know it's a hack but will come back to it later.13:25
T42<edp_17> Can I get a little help with routing audio to the headset?13:25
T42<edp_17> I have /dev/input/event18 which is "apq8064-tabla-snd-card Headset Jack" and also have /sys/class/switch/h2w/state that reacts on headset plugged in.13:26
T42<edp_17> However, any of them defined in /etc/ohm/plugins.d/accessories.ini, audio is not routed to headset. :(13:26
T42<Spidey24Z> thank i install it but it didn't work (re @nephros: https://build.sailfi...)13:28
T42<Spidey24Z> thanks i install it but it didn't work (edited) (re @nephros: https://build.sailfi...)13:28
T42<Spidey24Z> when i run minimer it segfault13:29
T42<Spidey24Z>  EGL_PLATFORM=hwcomposer /usr/lib64/qt5/bin/qmlscene -platform surfaceflinger /minimer/main.qml13:29
T42<Spidey24Z> cannot locate symbol "_ZN7android21SurfaceComposerClient17getBuiltInDisplayEi" referenced by "/usr/libexec/droid-hybris/system/lib64/"...13:30
T42<Spidey24Z> Segmentation fault (core dumped)13:30
ThaodanI think we mean init/*.rc13:36
Thaodane.g. find /vendor /system -name \*.rc -exec grep -H <term> {} \;13:36
dcalisteHello porters, if I would like to add a new HAL interface to a manifest, so it can be picked up by hwservicemanager in aliendalvik, which file should I touch ?14:28
dcalisteI tried to add it under /host_vendor/etc/vintf/manifest/foo.xml but after aliendalvik restart, it seems to not be picked up by hwservicemanager that complains that foo cannot be find in manifest or framework…14:29
Thaodandcaliste: why do you want to do that?16:14
T42<elros34> @Spidey24Z you must build it yourself in platform sdk16:56
T42<elros34> @edp_17 you could mask droid-hal-init/user@10000 then start only droid-hal-init. If that change permission to system:system then it must be *rc file (or script executed by *rc) somewhere on device16:58
Thaodanwhy are you using the qpa-surfaceflinger?17:11
T42<Spidey24Z> do i need a full source for building it ? (re @elros34: @edp_17 you could ma...)17:13
T42<elros34> at least droid-hal/lihybris/... rpms17:14
T42<elros34> @edp_17 ah don't you use some waydroid or something like that which starts and change permissions?17:22
T42<edp_17> @elros34 : Not yet. On this install I haven't installed waydroid. I've tested that on an older image. Altghough, lxc container and a desktop debian in it is installed.20:28
T42<edp_17> But I start that guest os manually, so there is no service like in waydroid.20:29
T42<edp_17> I'd like to use waydroid but first want to fix some stuff like audio, bluetooth, camera and video playing/recording.20:31
T42<Umeaman> Building hybris-hal and droid-media fails with this error:
T42<Umeaman> As you can see I'm fully up-to-date otherwise.22:35
T42<Umeaman> Any workaround?22:36
T42<Umeaman> I know I can remove projects from my manifest, but it's not my manifest the problem lies in.22:38
ThaodanYou can remove projects in device.xml since it is sourced as local manifet23:01
ThaodanSony does the same23:01
ThaodanE.g. see here:23:02
T42<Umeaman> Thaodan: Shouldn't that be in the HADK then?23:05
T42<Umeaman> In case someone gets the same error.23:05
ThaodanIt's more of an edge case23:09
ThaodanAlso it's more an Android issue than a SailfishOS issue.23:10
T42<Umeaman> Right.23:14
T42<Umeaman> What about the patch step? It's removed from the HADK...... isn't it mandatory to do the patches regardless of make and model?23:15
Thaodanwhat patch step, do you mean hybris patches?23:31
T42<Umeaman> Thaodan: Yes.23:46

Generated by 2.17.1 by Marius Gedminas - find it at!