Welcome to last project post!
Following GSoC Work Product Submission Guide (https://developers.google.com/open-source/gsoc/help/work-product) I wrote the following post to summarize the work done on GSoC ’20 on gnome-battery-bench project.
How to compile and test the project?
First blog post should be helpful to get ready (https://batterybenchgsoc2020.wordpress.com/2020/06/02/18/). To execute test, follow the guide inside README.
Notice there are two repositories:
- Main project respository (where changes are merged): https://gitlab.gnome.org/GNOME/gnome-battery-bench/
- My repository (for changes before merge to main repository): https://gitlab.gnome.org/josee.loren/gnome-battery-bench
Nothing is merged because it should be reviewed by my mentor (@gicmo) and GNOME community.
For project proposal I solved “Do not start testing if AC power is available” issue (https://gitlab.gnome.org/GNOME/gnome-battery-bench/-/issues/6). The pull request (PR) for this issue (https://gitlab.gnome.org/GNOME/gnome-battery-bench/-/merge_requests/4) pretends to check if AC power is online or not, to start testing.
There a few issues/feature request on project Gitlab. At summer beginning I implemented “Optional timestamps log output” (https://gitlab.gnome.org/GNOME/gnome-battery-bench/-/issues/3). PR for this feature (https://gitlab.gnome.org/GNOME/gnome-battery-bench/-/merge_requests/6) adds a timestamp option to gbb command, so date and hour is available on program output.
Main summer milestone: test recording working on Wayland
I highly recommend read blog post about libevdev to understand how it works: https://batterybenchgsoc2020.wordpress.com/2020/07/05/project-main-change-port-to-wayland/
We implemented mouse and keyboard devices recognition and recording -it is easy to see on code changes. However, we had issues in order to get mouse position. We misunderstood EV_ABS, that is position on a device, no on the screen and we started to work with EV_REL, that returns relative position movements. But we need to have same position on recording and playing, so our idea is move the mouse to (0,0), that it wasn’t achieve on summer project, and play tests on Wayland, because it is not working from command line execution.
Future work and know issues
On Wayland port, issues that should be solved are:
- Move mouse to (0,0) to reply same input as recorded test, using emulated touchscreen, for example.
- Test output and see why tests are not playing on Wayland (on command line execution).
- Test keyboard implementation.
Other issues to solve:
- All avaliable in issue tracker on GitLab.
- Create battery usage history and add (https://gitlab.gnome.org/GNOME/gnome-battery-bench/-/issues/11) to gnome-power-statistics. Even compare computers and software power usage.
Firstly, thank you to my mentor, Christian Kellner (@gicmo) for his comprehension and help during summer. Thank you to @garnacho and @jadahl, and all #gnome-shell channel for helping on this project. And, finally, thank you to GNOME admins to help us and organizing GUADEC, specially to Felipe Borges.