Cyber Space
A banal geek, coder, cyber-space girl, linux user but cute person.
If you like my work, feel free buy me a coffee https://donate.misterbanal.net/
she, her, hers
From Stacy Harper to ~mil/sxmo-devel
I think we should get rid of system daemon management completly, at least from our core scripts. We still offer a hook that the user can override on custom systems to restart modem daemons in case of crash. We continue to manage vvmd and mmsd throught superd cause they are user daemons and we choosed to use one daemon manager for that. Signed-off-by: Stacy Harper <contact@stacyharper.net> --- .../default_hooks/sxmo_hook_contextmenu.sh | 5 +- configs/default_hooks/sxmo_hook_icons.sh | 1 + .../sxmo_hook_restart_modem_daemons.sh | 106 +++++++++++++ configs/default_hooks/sxmo_hook_start.sh | 23 +-- scripts/modem/sxmo_modemdaemons.sh | 143 ------------------ [message trimmed]
From Stacy Harper to ~mil/sxmo-devel
Why not ? It can prevent a spec developer to use incompatible api. Applied ! To git.sr.ht:~mil/sxmo-utils 7899904e..faf766cc faf766cc -> master
From Stacy Harper to ~mil/sxmo-devel
> Was a report on IRC that hardware buttons fail under high load. Rumor > has it it was because superd crashes. I don't see any reason for these > to be managed by superd anyway, and hardware buttons are kind of > important in such cases (e.g., to reboot or switch WM). So let's make > them sufficient. I dont think we want to handle superd failures. And anyway if superd crash then we got multiple more important issues :D menumode toggler must be restarted if for some reason the process stop (oom killer, or whathever) I mark this as rejected cause I'm really not convinced of its value :S
From Stacy Harper to ~mil/sxmo-devel
> Arch, Debian, and probably most other systemd based ditros, enable > pipewire / mmsd / vvmd by default. If we start them with superd either > it or systemd will think the services failed to start. Arch, Debian and probably most other systemd based distros have to not enable systemd daemons for things sxmo will manage. > If we want to manage these services (e.g. mmsdconfig & vvmdconfig) we > need to know which service manager is being used, to do this we should > allow systemd to manage the service because we can't easily disable it. Not we support superd and not systemd. Yes it is easily to disable systemd daemons.
From Stacy Harper to ~mil/sxmo-devel
Applied with additional patchs to fix some issues and to adapt the build recipe. About the side note, I dont think we have / want to ignore issues that existed before the submitted patch. Thanks a lot for this ! To git.sr.ht:~mil/sxmo-utils c3558e1e..7899904e 7899904e -> master
From Stacy Harper to ~mil/sxmo-devel
Applied with the comment removed. Thanks a lot ! To git.sr.ht:~mil/sxmo-utils 91d2aab6..c3558e1e c3558e1e -> master
From Stacy Harper to ~mil/sxmo-user
> I exchanged some E-Mails with Simon (emersion) and nope I won't be able > to get any of those features into upstream swaylock because of the > complexity they introduce, swaylock is supposed to stay simple (which is > an honorable goal). This means I'll start a proper fork at some point in > the future. Glab you figured it out directly with him. That an expected results. Anyway there isnt that much available solution atm. Having more wayland DE agnostic touchscreen lockers would be benefit for the whole ecosystem.
From Stacy Harper to ~mil/sxmo-devel
What I mean by "mock the client" is to define a youtube-cli script or function that will stdout something like youtube-cli would do when you call it with the args we use in sxmo_youtube.sh. Thats "mocking", or stubing. We can then see if sxmo_youtube.sh youtubesearch "big buck bunny" returns the output we expect it to return without actually needing network access, or knowing what are youtube results. In the end, the only thing we care to test is if the combinaison of grep + awk + tr + give the expected results. That doesnt looks that worth it to me.
From Stacy Harper to ~mil/sxmo-devel
I'm sorry it just doesnt work at all. This version break the cleanup logic. It also break the ssh connection that grab sxmo environment variable logic. I dont have time to cleanup and find a good solution to support this. I mark this as need revisions !
From Stacy Harper to ~mil/sxmo-devel
Signed-off-by: Stacy Harper <contact@stacyharper.net> --- configs/default_hooks/sxmo_hook_lisgdstart.sh | 2 +- configs/default_hooks/sxmo_hook_start.sh | 2 +- .../deviceprofiles/sxmo_deviceprofile_pine64,pinephone-1.2.sh | 1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/default_hooks/sxmo_hook_lisgdstart.sh b/configs/default_hooks/sxmo_hook_lisgdstart.sh index 2945bcf5..c2ee3340 100644 --- a/configs/default_hooks/sxmo_hook_lisgdstart.sh +++ b/configs/default_hooks/sxmo_hook_lisgdstart.sh @@ -11,7 +11,7 @@ LISGD_THRESHOLD_PRESSED="${SXMO_LISGD_THRESHOLD_PRESSED:-60}" LISGD_INPUT_DEVICE="${SXMO_LISGD_INPUT_DEVICE:-"/dev/input/touchscreen"}" [message trimmed]