On Fri Dec 20, 2024 at 1:29 PM CET, ~baroque0 wrote:

When your pocket DDoSes peanutbutter! Device gets warm and battery drains while it doesnt go back to suspend.

Hmm... If it doesn't go back to suspend that means it very regularly receives keeps receiving touches right? Otherwise it should have suspended after a while again.

Steps to reproduce:

• Turn device on while on suspend.
• insert back in pocket and make sure it is pressed against your.
• resume a normal life.

-> a high number of inputs will be registered, thus triggering the red screen of no-input.

-> if -p option has been used, red time will increase over time

-> device doesnt go back to suspend.

suggested solution:

• when in "red" mode, time should be counted as idle, and after a while device goes back to sleep. (when resuming, the timer of the red mode is either resumed -better- or reset -easiest-)

I think it's the compositor itself from which tools like swayidle get their idle info. So if there's a touch in peanutbutter we can't discount it. One thing we might be able to do is disable touch entirely during the 'red phase' and re-enable it afterwards (and if it's long enough we have the suspend in between).

another suggested solution:

• one click on power is just "screen on"
• 2nd click on power activates input to unlock peanubutter

That's more or less the old behaviour, I don't really want to go back to that.

Of course you can also just ensure to press the power button so the screen is off before you put the device back in your pocket ;) (except if the power button gets pressed accidentally again whilst in your pocket)

When your pocket DDoSes peanutbutter! Device gets warm and battery drains while it doesnt go back to suspend.

Steps to reproduce:

• Turn device on while on suspend.
• insert back in pocket and make sure it is pressed against your.
• resume a normal life.

-> a high number of inputs will be registered, thus triggering the red screen of no-input.

-> if -p option has been used, red time will increase over time

-> device doesnt go back to suspend.

suggested solution:

• when in "red" mode, time should be counted as idle, and after a while device goes back to sleep. (when resuming, the timer of the red mode is either resumed -better- or reset -easiest-)

another suggested solution:

• one click on power is just "screen on"
• 2nd click on power activates input to unlock peanubutter

It seems like it happened after latest pipewire update (3.77), on pmos edge. calls are unusable, with a strange twist. Steps to reproduce:

• place a call -> after a long while, notifcation "we failed to disable speaker." then we failed to enable speaker" -> an "Incall Menu" item is in sxmo menu, with what seems to be an outgoing (ghost) call.
• hit "hang up. -> "we failed to hangup the call"

-> a new call is placed to the requested number, and this time things work!

(variations of this scenario occur... very mysterious)

comment by hazardchem:

maybe have a template that is called at the start and end of a be/dmenu script? that way the wheel doesnt need to invented each time

maybe apart of sxmo_common?

i really appreciate phartman's patch that puts "close menu" on top of the network menu!

It was needed for me (to the extent that i was removing older wifi networks to shorten the menu..) but now we're in that weird situation:

in "networks", the "close menu" option is on top, while in all others it is at bottom... but for some other menus (config, apps, scripts) it can become the case that the list is too long, same problem etc..

how about that:

• every sxmo menu (except some exceptions like system menu of course) have "system menu" / "close menu" as their two first entries? It could be done in a generic way?

could also be "close menu" / "system menu" in that order... point be: 1/ these two elements should be in all menu, ideally along with a "back" option, but probably harder to implement 2/ having them at predictable spot would greatly simplify navigation (ie. always on top) 3/ putting them on top would give them equal visibility/accessbility in all cases...

If anyone (~baroque0) wants to help creating SVG icons, see https://todo.sr.ht/~earboxer/statusbar to see what additional icons I wanted to add before sending my next iteration of the patch.

had twice, after upgrading to git head on Saturday, an incoming phonecall from an unknown number where instead of the number was displayed "--".

I cannot find trace of the actual number (.local/share/sxmo/modem/modemlog.tsv displays "--" as well as every call menu etc.).

Is there a quick/easy fix for that?

Also if ssh runs on non-standard port...

Thanks for clarifying!

I don't know if it's a side-effect of the "roundtrip", but as you suggested on other ticket, i added prefset_n distance_unit_tf_km_mi 1; to .mepo/config and launched it again... and it didnt change a thing.

i decided i would cat .mepo/config >> /home/user/share/mepo/savestate, as to try the "roundtrip" alright... and indeed it worked! ;)

so it still feels the savestate could leave a little bit of room to certain cases.... ;)

by all means, keep up the good work!!

It happens that mepo uses some units that very few people in the world use, that are not even divisible neatly by 100!!!

steps to reproduce:

• define a pin
• move the view away from the pin
• read: "Dist: 2.96mi away"

joke aside, is there a way to swich mepo to use units that are almost universally used and that make sense? ;)