Language Selection

English French German Italian Portuguese Spanish

Sunsetting XRandR Brightness

Filed under
KDE

One of the first features I added back then was smooth brightness changes. PowerDevil supports three ways of changing screen brightness: through XRandR configuration, through DDC (display data channel, for desktop monitors, experimental and not built by default), and by writing to sysfs (/sys/class/backlight or /sys/class/leds). Since the latter requires privileges and uses a helper binary through KDE’s KAuth framework, I only implemented the animation for the XRandR code path, which was executed in the same process.

Obviously, XRandR doesn’t work on Wayland, and it seems that modern graphics drivers don’t support changing brightness through it anymore either. I recently sat down and wrote a patch to have the helper binary execute a similar animation. KAuth works quite magically by exposing methods defined in an .actions file through DBus and then calling them as slots through Qt’s meta object. Unfortunately, the way it is designed doesn’t allow for delayed replies, which I wanted to use so the job only finished once the animation was completed in order to keep PowerDevil’s state consistent. I then found that KAuth randomly keeps its helper running for 10 seconds, more than enough for a 250ms animation.

Read more

More in Tux Machines

Mozilla: SpiderMonkey and Filter Treeherder Development

  • SpiderMonkey Newsletter 5 (Firefox 78-79)

    SpiderMonkey is the JavaScript engine used in Mozilla Firefox. This newsletter gives an overview of the JavaScript and WebAssembly work we’ve done as part of the Firefox 78 and 79 Nightly release cycles. If you like these newsletters, you may also enjoy Yulia’s weekly Compiler Compiler live stream, a guided tour of what it is like to work on SpiderMonkey and improve spec compliance.

  • In Filter Treeherder jobs by test or manifest path I describe the feature.

    In Filter Treeherder jobs by test or manifest path I describe the feature. In this post I will explain how it came about. I want to highlight the process between a conversation and a deployed feature. Many times, it is an unseen part of the development process that can be useful for contributors and junior developers who are trying to grow as developers. Back in the Fall of 2019 I started inquiring into developers’ satisfaction with Treeherder. This is one of the reasons I used to go to the office once in a while. One of these casual face-to-face conversations led to this feature. Mike Conley explained to me how he would look through various logs to find a test path that had failed on another platform (see referenced post for further details). After I understood the idea, I tried to determine what options we had to implement it. I wrote a Google Doc with various alternative implementations and with information about what pieces were needed for a prototype. I requested feedback from various co-workers to help discover blind spots in my plans. Once I had some feedback from immediate co-workers, I made my idea available in a Google group (increasing the circle of people giving feedback). I described my intent to implement the idea and was curious to see if anyone else was already working on it or had better ideas on how to implement it. I did this to raise awareness in larger circles, reduce duplicate efforts and learn from prior work. I also filed a bug to drive further technical discussions and for interested parties to follow up on the work. Fortunately, around the same time Andrew Halberstadt started working on defining explicitly what manifests each task executes before the tasks are scheduled (see bug). This is a major component to make the whole feature on Treeherder functional. In some cases, talking enough about the need can enlist others from their domains of expertise to help with your project.

  • Filter Treeherder jobs by test or manifest path

    This feature is useful for developers and code sheriffs because it permits them to determine whether or not a test that fails in one platform configuration also fails in other ones. Previously, this was difficult because certain test suites are split into multiple tasks (aka “chunks”). In the screenshot below, you can see that the manifest path devtools/client/framework/browser-toolbox/test/browser.ini is executed in different chunks.

Debian-based Grml 2020.06 Released and NsCDE in Debian-based Sparky

  • Grml 2020.06 – Codename Ausgehfuahangl

    We did it again™, at the end of June we released Grml 2020.06, codename Ausgehfuahangl. This Grml release (a Linux live system for system administrators) is based on Debian/testing (AKA bullseye) and provides current software packages as of June, incorporates up to date hardware support and fixes known issues from previous Grml releases. I am especially fond of our cloud-init and qemu-guest-agent integration, which makes usage and automation in virtual environments like Proxmox VE much more comfortable.

  • NsCDE

    There is a new desktop available for Sparkers: NsCDE What is NsCDE? Not so Common Desktop Environment (NsCDE) is a retro but powerful (kind of) UNIX desktop environment which resembles CDE look (and partially feel) but with a more powerful and flexible framework beneath-the-surface, more suited for 21st century unix-like and Linux systems and user requirements than original CDE. NsCDE can be considered as a heavyweight FVWM theme on steroids, but combined with a couple other free software components and custom FVWM applications and a lot of configuration, NsCDE can be considered a lightweight hybrid desktop environment.

Epiphany GSoC Milestone

During the past month I have been hacking on Epiphany’s Preferences dialog. The first piece of submitted work was splitting the dialog source code files into smaller ones. The split didn’t reflect any visual changes on Epiphany’s user interface so I decided to postpone writing this blog post. Read more

New Tech Vocabulary for 2020 Could Break Software Compatibility

2020 has been an interesting year with plenty of disruption to most people lives, and political changes. Now it appears some of those changes will affect technology, and by that, I mean things like changes to datasheets and even source code. [...] Twitter’s senior management is allegedly backing the effort for the changes. This goes beyond racially charged terms, but if it’s the world we’re going to live in so be it. Some changes in the datasheet may not be a big issue, except for the initial confusion, but it may become problematic when changes happen in the source code as it may break other programs and scripts. One example is Github planning to replace the master branch by another name. If it’s going to happen, and others are going to follow suit, I wondered about many “slave” code results there are in the Linux kernel. Answer: 2,878. Read more