💾 Archived View for missbanal.net › status-update-2023-02 captured on 2024-08-18 at 17:13:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-06-16)
-=-=-=-=-=-=-
Published the 2023-02-25 on Willow's site
Hey there! Let's try to recap what I've done this month.
I'll keep it short this time, promised! I finally resigned. This situation was painful to me, and unnoticeable for my employers. This was going nowhere better, so I decided I'll choose how and when it will end.
I still got a two-month prior until my contract actually ends. It will continue to be painful but at least, I see the end now.
Fortunately to me, my lifestyle and personal situation don't require important revenues. So I will have months, maybe a year before it really become precarious. I'll have even more time if I manage to obtain unemployment revenue dues.
And if nothing works, well I would just knock at to some company doors, and see if they need another developer, for another proprietary ERP web suite.
I would say my mental health is way better :)
My monthly spam on the channel #sway-devel finally worked! Two Sway folks reviewed the touch seat operation implementation, and after some iteration, we had it merged.
Sway Merge Request - Implement seatop_touch
To close this topic, let's recap what it does, and why we needed it that much:
On Wayland compositors, the applications only receive events that concern their own surface. A program that is not currently focused don't receive keyboard key press, nor that they receive touch or pointer events outside their "window territory".
When I worked on sxmo to support Sway, I had to choose which dmenu like program we will use on this compositor. I chose bemenu because it was the more mature, and the more complete solution. But bemenu was not supporting pointer nor touch events yet. I had to implement those!
While coding it, I quickly noticed that the bemenu Wayland backend stopped receiving my touch motion events as soon as I was leaving its surface. It was a problem because the behaviors I was intended to implement would require those events. On sxmo menus, if you hold a touch contact, and leave the surface by the top/bottom edge, it should ask you to go to the previous/next page if you release.
What was missing: If you initiate a touch from a surface, the futures events related to this touch (motion or release), should continue to be noticed to the initial surface. Touch position should be relative to the surface. Also, x and y could be negatives or higher than the surface weight or height.
In the Sway nomenclature, it is called a seat operation. Touching a surface should initiate this kind of operation, and make next events to behave differently. This is what the Sway merge request is all about!
This week I also took time to test the master branch of bemenu. I saw they implemented two features that we will really appreciate on sxmo, border and fixed height.
I haven't much to say about borders. This make the bemenu surface more visible while above other terminals. I just noticed they somehow failed to render correctly the right border. It took me some minutes to figure out they forgot to compute the width using the correct scaling value. It means the right border actually was far away outside the surface.
Now let's speak about the fixed height. Previously, bemenu height was recomputed while the entries count was shrinking with filters. It was unpractical on desktops cause the filter line and results was moving on almost every keystroke. And then on mobile it was also unpractical cause filtering was shrinking the height so that it became painful to use touches to select an entry. Enforcing a fixed height made the bemenu positions predictable.
While trying this on my Pinephone sxmo, I noticed that the newly generated blank space above the last entry was causing behavior issues with the pointer and touches. I pushed a fix to make it more pleasant to use on mobile.
I am now waiting for bemenu to release, and I'll add the needed configuration in sxmo-utils.
Peter is also working on stripping some part of the sxmo-dwm status bar so that it will "make dwm and sway look identical". I think he will be pleased to see that now bemenu looks almost exactly like dmenu.
Aren, a prolific sxmo contributor, brought this topic some weeks ago. Thanks to him, long debates, implementation tentatives, and iterations, we re-implemented almost completely how and when we suspend in sxmo. A bit of context:
In sxmo we got three state which are "unlocked", "locked", and "screenoff". While in screenoff, we want to suspend basically as soon as possible. But some rules could restraint this. If an ssh session is connected, a player is running, a modem related action is in progress, we have to hold suspension until there is no more "reason".
We had a script named `sxmo_mutex.sh` which was serving this purpose. It could `lock` or `unlock` to maintain the list of reason, and `hold` until the reason list is empty. Additionally, we have an extendable hook to check periodically a bunch of condition, and update the reasons (ssh, mpris player, etc).
The fun part is that we could actually rely on the kernel itself to implement this.
If Linux is compiled with the enabled capability (CONFIG_PM_WAKELOCKS), it will expose to the user space some interfaces to manipulate wake locks.
Reading `/sys/power/wake_lock` give the list of the current wake locks. Writing to this file register a new one, with a conditional argument <timeout> in nanosecond after which the wake lock will automatically expire. Writing to `/sys/power/wake_unlock` remove a wake lock.
We replaced our `sxmo_mutex.sh` calls to a `sxmo_wakelock.sh` new script that expose a simple API to manage wake locks. Then we had to choose how we should use this to actually suspend.
First option was to write "mem" to `/sys/power/autosleep`. It would enable opportunistic suspension. When no wake locks remains, the kernel will suspend by itself.
To keep some kind of control we just have to toggle a kind of "not_screenoff" wake lock while switching from one state to another.
Unfortunately we still got some edge cases features that prevent us from relying on this. In sxmo we make it possible to ask for a specific suspension time. It is mostly useful to wake up on time for a cronjob by example. We chose for now to keep some kind of control over suspensions.
Instead, we chose to use `/sys/power/wakeup_count`. Reading this file block until there is no remaining wake lock. Writing an integer to this would fail if the number is not the current wake lock count. If writing succeed, it will make the kernel to abort the following suspension if new wake locks has been registered in between.
With this, we implemented a very simple `sxmo_autosuspend.sh` daemon that will just loop over and try to suspend when no wake lock remains:
More documentation here:
List of the benefits:
- Less code on our side to manage the list (and hopefully a more robust code from the kernel)
- We decoupled suspension from the screenoff hook itself. `sxmo_autosleep.sh` now is a daemon supervised by superd.
- We used wake locks <timeout> values everywhere except in some specific cases ("not_screenoff" by example). Hopefully, it will fix all "my phone was awake when I found it" issues.
- The kernel gives useful wake lock statistics with `/sys/kernel/debug/wakeup_sources`
- This open possibilities to other programs and daemons to manage their own wake locks so that sxmo does not suspend while they are busy. We should now implement this on eg25-manager and ModemManager, additionally to their elogind support.
I have done a bunch of other stuff, mostly for sxmo this month. I'll not cover everything with deep explanations but here some tl;dr:
Peter initiated some status bar icon improvement. Recent releases of Nerd Font added a lot of new cool icons that we really needed. Say "bye bye" to the thermometer that display the modem signal strength. We are waiting for nerd-font update to be merged in aports so that we could merge everything in sxmo-utils. Peter also got additional patches ready to be applied later.
I worked on sxmo-dwm to drop the patch to support multi-key, so that I could write a new one to support key-up and key-down events. It now allows us to connect sxmo-dwm to Bonsai and so, unify both our Sway and Dwm environments. Now I can grow more complex Bonsai tree, to handle more complex situations than "sequential hardware button clicks"
Fossbill didn't have much of my attention this month. Still, I took some time to adapt the bills workflow and manage an extra "quote" state between "draft" and "bill". I also configured and integrated SQL migrations with Alembic, so that futures changes will be easier to do.
And finally, I managed to configure automatic builds of my personal aports. There is also a recipe to cross-compile aarch64 packages using qemu-user. It allows me to skip compiling software on my poor devices. It is such a pleasure to drop nightly recipes, and then upgrade on all my devices to install them.
I took more time, and used tools to help me to write this. Hopefully with less english mistakes! If you notice some remaining problems, feels free to contact me. Thanks for reading!
If this post inspired you, feels free to leave a comment!