Chaotic Experiments

Update: MSI Installer for GNU Emacs 29.3 for Windows

Fri, 29 Mar 2024 00:00:00 +0200

Following the GNU Emacs 29.3 release, my MSI installer for GNU Emacs has been updated!

This time there is no 32-bit version of it as no 32-bit executables were provided by the maintainers.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

I have also uploaded installers for 29.2 because I have completely missed that release.

Enjoy!

I decided to reuse screenshots from a previous release because the installer's code was not modified since then, so the screenshots will look the same (except the version number, obviously).

Update: MSI Installer for GNU Emacs 29.1 for Windows

Tue, 01 Aug 2023 00:00:00 +0300

Following the GNU Emacs 29.1 release, my MSI installer for GNU Emacs has been updated!

This time there is no 32-bit version of it as no 32-bit executables were provided by the maintainers.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

I decided to reuse screenshots from a previous release because the installer's code was not modified since then, so the screenshots will look the same (except the version number, obviously).

Update: MSI Installer for GNU Emacs 28.2 for Windows

Mon, 26 Sep 2022 00:00:00 +0300

Following the GNU Emacs 28.2 release, my MSI installer for GNU Emacs has been updated!

As usual, it is a belated update.

This time there is no 32-bit version of it as no 32-bit executables were provided by the maintainers.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

I decided to reuse screenshots from a previous release because the installer's code was not modified since then, so the screenshots will look the same (except the version number, obviously).

Update: MSI Installer for GNU Emacs 28.1 for Windows

Wed, 04 May 2022 00:00:00 +0300

Following the GNU Emacs 28.1 release, my MSI installer for GNU Emacs has been updated!

As usual, it is a belated update.

This time there is no 32-bit version of it as no 32-bit executables were provided by the maintainers.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

I decided to reuse screenshots from a previous release because the installer's code was not modified since then, so the screenshots will look the same (except the version number, obviously).

Update: MSI Installer for GNU Emacs 27.2 for Windows

Tue, 13 Apr 2021 00:00:00 +0300

Following the GNU Emacs 27.2 release, my MSI installer for GNU Emacs has been updated!

As usual, it is a belated update.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

I decided to reuse screenshots from a previous release because the installer's code was not modified since then, so the screenshots will look the same (except the version number, obviously).

Installing Entware on an Android-powered device: Entware Installer Module for Magisk

Fri, 02 Oct 2020 00:00:00 +0300

You may have an old unused Android-powered phone lying around, or you may have a set-top box which remains unused most of the time, so you want to make it to work also as a home WEB-server. Maybe you are geeky enough for an idea of carrying a Linux-powered server in your pocket. Or you would like to improve the functionality of your Android phone to include a package manager which simplifies installation of a large number of server-side software and development tools. These are only the reasons for installing Entware on an Android-powered device I can imagine. Everyone can have his or her reasons for doing so.

However, installing Entware on Android might be not straightforward. Initially, I planned to write a guide on how-to get Entware running on a device rooted using Magisk.

To my shame, the guide turned out to be complicated and error-prone. To save you from the hassle, I decided to reuse my findings and code and developed a module for Magisk which you can find on Github. Installing Entware using this module is as straightforward as possible, but for now, it supports only devices on which the root file system is a RAM-drive (rootfs). Unfortunately, this rules out most of the recent devices released with Android 9 and newer (so-called "system-as-root" devices). On these devices, the root file system is a real partition, so you need to manually modify it before using the module because Magisk does not currently provide a facility to make reversible modifications to directories outside of "/system."

I do not want to repeat myself in this post because I wrote hopefully complete documentation for the module. If you happen to have a newer device where the root file system is not a RAM-drive, I mentioned there the modifications which you might want to make before the installation.

Hopefully, I will get this module into the official Magisk modules repository at some point. Now you can install it manually, as described in the documentation.

Happy Entware installation!

Update to My 'daemonize' Library

Tue, 08 Sep 2020 00:00:00 +0300

I have updated my tiny C library for writing Unix daemons.

In fact, the library's code itself remained intact. When the original version was released, I made a somewhat sinful thing: although the library's code was written with portability in mind, the only example which came with it was Linux specific because of usage of signalfd(2) to redirect signal handling to the main event processing loop. This issue has been addressed recently: now, additionally to the original Linux specific example there is one which should be portable to the other Unix-like systems. It utilises the somewhat lesser-known self-pipe trick to redirect signal processing to the loop ¹.

I advise you to use the new example as a template for your daemons, even though there is slightly more code involved in doing the same thing. Even though we seem to live in the world of Linux monoculture, losing portability to other Unixes would be a sad thing.

Footnotes:

Here you can find another good example of the trick.

Update: MSI Installer for GNU Emacs 27.1 for Windows

Tue, 25 Aug 2020 00:00:00 +0300

Following the GNU Emacs 27.1 release, my MSI installer for GNU Emacs has been updated!

As usual, it is a belated update.

Although this release of Emacs contains a Windows installer, I decided to release my installer as well, because MSI installers might be more convenient in some cases.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

I decided to reuse screenshots from the previous release because the installer's code was not modified since then.

Finding the Square Root of a Number Without Using the Standard Library (Newton's Method)

Tue, 19 May 2020 00:00:00 +0300

In this short post, I want to show a way to find the square root of a positive number without relying on the standard library using Newton's method. This is the method which seems to be used in many implementations of the C standard library. The example code is in the C programming language. Before going to the implementation, I provide the mathematical formulae used.

I want to demonstrate how one could solve it with a relatively small amount of code without sacrificing precision much or at all compared to the sqrt() function from the C standard library.

A Bit of Math

Before going to the code, we need to describe the method which we are going to use. No advanced understanding of math is required.

Finding the square root of a number

\[N = \sqrt{X}\]

using Newton's method requires multiple steps.

To find the value of the desired accuracy

\[N = A_n\]

we will use the following formula:

\[A_{n} = \frac{A_{n-1} + \frac{X}{A_{n-1}}}{2}\]

where accuracy depends on the value of $n$. The higher the value of $n$ the more accurate value of square root we could obtain. We can say that $n$ is the number of approximations (how many times we want to apply this formula).

When choosing $n$ one needs to keep in mind that, in general, Newton's method has quadratic convergence which intuitively means that the number of correct digits roughly doubles in every step. On a computer, the number of approximations is dictated by the hardware.

From the formula above it is obvious that we need to know a way to find a value of $A_1$ to start.

A good starting value (or, should I say, a good first approximation) would be integer square root of $X$:

\[I=\lfloor \sqrt{X} \rfloor\]

\[A_{1} = I.\]

We will refer to this formulae during the programming process. Now let's go to the implementation.

Implementation

From the description above it becomes obvious that the first step which we need to do is to calculate the integer square root $I$. We can calculate this value iteratively increasing some number $k$ starting from $1$ until $k^2 \gt X$. Reaching this condition means that we have found the integer square root $I$ of the number $X$:

\[I = k - 1.\]

We can achieve this using the following C code:

unsigned long isqrt(const unsigned long X)
{
    unsigned long k = 1, result = 1;
    while (result <= X)
    {
        k++;
        result = k*k;
    }
    return k--;
}

There are more efficient methods available, but this one is easier to understand.

Then we need to find $A_n$¹ I have to admit that this sentence was added after some discussion at Reddit and it is quite bold. I tried to find some facts which will prove that I am wrong, but so far I have found none. But I am not a floating-point expert, though, so if you have information on this or, even better, the proof - please feel free to contact me. I am interested in improving this code and always ready to admit my mistakes. iteratively. Here the question arises: how should we peek $n$? We can paraphrase this question: how many times should we approximate the value?

In C we can use the following trick: considering that the floating-point numbers have finite precision, we may iterate until the value $A_n$ and $A_{n-1}$ will not become equal when compared using == operator in C. That means that we have reached the maximum possible precision on the current hardware (at least for this implementation). That is to say that I expect the method to converge as soon as

\[\left[A_{n-1} - A_n \right] \lt \epsilon\]

where $\epsilon$ is the machine epsilon for double-precision floating-point values (defined as DBL_EPSILON constant in C).¹

Please keep in mind that this approach may not work in some other programming environments. If it is the case, limit $n$ with some sane number. Also keep in mind, that we are targeting platforms with IEEE 754-compliant floating-point units.

So, finally, here is the code which implements calculation of the square root using Newton's method (with some checks omitted for clarity):

double nsqrt(double X)
{
    /* ... */
    unsigned long I;
    double A_prev, A;
    if (X == 0.0 || X == 1.0 /* .. */)
    {
        return X;
    }
    /* ... */
    I = isqrt((unsigned long)X); /* see above */
    if (X == (double)(I*I)) /* exact root */
    {
        return (double)I;
    }
    A = A_prev = I;
    do {
        A_prev = A;
        A = (A + X/A)/2.0;
    } while (A_prev != A);

    return A;
}

The reader might be interested in how well the code above performs compared against the sqrt() function from the C standard library. According to my tests, precision wise, it produces very similar or even the same results, at least on Windows (x86_64) and Linux (x86_64, ARM). I believe that it would be the case for Plan 9 as well. There is one notable exception though: when calculating $\sqrt{2}$ the results produced by the function above and the built-in one might differ. It seems that the functions in standard C library implementations may return the precomputed value of $\sqrt{2}$ (the M_SQRT2 constant), which might have been computed using different, possibly more precise, method.

Let's add the corresponding check to the code (as well as some other checks). Here is the revised version of the function:

double nsqrt(double X)
{
    const double inf = 1.0l/0.0l; /* positive infinity */
    const double ninf = -inf; /* negative infinity */
    const double nan = 0.0l/0.0l; /* not a number */
    unsigned long I;
    double A_prev, A;
    if (X == 0.0 || X == 1.0 || X == inf)
    {
        return X;
    }
    else if (X == 2.0)
    {
        return M_SQRT2;
    }
    else if (X == ninf || X < -0.0)
    {
        return nan;
    }
    /* NaN cannot be compared using == operator */
    else if (memcmp((void *)&X, (void *)&nan, sizeof(double)) == 0)
    {
        return nan;
    }
    /* I =  floor(sqrt(X)) */
    I = isqrt((unsigned long)X);
    if (X == (double)(I*I)) /* exact root */
    {
        return (double)I;
    }
    /* Newton's method: A{n} = (A{n-1} + X/A{n-1})/2 */
    A = A_prev = I; /* A{1} = I, or A{1} = floor(sqrt(X)) */
    do {
        A_prev = A;
        A = (A + X/A)/2.0;
    } while (A_prev != A);
    return A;
}

As far as I can tell, this version should be standard-compliant (at least on my hardware), but I do not want to make such a bold statement, especially considering that developing the standard compliant version of sqrt() was not the main point of this post.

Moreover, I do not want to claim that this function works in the same way as sqrt() from the standard C library. For some input values that can be not true. At very least you can expect that the results would be very similar. Please keep it in mind when comparing the implementations.

The main point of this post is to show that one can solve the problem without sacrificing precision with a small amount of code, a bit of math and some knowledge of how the hardware works.

The Full Example

/* to make assert() work in release builds */
#undef NDEBUG

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <assert.h>

#include <math.h>

/*
Given a number N, the task is to find the square root of N without using sqrt() function.
*/
static unsigned long isqrt(const unsigned long X)
{
    unsigned long k = 1, result = 1;
    while (result <= X)
    {
        k++;
        result = k*k;
    }
    return k--;
}

static double nsqrt(double X)
{
    const double inf = 1.0l/0.0l; /* positive infinity */
    const double ninf = -inf; /* negative infinity */
    const double nan = 0.0l/0.0l; /* not a number */
    unsigned long I;
    double A_prev, A;
    if (X == 0.0 || X == 1.0 || X == inf)
    {
        return X;
    }
    else if (X == 2.0)
    {
        return M_SQRT2;
    }
    else if (X == ninf || X < -0.0)
    {
        return nan;
    }
    /* NaN cannot be compared using == operator */
    else if (memcmp((void *)&X, (void *)&nan, sizeof(double)) == 0)
    {
        return nan;
    }
    /* I =  floor(sqrt(X)) */
    I = isqrt((unsigned long)X);
    if (X == (double)(I*I)) /* exact root */
    {
        return (double)I;
    }
    /* Newton's method: A{n} = (A{n-1} + X/A{n-1})/2 */
    A = A_prev = I; /* A{1} = I, or A{1} = floor(sqrt(X)) */
    do {
        A_prev = A;
        A = (A + X/A)/2.0;
    } while (A_prev != A);
    return A;
}

int main(int argc, char **argv)
{
    const double inf = 1.0l/0.0l; /* positive infinity */
    const double ninf = -inf; /* negative infinity */
    const double nan = 0.0l/0.0l; /* not a number */
    size_t i;
    /* some edge cases */
    assert(isnan(sqrt(nan)));
    assert(isnan(nsqrt(nan)));
    assert(isnan(sqrt(-1.0)));
    assert(isnan(nsqrt(-1.0)));
    assert(sqrt(inf) == nsqrt(inf));
    assert(isnan(sqrt(ninf)));
    assert(isnan(nsqrt(ninf)));
    assert(sqrt(0.0) == nsqrt(0.0));
    assert(sqrt(-0.0) == nsqrt(-0.0));
    assert(sqrt(1.0) == nsqrt(1.0));
    assert(sqrt(2.0) == nsqrt(2.0));

    for (i = 0; i < 100; i++)
    {
        const double r = sqrt(i), nr = nsqrt(i);
        printf("%lu - sqrt(): %.50f, nsqrt(): %.50f. same: %s\n",
                i, r, nr, (r == nr ? "true" : "false"));
    }
    return 0;
}

Footnotes:

I have to admit that this sentence was added after some discussion at Reddit and it is quite bold. I tried to find some facts which will prove that I am wrong, but so far I have found none. But I am not a floating-point expert, though, so if you have information on this or, even better, the proof - please feel free to contact me. I am interested in improving this code and always ready to admit my mistakes.

Facilities for Context Switching and Coroutines on AVR microcontrollers (and AVR-based Arduino boards)

Fri, 15 May 2020 00:00:00 +0300

In this short post, I want to present a small project on which I have been working for the last couple of weeks. It is a small library to control an AVR micro-controller execution context. Additionally, it can be used on AVR-based Arduino boards.

I have to note that this is my first serious attempt in micro-controllers programming. Nevertheless, I tried to do my best, but bugs are always possible, so bug reports are welcome. Caveat lector.

Initially, the project started as a side effect of my attempt to understand how task switching is performed in operating systems. I believe that it is better to use microcontrollers to understand the concepts like this one because the generic computers are meant to run full-featured, multi-user operating systems with virtual memory support. These things, while important on their own, considerably complicate the low-level programming to the point where it is hard to see the forest behind the trees.

The functionality, developed in the process, turned out to be generic enough, so I decided to continue to work on the project, and implemented substitutes for functions getcontext(), setcontext(), makecontext(), swapcontext(). These functions are commonly available on UNIX-like operating systems because they used to be a part of the POSIX standard (You can read about them here and here). They can be used to implement many interesting abstractions, but in most cases, this functionality is used to implement coroutines. I decided to go ahead and implemented the asymmetric stackful coroutines (as in the Lua programming language).

I tried to make the library's interface as easy to use as possible. There are 8 functions (4 to work with execution context, 4 for to work with coroutines), 4 macros and 2 data types. The interface can be summarised as follows (to give you the high level view):

/* Context Switching: avrcontext.h */

typedef struct avr_context_t_ {
    /* ... */
} avr_context_t;

typedef void (*avr_context_func_t)(void *);

#define AVR_SAVE_CONTEXT(presave_code, load_address_to_Z_code) /* ... */
#define AVR_RESTORE_CONTEXT(load_address_to_Z_code) /* ... */

#define AVR_SAVE_CONTEXT_GLOBAL_POINTER(presave_code, global_context_pointer) /* ... */
#define AVR_RESTORE_CONTEXT_GLOBAL_POINTER(global_context_pointer) /* ... */

void avr_getcontext(avr_context_t *cp);
void avr_setcontext(const avr_context_t *cp);

void avr_swapcontext(avr_context_t *oucp, const avr_context_t *cp);
void avr_makecontext(avr_context_t *cp,
                     void *stackp, const size_t stack_size,
                     const avr_context_t *successor_cp,
                     avr_context_func_t funcp, void *funcargp);

/* Asymmetric Stackful Coroutines: avrcoro.h */

typedef struct avr_coro_t_ {
    /* ... */
} avr_coro_t;

typedef enum avr_coro_state_t_ {
    AVR_CORO_SUSPENDED = 0,
    AVR_CORO_RUNNING,
    AVR_CORO_DEAD,
    AVR_CORO_ILLEGAL,
} avr_coro_state_t;

typedef void *(*avr_coro_func_t)(avr_coro_t *, void *);

int avr_coro_init(avr_coro_t *coro,
                  void *stackp, const size_t stack_size,
                  avr_coro_func_t func);
int avr_coro_resume(avr_coro_t *coro, void **data);
int avr_coro_yield(avr_coro_t *self, void **data);
avr_coro_state_t avr_coro_state(const avr_coro_t *coro);

I do not want to repeat myself here, so if you are interested, you can find the full project documentation on the project's page on GitHub. There are examples included. I tried to arrange them in such a way that one can use them as a tutorial. They are, I hope, properly documented as well.

The list of available examples:

Context Switching:
Coroutines:

The library can be installed via "Library Manager" in Arduino IDE (search for AVR-context).

The project turned out to be very interesting on itself and involved some research. The references to the specifications, papers and other resources can be found in the project's documentation. I may do a couple of publications which demonstrate how this library was developed. Although the result is hardware specific, the approach itself can be adapted to almost any hardware platform.

High-Quality Video Playback on Linux

Mon, 07 Oct 2019 00:00:00 +0300

Some programs are so damn good that you start to see them without any relation to the platform on which they run. In this case, you start looking for their substitutes if you are unable to use them on some platforms, often without success. In my opinion, one of the better combinations for video playback is Media Player Classic Home Cinema in combination with MadVR video renderer. It is rather hard to beat this combination, but there is a very good, open-source alternative available on Linux: mpv+SMPlayer. In this post, I am going to describe how I essentially repeated my configuration for high-quality video playback on Linux.

I believe that there is one thing worth noting: as both SMPlayer and mpv are available on Windows the information from this post might be useful if you plan to use these programs on Windows as well. I think that no additional adaptation required for this platform. The same goes for macOS.

I would suggest you keep the man page of mpv opened so that you can quickly read about the configuration options referenced in this post.

Important Options for High-Quality Video Playback

To improve video playback quality, we need the following:

Good scaling algorithms - I believe that this part is obvious. I should note that scaling algorithms are computationally intensive in general and require a fairly high-performance video card. I suggest that you use the following algorithms: ewa_lanczos (aka jinc) with an anti-ringing filter for up-scaling and chroma scaling, mitchell for down-scaling. A better alternative to ewa_lanczos would be ewa_lanczossharp, but it is very computationally intensive. If you have decided to use it, I believe that you might not need the anti-ringing filter in that case.
Smooth-motion (with V-Sync). Here I should note that this is not converting video to the higher frame-rate as some might think. This technique allows frames from a video to better synchronise with frame-rate of your display. Without this, some judder might appear during motion. This technique is called Interpolation in mpv's manual, and there is an in-depth explanation of it on the wiki of the project.
Debanding filter - prevents colour banding from appearing on the scenes containing some gradients.

Configuring mpv

Let's create a configuration file for mpv which uses the techniques mentioned above. The configuration file of mpv is located here: ~/.config/mpv/mpv.conf, we are going to add the options described below into it.

In some cases, I am going to mention settings both for middle-end and high-end systems. In my opinion, the visual difference between them is so subtle that I would suggest that you go with the configuration for middle-end systems first, especially if you use a laptop. If you use a relatively modern desktop or do not mind extra battery drain and fan noise then go experiment with the configuration for high-end systems.

The first thing which we should set is a video renderer profile. There are many of them but gpu and gpu-hq are the ones in which we are interested the most. These, as you might have guessed, allow offloading most of the video post-processing and rendering to a GPU using OpenGL or Vulkan API. gpu-hq is pre-configured to use higher quality, more computationally intensive filters.

middle-end systems:

profile=gpu

high-end systems:

profile=gpu-hq

We may use Vulkan or OpenGL as a GPU API. Honestly, I have not noticed any difference in performance when playing a video using either, so I would suggest that you stick with OpenGL as the most compatible option. We are going to enable V-Sync as well.

gpu-api=opengl
opengl-swapinterval=1

If you want to use Vulkan instead, here is how to do it:

gpu-api=vulkan
vulkan-swap-mode=fifo

The next logical step is to configure smooth-motion. Here is how:

video-sync=display-resample
interpolation
tscale=oversample

Now let's configure scaling.

middle-end systems:

scale=ewa_lanczos:scale-antiring=1
cscale=ewa_lanczos:scale-antiring=1
dscale=mitchell
correct-downscaling

high-end systems:

scale=ewa_lanczossharp
cscale=ewa_lanczossharp
dscale=mitchell
correct-downscaling

It is a good idea to enable dithering when it is necessary. mpv uses a fairly good dithering algorithm by default.

dither-depth=auto

The last step is to offload video decoding to GPU when possible. It is especially useful for laptops. We are using auto-copy instead of auto to enforce copying back decoding results back to the system RAM. It might be necessary for some filters to work and helps to avoid some decoding issues at the expense of a relatively small performance loss.

hwdec=auto-copy

Using SMPlayer with a Pre-configured mpv Instance

I prefer to use mpv as a back-end of SMPlayer. If you are going to use mpv as a standalone video player then you can skip reading this section.

Modern versions of SMPlayer can use mpv as its back-end without any additional configuration. However, SMPlayer tries to have mpv under its full control and starts it with --no-config option. It forces mpv to ignore its default configuration file. Fortunately, SMPlayer can pass user-defined command-line options to mpv, which allows us to bypass this limitation. To do it we have to use this extra option to force mpv to load its configuration file:

--include=~/.config/mpv/mpv.conf

Here is the screenshot which shows us how to do it:

Please keep in mind that SMPlayer expects that mpv does not load its configuration file, so be conscious about what you have in the mpv.conf file.

Also, it might be a good idea to configure SMPlayer to use Default video output engine with disabled post-processing:

Conclusions

In this post, we have configured mpv and SMPlayer for high-quality video playback. I think that there are some things left which are worth noting.

Firstly, the video output quality depends mostly on the quality of the video files. No amount of configuration will make a miracle here if all you have is a low-quality media material.

Secondly, the quality of the display matters a lot. It does not necessarily mean that you should use these ridiculously expensive professional displays for high precision colour work. Adequately priced display with good IPS matrix will do. I doubt that you will see any difference on a low-end TFT monitor.

I think that these things are rather obvious, but I wanted to have them mentioned anyway.

Hopefully, this post will improve your ~~anime~~ video playback experience and make your entertainment more joyful.

Update: MSI Installer for GNU Emacs 26.3 for Windows with Per-User Installation Support

Tue, 01 Oct 2019 00:00:00 +0300

I have been working on improving Emacs installer for Windows to add support both per-user and per-machine installations. It was made to address the installation issues of users without administrative privileges. This post is a follow up to a post I have made recently.

This effort resulted in adding support for building per-user installers. These are available alongside the usual, per-machine installers. It should be noted, though, that their name might be a little bit deceptive because they support installation in both per-machine and per-user mode. As you might expect the latter does not require administrative privileges.

Feature-wise both kinds of installers provide similar functionality with one notable exception: the per-user installers unable to set and modify environmental variables conditionally depending on selected scope and, thus, unable to add installation directory of Emacs to the Path. This is a limitation of tooling.

Please keep in mind that mixing both per-user and per-machine installations of the same package on the same machine might result in strange behaviour. I would suggest sticking with classical, per-machine only installers if you have enough privileges on your machine.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

As usual, If you used an older version of the installer you should be able to perform an in-place upgrade.

The screenshots provided below show the installation of a per-user installer in advanced mode.

Enjoy!

Update: MSI Installer for GNU Emacs 26.3 for Windows

Thu, 12 Sep 2019 00:00:00 +0300

Following the GNU Emacs 26.3 release, my MSI installer for GNU Emacs has been updated!

This time it is rather a belated update.

You can find all the sources on GitHub as well as the pre-built installers for the latest release of GNU Emacs. The provided installers bundle official, unmodified GNU Emacs binaries for Windows.

If you used an older version of the installer you should be able to perform an in-place upgrade.

Enjoy!

Integrating Xfce with LightDM Display Manager

Fri, 19 Jul 2019 00:00:00 +0300

One of the most basic security features of any laptop or workstation is the ability to lock the sscreen. It might be convenient in many other, non-security related, scenarios as well. In most cases, this feature works without user's intervention on most of the Linux distributions, yet it did not work for me in Xfce4 with LightDM on Arch Linux. As I understand, Xfce does not have its display manager, so it relies on third-party solutions, mostly Gnome Display Manager (GDM). As I prefer Xfce as my desktop environment, I did not want to install GDM as it needs many Gnome libraries to work. Because of this, I decided to use LighDM as my display manager, which is more desktop environment agnostic and lightweight. Unfortunately, Xfce lacks proper integration with it (at least in Arch Linux). In this post, I want to provide a solution to this problem. Moreover, I believe that information in this post might give some ideas to the users of the other desktop environments and window managers on how to integrate them with LightDM.

To some extent, this post is a continuation of the other LightDM related post which I have posted earlier.

If the first two buttons from the image below do not work on your system, you might want to continue reading this post.

How Xfce Initiates Screen Locking and User Switching

Xfce does not do screen locking or user switching itself, it delegates this functionality to the other programs.

For screen locking Xfce executes xflock4 program which is a shell script. The script locks the session by calling the following programs if they are present on the system (in the following order):

xscreensaver-command
gnome-screensaver-command
xlock
slock

Similarly, Xfce delegates user switching to the gdmplexiserver which is (or was) a part of the Gnome Display Manager package. As you can see, Xfce is attuned to reuse some of the parts of the GNOME desktop environment.

Considering that LightDM has its utility to control itself, the dm-tool, we might try to "deceive" Xfce to invoke the dm-tool instead. We could accomplish that by placing the scripts which call the dm-tool with a required parameter (lock or switch-to-greeter) and are named as above mentioned programs into a directory from the $PATH environmental variable (/usr/local/bin seems like the right choice).

The Scripts to Perform Screen Locking and User Switching

At this point, it is obvious that we need two executable shell scripts, one for session locking and one for user switching, which we should place into /usr/local/bin folder. For the first one, I propose to use the name slock or xlock (I used to recommend xscreensaver-command, but I had some problems in SMPlayer in this case). Here is the code:

#!/bin/sh

# fake slock to make xflock to use lightdm locker

DMTOOL_AVAILABLE="$(which dm-tool)"

if [ -n $DMTOOL_AVAILABLE ] ; then
    dm-tool lock
fi

For the second case, user switching, we might use a very similar script, named as gdmplexiserver (the only difference is a parameter to the dm-tool):

#!/bin/sh

# fake gdmplexiserver to make xflock to use lightdm locker
# for user switching

DMTOOL_AVAILABLE="$(which dm-tool)"

if [ -n $DMTOOL_AVAILABLE ] ; then
    dm-tool switch-to-greeter
fi

If you are a systemd user, you might try to use a script which relies on loginctl for both cases:

#!/bin/sh

LOGINCTL_AVAILABLE="$(which loginctl)"

if [ -n $LOGINCTL_AVAILABLE ] ; then
    loginctl lock-session
fi

After you have done all the steps mentioned above, screen locking and user switching in Xfce should work as expected.

UPD:

20.07.19 - Note about problems with xscreensaver-command.

Using LightDM with an External Monitor on a Laptop or with the Multi-monitor Setups

Tue, 16 Jul 2019 00:00:00 +0300

Like many other users, I find it convenient to connect an external monitor to my laptop sometimes. As I often do this, I expect this functionality to work flawlessly but, unfortunately, I experienced some problems when using LightDM on Arch Linux . By default, LightDM tries to mirror data on multiple displays, and it does not work well when you have monitors with different resolutions. In this post, I want to share my solution to this problem. I expect that this solution might be useful not only for laptop users but for the workstation users with multi-monitor setups as well. Moreover, if LightDM's user interface sometimes stops responding to your actions, this post might be useful for you.

In general, on a laptop with an external monitor, I expect the login screen to appear on it and have the laptop screen disabled in that case. If there are multiple external monitors connected to the system, I want only one of them used for a login screen.

Fortunately, these actions can be programmed using a UNIX shell script build around the functionality of the xrandr utility.

When used without any parameters it prints the list of monitor outputs alongside the information about the connected monitors:

artem@artbox:~$ xrandr
Screen 0: minimum 8 x 8, current 1366 x 768, maximum 32767 x 32767
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 340mm x 190mm
   1366x768      60.03*+
   1280x720      59.74
   1024x768      60.00
   1024x576      60.00    59.90    59.82
   960x540       60.00    59.63    59.82
   800x600       60.32    56.25
   864x486       60.00    59.92    59.57
   640x480       59.94
   720x405       59.51    60.00    58.99
   680x384       60.00
   640x360       59.84    59.32    60.00
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

We could filter out the information about the available outputs using the UNIX tools:

artem@artbox:~$ xrandr | grep connected | cut -d ' ' -f 1-2
LVDS1 connected
DP1 disconnected
HDMI1 disconnected
VGA1 disconnected
VIRTUAL1 disconnected

Keeping in mind that an internal laptop screen is usually connected using the LVDS interface, we could use the information obtained from the xrandr tool to achieve what is required.

Let's outline the logic of the script using pseudo-code:

var primary_out = nil
var to_disable = nil

foreach monitor_out in list_monitor_outputs() do
    if is_connected(monitor_out) then
        if is_connected_via_LVDS(monitor_out) then
            to_disable = monitor_out
        else if primary_out == nil then
            primary_out = monitor_out
        else
            disable_monitor_output(monitor_out)
        endif
    endif
endfor

if primary_out != nil and to_disable != nil then
    set_as_primary_monitor_output(primary_out)
    disable_monitor_output(to_disable)
else if primary_out != nil then
    set_as_primary_monitor_output(primary_out)
endif

After translating the pseudo-code above into a shell script, I got the following code:

#!/bin/sh

# the script will not work if xrandr is not available
if [ -z "$(which xrandr)" ]; then
    exit 1
fi

DISABLE_SUBSTRING="LVDS"

TO_DISABLE=""
PRIMARY_OUT=""

old_IFS="${IFS}"
IFS=$'\n'
for out in `xrandr | grep connected | cut -d ' ' -f 1-2`; do
    name=`echo $out | cut -d ' ' -f 1`
    state=`echo $out | cut -d ' ' -f 2`
    if [ "$state" = "connected" ]; then
        case "$name" in
            # disable a monitor connected via LVDS
            ${DISABLE_SUBSTRING}*)
                if [ -z "$TO_DISABLE" ]; then
                    TO_DISABLE="$name"
                fi
                ;;
            *)
                # set the 'first' external monitor as the
                # primary one, disable the other external monitors
                if [ -z "$PRIMARY_OUT" ]; then
                    PRIMARY_OUT="$name"
                else
                    xrandr --output "$name" --off
                fi
                ;;
        esac
    fi
done
IFS="${old_IFS}"

# If there is an internal screen, as well as at least one external monitor, then
# disable the internal monitor and use the external monitor as the primary one.
#
# Otherwise, if there are any external monitors, use the 'first' detected one
# as the primary monitor.
if [ -n "$TO_DISABLE" ] && [ -n "$PRIMARY_OUT" ]; then
    xrandr --output "$PRIMARY_OUT" --primary --auto --output "$TO_DISABLE" --off
elif [ -n "$PRIMARY_OUT" ]; then
    xrandr --output "$PRIMARY_OUT" --primary --auto
fi

exit 0

To use the script, one should save it into an executable file and alter the LightDM's settings to use it to configure the displays.

In order to accomplish this one should change the display-setup-script in the [Seat:*] section of the LightDM configuration file (/etc/lightdm/lightdm.conf):

[Seat:*]
...
display-setup-script=/path/to/the-script
...

To apply the new settings, please restart the LightDM daemon. The next LightDM session should use the script to configure monitors.