~mungfusensei


#273 inputhandler hook broke 9 days ago

Ticket created by ~mungfusensei on ~mil/sxmo-tickets

https://git.sr.ht/~mil/sxmo-utils/commit/c81940a74e4f409e11c4095b4affc9b7fee90202#scripts/core/sxmo_inputhandler.sh

Pretty sure this commit is the culprit, as reverting it fixed the issue.

My inputhandler hook:


case "$1" in  
        "surf")  
                if [ "$2" = "back" ]; then  
                        xdotool key ctrl+h  
                        exit 0  
                elif [ "$2" = "enter" ]; then  
                        xdotool key ctrl+l  
                        exit 0  
                else  
                        exit 1  
                fi  
                ;;  
        "qutebrowser")  
                if [ "$2" = "back" ]; then  
                        xdotool key shift+h & exit 0  
                elif [ "$2" = "enter" ]; then  
                        xdotool key shift+l & exit 0  
                elif [ "$2" = "showmenu" ]; then  
                        xdotool key r & exit 0  
                elif [ "$2" = "movenextdesktop" ]; then  
                        xdotool shift+j & exit 0  
                elif [ "$2" = "moveprevdesktop" ]; then  
                        xdotool shift+k & exit 0  
                else  
                        exit 1  
                fi  
                ;;  
        "Firefox")  
                if [ $2 = "back" ]; then  
                        xdotool key shift+h & exit 0  
                elif [ $2 = "enter" ]; then  
                        xdotool key shift+l & exit 0  
                else  
                        exit 1  
                fi  
                ;;  
        *) exit 1  
esac```

I just did a fresh build of everything today, pretty sure my last build was before this commit. Everything worked fine beforehand, and reverting this commit fixes all issues.

#206 Modem appears to be too slow to wake up when receiving a call 3 months ago

Ticket created by ~mungfusensei on ~mil/sxmo-tickets

I've only recently discovered that I've been missing a lot of calls while my phone is suspended.

While suspended, if a call is incoming, the phone will blink the purple light non-stop (kinda like a neverending rtcwake), but it will not ring or notify, so there is no evidence that a call was even missed. However, I noticed that it was going to voicemail quicker than usual, as if the service itself was just giving up after being unable to find the phone or something. So I tried immediately calling again (like, right away, not waiting a minute or anything) and voila, it starts ringing and notifies and everything. If the second call doesn't immediately happen, it'll just go back to sleep, I think, and the problem starts all over.

Now, upon booting, I have been seeing this message recently: "modem-power serial1-0: AT command 'AT+QCFG="fast/poweroff"' returned ERROR"

Dunno what that has to do with it, but I figured it might be relevant. I am using this on void but as far as I know I have everything in order, as it all works well besides this issue (and other known sxmo issues like sms but whatever).

For now, I am just keeping the screenlock to screen_off rather than suspend until this can be figured out.

#184 svkbd leaves a lingering "enter" after xdm login 3 months ago

Comment by ~mungfusensei on ~mil/sxmo-tickets

It'll happen even without an xinit file. If you bring up svkbd and hit some keys before doing literally anything else, it won't happen. If you bring up the menu or open a terminal etc. without opening svkbd after a fresh login, then whatever you open will be spammed with the enter key. This is in Void, but I can't imagine that causing any issues of this type.

#185 sxmo_screenlock should just blink instead of leaving the led on while locked 3 months ago

Comment by ~mungfusensei on ~mil/sxmo-tickets

The problem is, such a lock script wouldn't work, as it's turning off the LEDs and then turning them back on once the lock initiates. Maybe some way we can work in a SCREEN_LOCK_LED environment variable somewhere, which just overrides the default behavior?

#185 sxmo_screenlock should just blink instead of leaving the led on while locked 3 months ago

Ticket created by ~mungfusensei on ~mil/sxmo-tickets

I know that the led is useful as a signal for which stage of lock you're in, but for most of us, I imagine we're only using screen_off or suspend, and we know what stage we're entering when we decide to lock it. A simple blink of the led on lock should be sufficient to be sure what stage you're entering upon lock, and then it can go away.

The led battery usage is barely anything, but it's not nothing, so might as well save where we can.

#184 svkbd leaves a lingering "enter" after xdm login 3 months ago

Ticket created by ~mungfusensei on ~mil/sxmo-tickets

I am not sure, but it appears that the input from svkbd at the xdm login is "lingering" after login. This means, whenever you open something after logging in, be it the appmenu or a terminal or whatever, it's repeatedly hitting enter. So if you open the appmenu, your first userscript will be run, etc.

The way to stop this is to bring up svkbd and hit a few buttons, and then it's back to normal. Not a huge problem, since it's only at first login and it's easy to prevent it from going haywire, but still annoying.

#174 sxmo-dwm should explicitly call busybox when running a command 3 months ago

Ticket created by ~mungfusensei on ~mil/sxmo-tickets

I'm too dumb to figure out how to make or send in a patch, but I wasn't able to kill the keyboard with the powerbutton until I changed this in sxmo-dwm.

{1, 0, XF86XK_PowerOff, spawn, SHCMD("pkill -9 $KEYBOARD || $KEYBOARD") },

to this:

{1, 0, XF86XK_PowerOff, spawn, SHCMD("busybox pkill -9 $KEYBOARD || $KEYBOARD") },

I dunno where other such cases may be hiding, but somethin' to look out for.