| T42_ | <elros34> I did nothing but anyway I am interested about blacklisting proximity. Isn't it needed for example in lockscreen for /system/osso/dsm/locks/proximity_blocks_touch=true or some other features? | 00:11 |
|---|---|---|
| mal | @elros34 you might want to have a look at https://github.com/sailfishos/mce/blob/master/mce-sensorfw.c | 00:38 |
| T42_ | <oleg3256> System dont want boot when i just power on (stuck on boot) and im using actdead what doesn't work and start system then its boot normal (re @b100dian: @oleg3256 actdead sh...) | 04:31 |
| T42_ | <AntonlX> Looks here https://paste.opensuse.org/pastes/e0cca9ca7668 (re @b100dian: @AntonlX how did the...) | 06:44 |
| T42_ | <AntonlX> Founds out that it was problem with removed libraries in los. (re @AntonlX: Looks here https://p...) | 08:11 |
| T42_ | <elros34> mal: I had light-prox detected as "USER ACTIVITY ONLY", blacklisted it and it's good so far. Is this always true and one should blacklist or I guess override evdev type detection for such a sensors because they are processed through sensorfw | 10:04 |
| T42_ | <elros34> ? | 10:04 |
| mal | @elros34 afaik yes, sensor event devices are not needed in mce so blacklisting would minimize any chances of issues, it's quite rare to have those sensor event devices on a device | 10:49 |
| mal | need to ask around why that sensor handling even is there | 10:50 |
| mal | I mean why doesn't it ignore those automatically with some rules like what kind of things the event device contains | 10:50 |
| spiiroin | @Mister_Magister: short version is: 1) mce reading correctly recognized & handled als/ps from evdev is good; 2) mce reading any other sensors from evdev is bad | 12:05 |
| Mister_Magister | oki | 12:05 |
| spiiroin | and even then (1) is probably not necessary | 12:06 |
| Mister_Magister | so this is good? https://github.com/sailfishos-on-sake/droid-config-sake/commit/c12988d48947707ccb16b85a8cc04982e5358069 | 12:06 |
| spiiroin | doing als/ps from evdev was necessary back in J1 days as: it provided naturally suspend proofed data channel for mce + worked around sensorfwd at the time having problems with initial values of als/ps | 12:07 |
| spiiroin | *correctly* recognized & handled als/ps | 12:08 |
| spiiroin | as a quick check you can do: mce -Tq -levent-input.c:evin_iomon_device_add --auto-exit | 12:08 |
| spiiroin | e.g. in l500d you get something like | 12:09 |
| spiiroin | mce: T+0.227 N: event-input.c: evin_iomon_device_add(): /dev/input/event1: name='proximity' type=PROXIMITY SENSOR | 12:09 |
| spiiroin | mce: T+0.229 N: event-input.c: evin_iomon_device_add(): /dev/input/event0: name='light' type=AMBIENT LIGHT SENSOR | 12:09 |
| Mister_Magister | can't lol some issue with dbus | 12:09 |
| Mister_Magister | but the config file is good? | 12:09 |
| spiiroin | you need to "systemctl stop mce" first | 12:10 |
| spiiroin | whether config is good depends on details | 12:10 |
| spiiroin | if listing like ^ has sensor evdev nodes with type=mouse|user activity|whatnot -> not ok | 12:10 |
| Mister_Magister | what details? :P | 12:10 |
| Mister_Magister | wait i stopped mce and lost ssh xd | 12:11 |
| Mister_Magister | spiiroin: https://paste.opensuse.org/pastes/95d3d45cfa1c | 12:12 |
| Mister_Magister | you probably will want me to unblacklist them next :P | 12:12 |
| spiiroin | surprise, surprise - they are blacklisted now ;-) | 12:13 |
| Mister_Magister | :) | 12:13 |
| Mister_Magister | https://paste.opensuse.org/pastes/f6c111d1c326 | 12:13 |
| Mister_Magister | i don't think i have to blacklist proximity sensor? | 12:14 |
| spiiroin | yup | 12:15 |
| mal | als and gyro seem bad | 12:15 |
| * Mister_Magister what is als | 12:15 | |
| mal | ambient light sensor | 12:15 |
| Mister_Magister | yeah thats what i see too | 12:16 |
| Mister_Magister | only they have user activity | 12:16 |
| mal | but why do they have that, spiiroin any idea? | 12:16 |
| mal | spiiroin: this evdev_trace -I https://paste.opensuse.org/pastes/1389b02c67d8 | 12:16 |
| spiiroin | something, perhaps ABS_MISC, was user activity in some context somewhere... | 12:18 |
| spiiroin | or possibly has ABS_X/Y but not ABS_Z -> could be 2d touch or something | 12:19 |
| mal | spiiroin: https://github.com/sailfishos/mce/blob/master/event-input.c#L1544 looks like it doesn't like if there are other things in als | 12:19 |
| spiiroin | yeah. I'd say, nowadays, unless you have problems with proximity related things -> just blacklist all sensors | 12:20 |
| mal | most devices don't have event devices for sensors anyway | 12:21 |
| Mister_Magister | spiiroin: so this is good? https://github.com/sailfishos-on-sake/droid-config-sake/commit/a4d9df6629f1a47a938e37c575d3172b2247a590 or the previous one? | 12:21 |
| spiiroin | we could of course improve the heuristics, but it is already a bit brittle due legacy devices | 12:21 |
| Mister_Magister | the previous one blacklists all the sensors but only those 2 have user activity | 12:22 |
| mal | spiiroin: there is some funny legacy stuff in mce https://github.com/sailfishos/mce/blob/master/mce-conf.c#L472 | 12:22 |
| Mister_Magister | so i'm bit confused :P | 12:22 |
| mal | Mister_Magister: as already said blacklisting all also works, but on 2 of those are actually a problem | 12:23 |
| spiiroin | @Mister_Magister: both ok, depends on whether you want minimalistic or holistic config. I'd perhaps do the latter i.e. blacklist all sensors | 12:23 |
| Mister_Magister | oki done | 12:24 |
| Mister_Magister | spiiroin: just a question but mce doesn't have any option to set sleep method right? like outputting to /sys/power/mem_sleep? | 12:25 |
| spiiroin | mal: you can think it in terms of sw development back in nokia days: fork for new device, add hardcoded stuff. then X years later it is a bit hard to remove | 12:26 |
| spiiroin | Mister_Magister: mce supports early_suspend and autosleep. differentiation for that stuff is in libwakelock.c | 12:29 |
| spiiroin | autosleep uses off/mem | 12:29 |
| Mister_Magister | spiiroin: ye i was more talking about changing the mem type, autosuspend changes /sys/power/autosuspend to off/mem but i need to change /sys/power/mem_sleep as in type o the sleep | 12:30 |
| Mister_Magister | if it doesn't have that its fine | 12:31 |
| Mister_Magister | just asking :) | 12:31 |
| spiiroin | yup, "not supported" | 12:31 |
| Mister_Magister | gotcha thanks | 12:31 |
| Mister_Magister | also i've just learned that early_suspend is not autosleep | 12:32 |
| Mister_Magister | can you tell me more? which one should i be using? | 12:32 |
| spiiroin | whatever kernel is already using, i.e. it is android history line thing, old devices = early_suspend, new devices = autosleep | 12:33 |
| Mister_Magister | oki autosleep it is then | 12:33 |
| spiiroin | yes | 12:33 |
| Mister_Magister | thanks! | 12:33 |
| Mister_Magister | much love | 12:33 |
| Mister_Magister | mal: i don't supppose there's any script that's being ran post-dhi? | 12:36 |
| mal | what do you mean? | 12:37 |
| Mister_Magister | i need to do "echo deep > /sys/power/mem_sleep" after droid-hal-init and i'm wondering what is the best way of achieving that short of another systemd service | 12:38 |
| mal | isn't there that droid-hal post service, add that as After in your custom service? | 12:40 |
| Mister_Magister | yeah if i have to add systemd service thats no issue I was just wondering if there was better way, thanks | 12:41 |
| mal | check the droid-hal post service if it has any optional things it can do | 12:48 |
| Mister_Magister | wasn't working without some sleep 5 xd | 12:56 |
| Mister_Magister | sleep is always the solution | 12:56 |
| T42_ | <elros34> can I mark ps/als which is one evdev device as proximity and als sensor so mce uses it instead sensorfw? I had some rare issues with initial value of proximity sensor and I use even modified sensorf plugina and some quirks for it. I have tried 'light-prox=PS;ALS' in mce ini file but this doesn't work | 13:36 |
| T42_ | <oleg3256> https://photos.app.goo.gl/hk2EkjPSVQg9G6MG8 | 17:27 |
| T42_ | <oleg3256> Sorry for bad quality | 17:27 |
| T42_ | <rikolv> armv8l CPU can run aarch64 builds? | 17:53 |
| T42_ | <Mister_Magister> no | 17:53 |
| T42_ | <TheVancedGamer> armv8l is aarch64? | 17:53 |
| T42_ | <Mister_Magister> no | 17:53 |
| T42_ | <TheVancedGamer> clarify | 17:54 |
| T42_ | <Mister_Magister> it's armv7hl | 17:54 |
| T42_ | <TheVancedGamer> armv8l exists | 17:54 |
| T42_ | <Mister_Magister> you can't run x64 system on x86 cpu but you can do reverse | 17:54 |
| T42_ | <TheVancedGamer> its called arm64 little endian | 17:54 |
| T42_ | <Mister_Magister> welcome to sfos where armv8 is armv7hl | 17:54 |
| T42_ | <rikolv> hah, I was configured build for aarch64, this is my error. I will rebuild it now. but my kernel config is located on $KERNEL_DIR/arch/arm64/... | 17:54 |
| T42_ | <adampigg> not any more past 4.6 | 17:55 |
| T42_ | <Mister_Magister> u sure? | 17:55 |
| T42_ | <rikolv> I know, but I was surprised bcoz config location... (re @Mister_Magister: you can't run x64 sy...) | 17:55 |
| T42_ | <adampigg> arnt new releases going 64bit only? | 17:55 |
| T42_ | <rikolv> Yes (re @Mister_Magister: u sure?) | 17:55 |
| T42_ | <Mister_Magister> you tell me (re @adampigg: arnt new releases go...) | 17:55 |
| T42_ | <rikolv> $KERNEL_DIR_ARCH/aarch64/configs/j5y17lte_defconfig | 17:56 |
| T42_ | <rikolv> It is normal? (re @rikolv: Yes) | 17:56 |
| T42_ | <TheVancedGamer> no that is not | 17:56 |
| T42_ | <TheVancedGamer> its arm64 not aarch64 in kernel | 17:57 |
| T42_ | <rikolv> oh, arm64 (re @rikolv: $KERNEL_DIR_ARCH/aar...) | 17:57 |
| T42_ | <rikolv> yes | 17:57 |
| *** amccarthy is now known as Guest3441 | 22:44 | |
| *** amccarthy_ is now known as amccarthy | 22:44 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!