Ever since we (Red Hat's Desktop Hardware Enablement Team) received the 2017 models from Lenovo for testing (e.g. the T470s), we experienced an issue (rhbz#1480844) where sometimes the fan would run at 100% after resuming from suspend. A warm reboot alone would not make the fan go back to normal and a hard reboot was required. It seems the behavior is the result of firmware bug and kernel ACPI changes. Patches for 4.13 reduced the likelihood for the appearance of the noisy issue. Additionally, we have been working together with Lenovo to fix the firmware side and I am happy to report that for the T470s Lenovo recently released a new firmware that should completely fix the issue. Since Lenovo is not yet(!) part of Linux Vendor Firmware Service updating the BIOS is currently not super straight-forward. Thankfully, Jeff has provided detailed instructions how to do this from GNU/Linux only.

FOSDEM 2018 is approaching fast. There will be a Hardware Enablement Devroom, among many other very interesting ones. We invite everybody to come and participate:

Important dates

  • Conference date: 3 & 4 February 2018 in Brussels, Belgium
  • Devroom date: Sunday 4 February 2018
  • Submission deadline: Sunday 26 November 2017
  • Speaker notified: Sunday 10 December 2017

About

In this devroom we want to discuss topics surrounding hardware enablement. Subjects can range from the firmware running on the bare metal machine, drivers and plumbing all the way to the user interface.
We welcome a board range of presentations, including but not limited to technical talks, state of union summaries as well as discussions that facilitate the collaboration between community members, software vendors and OEMs. A particular emphasis will be given to talks covering a significant part of the software stack involved in hardware enablement, with an obvious focus on using open source throughout the whole stack.

Visit https://fosdem.org for general information about FOSDEM.

Talk Format

  • To cover the wide range of topics we will prefer short talks (about 15-25 minutes). Please include at least 5 minutes for discussions and questions.
  • Presentations will be recorded and streamed. Sending your proposal implies giving permission to be recorded. Exceptions may be possible.
  • Proposals need to be submitted via pentabarf  (see "Submission" below for details)

Topics & Examples

  • UX design to enable users to use their HW effectively
  • Firmware:
    • coreboot
    • flashrom
    • UEFI EDK2 (Tianocore)
    • Security
    • Lockdown of platform using firmware
    • Updating
  • Secure Boot
  • Hardware testing / certification
  • Thunderbolt 3 security modes
  • Gaming input devices (keyboards, mice, piper)
  • Biometric authentication
  • Miracast or controlling remote devices
  • Why vendors should facilitate upstream development

Submission

The FOSDEM Pentabarf is used for submission and scheduling:

  • Please reuse and existing account otherwise register a new one.
  • Please provide your full name and email address. If you provide bio then this will be visible publically.
  • Create a new event:
    • Select "Hardware Enablement devroom" as the track
    • Provide a descriptive title
    • Provide a public abstract for your talk
    • Add any further information for paper review into the submission notes (e.g. outline, why this devroom)

I joined Red Hat's Desktop Hardware Enablement team almost a year ago. One of the things that I have been looking into recently is Thunderbolt 3. With kernel 4.13 we got a completely new kernel interface for interacting with it from userspace (the work was done by Intel). One of the two big things this interface provides is updating the firmware (the non-volatile memory, or NVM in short) of the host controller and attached thunderbolt devices. With help from Dell's Mario Limonciello, Intel's Yehezkel Bernat, and of course our own Richard Hughes I created a thunderbolt 3 plugin for fwupd, which device and host firmware updates should show up in GNOME Software (or any other fwupd userspace clients) and updating them should be a breeze. The code landed already in fwupd 0.9.7.

On the technical side this is done all done via sysfs. Thunderbolt devices (including the host) are exposed via /sys/bus/thunderbolt/devices and for the NVM we get two additional subdevices for each devices, i.e. nvm_activeX and nvm_non_activeX (where X is a global nvm device counter). The latter one contains a file called nvmem where we can write new firmware binaries to. The upgrade process is triggered by authenticating the NVM via a write to the nvm_authenticate file of the device, like # echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate. That in brief is what the thunderbolt 3 fwupd does to apply firmware updates. It uses udev to monitor for changes of attached devices. Discovery of updates is all done by the existing fwupd code, and the fwupd plugin API was actually nice to work with and made writing the plugin straight-forward and, yes even fun.

Once vendors start uploading firmware to the LVFS it will be easy, safe and reliable to update the NVM. If you're interested in helping out with fwupd or the Thunderbolt stuff then please join the mailing list where we discuss this kind of thing.

Just a very quick announcement. I created two new packages for Fedora:

  • rtags - A source code indexer for the C language family. I use it together with Emacs, to get IDE-like functionality. The package contains systemd (user) unit files that should socket-activate the rtags daemon on demand. Check via systemctl status --user rtags.socket.
  • renderdoc - a stand-alone graphics debugger; it is a wonderful tool to help developers when doing anything 3D (OpenGL, Vulkan) related.
    Thanks goes to @baldurk for a patch to install renderdoc's library into a private location.

Install on Fedora 26, 27 and rawhide via dnf install rtags renderdoc.

I also created my first flatpak:

  • NixView - as the name suggests a viewer for the free and open NIX scientific data format. It is available via flathub. Open data formats are the necessary basis for data sharing, which is one of the most important problems in science that is still not solved properly.

All this was done during the workshop & hackathon on open data formats and data sharing in neuroscience (in Japan!). Thanks goes to the German Neuroinformatics Node and Red Hat (my employer), that made it possible for me to attend it; and also to the Japanese Node for organizing it. I had a great and productive time in Japan.

I have been working on a little rust project lately (more on that some time later). For this I have been using Emacs with rust-mode, flycheck-rust, racer-mode and cargo-mode (see my config). This setup already works quite nicely with all the nice IDE-like features you would expect. But, I also really like the idea of Microsoft's language server protocol , where the various editors out there can use a single implementation of a common "language" server that does the indexing, auto-completion, docs, etc.pp. for a given programming language. The common language server for rust (rls) can be installed via rustup (assuming one is already using rustup and rust nightly, if not go to the rls README.md and follow the instructions there):


rustup component add rls --toolchain nightly
rustup component add rust-analysis --toolchain nightly
rustup component add rust-src --toolchain nightly

As for Emacs, there is the common lsp-mode and the rust specific lsp-rust. Btw, RMS also seems to like lsp; who knows maybe we get out of the box support for it someday. For now the installation via use-package is also fairly trivial:


(use-package rust-mode
    :mode "\\.rs\\'"
    :init
    (setq rust-format-on-save t))
(use-package lsp-mode
    :init
    (add-hook 'prog-mode-hook 'lsp-mode)
    :config
    (use-package lsp-flycheck
        :ensure f ; comes with lsp-mode
        :after flycheck))
(use-package lsp-rust
    :after lsp-mode)

This already provides all the goodies: auto-completion, eldoc, goto definition, symbol references, flycheck.
I have used it for the last couple of days and it mostly works. On the initial opening of a project it will hog the CPU and spin up the fans but that doesn't last too long. Sometimes it completely hangs Emacs. Nothing that killall rls followed by a M-x revert-buffer can't fix. (It seems to correlate with my having written some bad rust code full of errors, so ultimately I am to be blamed I guess). Long story short, quite usable already with a few glitches, but very promising!

Although Builder clearly is The Future as GNOME IDE, I still all my coding in Emacs, mostly because I have been using it for such a long time that my brain is to all the shortcuts and workflows. But Emacs can be a good IDE too. The most obvious everyday features that I want from an IDE are good source code navigation and active assistance while editing. In the first category are tasks like jumping to symbol's definition, find all callers of a function and such things. For editing, auto-completion, immediate warnings and error reporting, semantic-aware re-factoring are a must. Specifically for GNOME related development, I need all this to also work with JHBuild.

Emacs autocompletion

Auto-completion via irony-mode

Emacs can do all these with a combination of various packages: RTags indexes C/C++ source code and provides all sorts of functionality on top of that, like follow-symbol, find-references, rename-symbol and even fix obvious errors for you (via clang's "Fix-It Hints"). Auto-completion and "online" diagnostics are currently handled via Irony-mode (via company-irony and company-flycheck); RTags could do both too, I use irony-mode mostly for historic reasons and it works quite well. Additionally, irony-mode also has integration with eldoc-mode, that will show function signatures in the mode-line.

Eldoc integration

Eldoc integration

compile database compiler wrapper

Both of these packages use (lib)clang internally, which in turn needs to know the right compile flags for all source files. CMake and other modern build system can generate a compile_commands.json file that contains that information. For automake/autoconf based projects a wrapper around gcc can in theory be used to generate the file. But for JHBuild that approach is not working, because the build directory is not the source directory, so the wrapper generates the files in the wrong place. To work around this I wrote a special gcc wrapper and small set of tools, called cdcc (for compile database cc). The cdcc-gcc wrapper will store the compile flags in a sqlite database and the cdcc-gen command can then be called with a path to the source directory to generate the corresponding compile_commands.json. The easy way to use cdcc with JHBuild is to put the following in your ~/.config/jhbuildrc (this includes a fallback if it is not installed):

if spawn.find_executable('cdcc-gcc') is not None:
    os.environ['CC'] = 'cdcc-gcc'
    os.environ['CXX'] = 'cdcc-g++'

After the build is done, the compile_commands.json for each module can then be generated with cdcc-gen * in the JHBuild checkout root. The Emacs package cmake-ide is used to automatically set up RTags and friends with the correct settings, if it detects the compile_commands.json file.

Installation

RPMs for Fedora of RTags and cdcc can be found in my copr. The rdm server for RTags can easily be started via systemd socket activation, instructions are here. I install the irony-server binary locally in my ~/.emacs.d folder via a custom script.
I load all Emacs packages with use-package, you can look at my init.el for details.

Last Thursday I merged the Apple Filing Protocol (AFP) backend for GVfs; so we finally have support for Apple shares too now. It has been written by Carl-Anton Ingmarsson and it was his Summer of Code 2011 project. It is on the master branch and thus will be in the next unstable release. Please test it and report bugs against the "afp backend" component.

Carl-Anton did quite an impressive job - probably best depicted by the diffstat of the merge:

 client/Makefile.am            |    1 
 client/afpuri.c               |  269 ++
 client/gdaemonvfs.c           |    2 
 configure.ac                  |   31 
 daemon/Makefile.am            |   45 
 daemon/afp-browse.mount.in    |    8 
 daemon/afp.mount.in           |    5 
 daemon/gvfsafpconnection.c    | 1651 ++++++++++++++++
 daemon/gvfsafpconnection.h    |  420 ++++
 daemon/gvfsafpserver.c        | 1033 ++++++++++
 daemon/gvfsafpserver.h        |   85 
 daemon/gvfsbackendafp.c       | 4292 +++++++++++++++++++++++++++++++++++++++++-
 daemon/gvfsbackendafp.h       |   23 
 daemon/gvfsbackendafpbrowse.c |  608 +++++
 daemon/gvfsbackendafpbrowse.h |   47 
 daemon/gvfsbackenddnssd.c     |    6 
 daemon/gvfsjobsetattribute.h  |    1 
 17 files changed, 8491 insertions(+), 36 deletions(-)

International Neuroinformatics Coordinating Facility

 

Just a quick reminder: The student application period for the Google Summer of Code 2011 has opened as of yesterday (Monday, the 28th of March). Apply now! The starting point for Gnome is here; it has all the relevant information.

In addition to that, if you are happen to be interested in Neuroscience and Informatics the International Neuroinformatics Coordinating Facility (INCF) also got accepted as a organization (Thanks Raphael!). Among other very interesting project ideas there are also two proposals that are Gnome related (as in pygtk based applications). If you have a cool Neuroinformatics+Gnome based idea be sure to apply at the INCF. The starting point is here.

After being down for a while the blog is now back online. The server moved - as I did - to Munich. EOM for now - more real news later ...

... continued:

"In Deutschland ist nicht nur die Steuerbelastung so hoch wie in kaum einem anderen Industrieland, die Steuern und Abgaben sind auch noch besonders ungerecht verteilt. [...] Der DGB fordert, die wirtschaftlich Leistungsfähigen über die Anhebung des Spitzensteuersatzes und Wiedereinführung der Vermögenssteuer stärker zur Kasse zu bitten. [...] Die Union weist die Forderungen zurück. "Für mich ergibt sich kein Handlungsbedarf", sagte CDU-Sozialpolitiker Ralf Brauksiepe." (ZEIT Online)

Vermögende besteuern? Also das geht offenbar gar nicht. Aber halt: Das C in CDU steht doch immer noch für christlich, oder? Sein Hab und Gut den Armen geben - war da nicht was, Herr Sozialpolitiker? Ach quatsch, alles gerecht so wie es ist; auch dass Doppelverdiener mehr Abgaben zahlen. Oder? "Selbstverständlich", meint Herr Brauskiepe (ebd.).
"Ökonomen teilen diese Meinung nicht." - Pah. Experten. Was wissen die schon. Und überhaupt: Die vom Familienministerium kümmern sich ja auch nicht um die. - "Die deutschen Sozialsysteme seien nach wie vor auf die vierköpfige Standardfamilie mit zwei Kindern und einem Alleinverdiener." (ebd.) Aha! Wer hätte das gedacht. Wer nicht ins verstaubte Weltbild passt ist eh selber schuld und zahlt deswegen auch mehr; und womöglich Atheist, Agnostiker oder Schlimmeres. Christlich ist man halt nur unter sich. Doppel-Moral war ja noch nie ein Problem.
Außerdem hat die Regierung ja gerade auch viel, viel Wichtigeres zu tun; nämlich Medien zensieren und verbieten, dass Leute mit Farbkugeln in der Gegend rumschießen. Viel, viel wichtiger.

Made by ThemesKult