Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBus Monitor to pass events to input modules: First cut #64

Open
wants to merge 8 commits into
base: packaging-process-and-systemd-service
Choose a base branch
from

Conversation

zachfeldman
Copy link
Contributor

@zachfeldman zachfeldman commented Aug 27, 2023

This is a working implementation of the DBus monitor applied to Input Modules!

I've folded it directly into this project instead of in a separate repo.

Try it out with RUST_LOG=debug cargo run --target x86_64-unknown-linux-gnu -p framework-inputmodule-dbus-monitor, to see debug output too, then try making a test calendar event with notification. Assuming your system uses the same DBus monitoring channel as mine, your LED Matrix module should blink when a notification comes in for a calendar event.

Some things I am working on/trying to make better:

  • I know this is only one level better than calling the binary you've outputted, but I think passing Clap CLI arguments is a pretty good interface, I'm not sure if it's worth going to a level lower in the existing modules or not when you've implemented a pretty great interface there.
  • I want to make this much more generic as @kiram9 and I have discussed, where a user can create a config file in their home directory, subscribe to specific events, and then have certain commands run in response to them! But wanted a working example first. This is done, you can now have this respond to any DBus message and run any command!
    • I think for this reason the CLI interface is good because it's pretty understandable to users who might configure this through a file.
  • I can't seem to figure out how to make my run_inputmodule_command which calls the serial_commands function go on to the next command...it just stays on the first one. Any ideas @JohnAZoidberg ? Sorry if this is super obvious and I'm missing something! I added a new command that doesn't loop to address this!

@zachfeldman zachfeldman changed the base branch from main to packaging-process-and-systemd-service August 27, 2023 14:11
@zachfeldman zachfeldman changed the base branch from packaging-process-and-systemd-service to main August 27, 2023 14:13
@zachfeldman zachfeldman changed the base branch from main to packaging-process-and-systemd-service August 27, 2023 14:13
@zachfeldman zachfeldman force-pushed the dbus-monitor branch 2 times, most recently from 83bc861 to 2c3294d Compare August 27, 2023 14:14
Copy link
Contributor Author

@zachfeldman zachfeldman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Github made me leave this comment for some reason...

println!("Got message from DBus: {:?}", msg);

run_inputmodule_command(vec!["led-matrix", "--pattern", "all-on", "--blinking"]);
// Can't seem to get to this second command
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JohnAZoidberg this is where I can't seem to get to the second command, it just stays on the first one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This blinking command is implemented in software and will loop until you terminate the process.
The function call here will never exit. That's why it doesn't go to the next one.

If you reverse the order, it'll probably work fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @JohnAZoidberg ! Maybe I'll implement my own one that blinks n times, than exits, that'd be fun. Appreciate the tip.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Phew I know it's been a while since I was in this repo but I finally had some time on this 4 day weekend!

I added a new blink_n_times function and am using it here now, so it's not blocking anymore.

@zachfeldman zachfeldman force-pushed the packaging-process-and-systemd-service branch from 20b25e8 to 2b678b1 Compare October 9, 2023 19:50
@zachfeldman zachfeldman marked this pull request as ready for review October 9, 2023 19:54
@zachfeldman
Copy link
Contributor Author

@JohnAZoidberg @kiram9 FYI, I finished up a pretty decent implementation of this that let's you configure which channel you want to monitor and what commands to run through a configuration file! Eventually you could have an n of more than 1 here, but this is a decent PoC.

It is based on my packaging-process-and-systemd-service branch which hasn't been merged yet, my intention is to eventually shove this into systemd and run all of the time.

I think I'm going to pause here for now though until I receive the newer hardware so I can test it with that, but if you'd like to merge it sooner for any reason let me know, or feel free to try it yourself :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants