Colors of Noise

agx@sigxcpu.org

Entries tagged "phosh".

Introducing gtherm
7th January 2020

Continuous temperature monitoring from the kernel's /sys/class/thermal/ in an application can be cumbersome. gtherm aims to make that simpler by providing a daemon (gthd) that exports thermal zones and cooling cells over DBus and providing a small library libgtherm (and GObject introspection bindings). gthcli is a simple command line client that displays the currently found values:

Thermal Zones
-------------
      dbus path: /org/sigxcpu/Thermal/ThermalZone/0
           type: cpu-thermal
    temperature: 53,00°C
cooling devices: /org/sigxcpu/Thermal/CoolingDevice/0

      dbus path: /org/sigxcpu/Thermal/ThermalZone/3
           type: max170xx_battery
    temperature: 36,60°C

      dbus path: /org/sigxcpu/Thermal/ThermalZone/2
           type: vpu-thermal
    temperature: 54,00°C

      dbus path: /org/sigxcpu/Thermal/ThermalZone/1
           type: gpu-thermal
    temperature: 54,00°C
cooling devices: /org/sigxcpu/Thermal/CoolingDevice/1

Cooling Devices
---------------
    dbus path: /org/sigxcpu/Thermal/CoolingDevice/0
         type: thermal-idle-0
    max state: 100
current state: 0

    dbus path: /org/sigxcpu/Thermal/CoolingDevice/1
         type: 38000000.gpu
    max state: 6
current state: 0

There's support for gnome-usage in the works:

gnome-usage thermal view

Next up is support for trip points (and maybe tuning cooling behaviour from userspace later on).

Tags: gnome, librem5, phosh, planetgnome.
GTK+ and the application id
28th August 2018

tl;dr: If you want to be sure your application will be displayed with the correct icon under different Wayland compositors make sure that your GApplication (or GtkApplication) uses

g_set_prgname(your_g_application_id);

on GTK+3. On GTK+4 this is handled for you.

Details: While working on touch based window switching for the Librem5 I noticed that lots of the GNOME application did not end up with a proper icon when using g_desktop_app_info_new (desktop_id). The desktop_id is determined from the Wayland xdg surface's app_id as specified by in Wayland's xdg-shell protocol.

The protocol says:

The compositor shell will try to group application surfaces together
by their app ID. As a best practice, it is suggested to select app
ID's that match the basename of the application's .desktop file.
For example, "org.freedesktop.FooViewer" where the .desktop file is
"org.freedesktop.FooViewer.desktop".

It's even more explicit about the relation of the app_id to the D-Bus service name:

For D-Bus activatable applications, the app ID is used as the D-Bus
service name.

So why does this currently fail? It's because GTK+3 historically uses g_get_prgname() to set the app_id and this defaults to application's basename. But what we rather want is

g_application_id == D-Bus service name == $(basename desktop_file_path .desktop) == xdg app_id

There were patches by Jonas Ådahl to fix this but those were partially reverted since it broke existing applications. Now with GTK+4 around the corner we can fix this. See the migration docs.

This will also allow us to get rid of all the rename-desktop-file in the flatpak manifests too.

(The reason why this currently works in gnome-shell is because there's a private protocoll between GTK+ and GNOME Shell that (among other things) works around this).

Update: to check what app_id Wayland is seeing use:

WAYLAND_DEBUG=1 your_program |& grep 'xdg_toplevel@[0-9]\+\.set_app_id'
Tags: librem5, phosh, planetdebian, planetgnome.

RSS Feed