Project Summary

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:

Nothing is merged because it should be reviewed by my mentor (@gicmo) and GNOME community.

Project proposal

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.

Adding features

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:

Acknowledgements

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.

GUADEC ’20 experience

Welcome folks!

Last days of July before 27th, I had been preparing my GUADEC 3 minutes presentation. It was an easy task because I introduce myself and what I was working on. Below I attached slides and speech if you want to review them. Also, I embedded presentation video where you can find my talk between 20:10 and 23:50.

I attended to several talks about GNOME world and it is huge, that is my conclusion. There are a lot of projects and ideas that could improve GNOME and open-source environment, enhancing the world. Interns -and some of them, future contributors- are pushing tiny improvements and all of them are really important to improve GNOME ecosystem. Particularly, I want to mention last talks on “Intern lightning talks” when past interns that still on GNOME share their experience and their career inside and outside GNOME, letting us know what we can do next and where we can be in the future.

Thank you for reading!

Speech slidesDownload
Speech transcriptionDownload

Project main change: port to Wayland!

Welcome again!

The main summer project feature is you can record your own tests on Wayland. gnome-battery-bench is a battery testing software, so one of its features is recording actions on the computer such as keyboard keystrokes and mouse movements. However, that is not possible on Wayland because recording is X11 dependant nowadays, so our mission is get in working on Wayland.

To do that, we did a research about how Wayland works. The conclusion was Wayland has a strong security base and it is not possible to get input devices events from it. Talking with @jadahl and @garnacho at gnome-shell channel on GNOME chat, my mentor and I conclude to use libevdev to get mouse and keyboard events. Below there is a commented example of how to use the library:

struct libevdev *dev = NULL;
int fd;
int rc = 1;

#Open input event file corresponding to device you want to record.
fd = open("/dev/input/event0", O_RDONLY|O_NONBLOCK);
rc = libevdev_new_from_fd(fd, &dev);
if (rc < 0) {
    fprintf(stderr, "Failed to init libevdev (%s)\n", strerror(-rc));
    exit(1);
}
printf("Input device name: \"%s\"\n", libevdev_get_name(dev));
printf("Input device ID: bus %#x vendor %#x product %#x\n",
    libevdev_get_id_bustype(dev),
    libevdev_get_id_vendor(dev),
    libevdev_get_id_product(dev));

#On this case, check device is a mouse
if (!libevdev_has_event_type(dev, EV_REL) ||
    !libevdev_has_event_code(dev, EV_KEY, BTN_LEFT)) {
    printf("This device does not look like a mouse\n");
    exit(1);
}
do {
    struct input_event ev;
    #Get event and print some information like event type and code
    rc = libevdev_next_event(dev, LIBEVDEV_READ_FLAG_NORMAL, &ev);
    if (rc == 0)
        printf("Event: %s %s %d\n",
            libevdev_event_type_get_name(ev.type),
            libevdev_event_code_get_name(ev.type, ev.code),
            ev.value);
} while (rc == 1 || rc == 0 || rc == -EAGAIN);

Using this, we trying to record all mouse and keyboards events:

  • Mouse left, right and middle button clicks.
  • Mouse movements.
  • Keyboard keystrokes.

Furthermore, we need to have the same test recording output file as X11 implementation. That could be challenging!

Thank you for reading!

How to compile and run gnome-battery-bench

Welcome to my GSoC blog!

I’m a bit lazy about writing blogs, but you know, it is important to document main steps you have done on project, to help the community on tons of things like, for example, how to get up and running a project without a headache – if you are a newbie. On this short blog entry I will show you the set of commands you have to run on a fresh Fedora 32 (x86_64) install to get gnome-battery-bench working:

git clone https://gitlab.gnome.org/GNOME/gnome-battery-bench
cd gnome-battery-bench
sudo dnf install make automake gcc gcc-c++ kernel-devel
sudo dnf install libevdev-devel
sudo dnf install glib2-devel
sudo dnf install polkit-devel
sudo dnf install gtk3-devel
sudo dnf install libgudev-devel
sudo dnf install json-glib-devel
sudo dnf install gnome-common
./autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib64
make -j5
sudo make install
gnome-battery-bench

Next steps I have to document are setting up my working environment, because I have a laptop that I need to run the project, but I want to use three displays I have at home, connected to a desktop PC. So, I want to connect to that computer (a Macbook Pro late 2013) remotely, to use that three screen without use more cables.

I hope you enjoy the journey like me!

Thank you for reading!