Thursday, 2024-03-21

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
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 (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 sensorfw10: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 device10:49
malneed to ask around why that sensor handling even is there10:50
malI mean why doesn't it ignore those automatically with some rules like what kind of things the event device contains10: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 bad12:05
spiiroinand even then (1) is probably not necessary12:06
Mister_Magisterso this is good?
spiiroindoing 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/ps12:07
spiiroin*correctly* recognized & handled als/ps12:08
spiiroinas a quick check you can do: mce -Tq -levent-input.c:evin_iomon_device_add --auto-exit12:08
spiiroine.g. in l500d you get something like12:09
spiiroinmce: T+0.227 N: event-input.c: evin_iomon_device_add(): /dev/input/event1: name='proximity' type=PROXIMITY SENSOR12:09
spiiroinmce: T+0.229 N: event-input.c: evin_iomon_device_add(): /dev/input/event0: name='light' type=AMBIENT LIGHT SENSOR12:09
Mister_Magistercan't lol some issue with dbus12:09
Mister_Magisterbut the config file is good?12:09
spiiroinyou need to "systemctl stop mce" first12:10
spiiroinwhether config is good depends on details12:10
spiiroinif listing like ^ has sensor evdev nodes with type=mouse|user activity|whatnot -> not ok12:10
Mister_Magisterwhat details? :P12:10
Mister_Magisterwait i stopped mce and lost ssh xd12:11
Mister_Magisteryou probably will want me to unblacklist them next :P12:12
spiiroinsurprise, surprise - they are blacklisted now ;-)12:13
Mister_Magisteri don't think i have to blacklist proximity sensor?12:14
malals and gyro seem bad12:15
* Mister_Magister what is als12:15
malambient light sensor12:15
Mister_Magisteryeah thats what i see too12:16
Mister_Magisteronly they have user activity12:16
malbut why do they have that, spiiroin any idea?12:16
malspiiroin: this evdev_trace -I
spiiroinsomething, perhaps ABS_MISC, was user activity in some context somewhere...12:18
spiiroinor possibly has ABS_X/Y but not ABS_Z -> could be 2d touch or something12:19
malspiiroin: looks like it doesn't like if there are other things in als12:19
spiiroinyeah. I'd say, nowadays, unless you have problems with proximity related things -> just blacklist all sensors12:20
malmost devices don't have event devices for sensors anyway12:21
Mister_Magisterspiiroin: so this is good? or the previous one?12:21
spiiroinwe could of course improve the heuristics, but it is already a bit brittle due legacy devices12:21
Mister_Magisterthe previous one blacklists all the sensors but only those 2 have user activity12:22
malspiiroin: there is some funny legacy stuff in mce
Mister_Magisterso i'm bit confused :P12:22
malMister_Magister: as already said blacklisting all also works, but on 2 of those are actually a problem12: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 sensors12:23
Mister_Magisteroki done12:24
Mister_Magisterspiiroin: just a question but mce doesn't have any option to set sleep method right? like outputting to /sys/power/mem_sleep?12:25
spiiroinmal: 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 remove12:26
spiiroinMister_Magister: mce supports early_suspend and autosleep. differentiation for that stuff is in libwakelock.c12:29
spiiroinautosleep uses off/mem12:29
Mister_Magisterspiiroin: 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 sleep12:30
Mister_Magisterif it doesn't have that its fine12:31
Mister_Magisterjust asking :)12:31
spiiroinyup, "not supported"12:31
Mister_Magistergotcha thanks12:31
Mister_Magisteralso i've just learned that early_suspend is not autosleep12:32
Mister_Magistercan you tell me more? which one should i be using?12:32
spiiroinwhatever kernel is already using, i.e. it is android history line thing, old devices = early_suspend, new devices = autosleep12:33
Mister_Magisteroki autosleep it is then12:33
Mister_Magistermuch love12:33
Mister_Magistermal: i don't supppose there's any script that's being ran post-dhi?12:36
malwhat do you mean?12:37
Mister_Magisteri 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 service12:38
malisn't there that droid-hal post service, add that as After in your custom service?12:40
Mister_Magisteryeah if i have to add systemd service thats no issue I was just wondering if there was better way, thanks12:41
malcheck the droid-hal post service if it has any optional things it can do12:48
Mister_Magisterwasn't working without some sleep 5 xd12:56
Mister_Magistersleep is always the solution12: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 work13:36
T42_<oleg3256> Sorry for bad quality17:27
T42_<rikolv> armv8l CPU can run aarch64 builds?17:53
T42_<Mister_Magister> no17:53
T42_<TheVancedGamer> armv8l is aarch64?17:53
T42_<Mister_Magister> no17:53
T42_<TheVancedGamer> clarify17:54
T42_<Mister_Magister> it's armv7hl17:54
T42_<TheVancedGamer> armv8l exists17:54
T42_<Mister_Magister> you can't run x64 system on x86 cpu but you can do reverse17:54
T42_<TheVancedGamer> its called arm64 little endian17:54
T42_<Mister_Magister> welcome to sfos where armv8 is armv7hl17: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.617: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_defconfig17:56
T42_<rikolv> It is normal? (re @rikolv: Yes)17:56
T42_<TheVancedGamer> no that is not17:56
T42_<TheVancedGamer> its arm64 not aarch64 in kernel17:57
T42_<rikolv> oh, arm64 (re @rikolv: $KERNEL_DIR_ARCH/aar...)17:57
T42_<rikolv> yes17:57
*** amccarthy is now known as Guest344122:44
*** amccarthy_ is now known as amccarthy22:44

Generated by 2.17.1 by Marius Gedminas - find it at!