i3 window manager setup on Debian Bullseye

In this blog, we will look at setting up i3 tiling window manager, and a status bar for i3 named i3status-rust. All of this is tested on Debian Bullseye. Some basic understanding of configuring i3 is expected.

This is part 2 in a series of 3 blogs regarding setup of Debian Bullseye on a Laptop with i3 window manager. Read part 1 here.

Login manager

A display manager, or login manager, is typically a graphical user interface that is displayed at the end of the boot process in place of the default shell.

Let’s start by installing a login manager. We will be using LightDM.

This will also install the GTK greeter for LightDM. Next time we boot up, this is what will greet us during login instead of the command line prompt.

Installing i3

Next, lets install i3 and related components:

So what did we just install?

  1. i3 – The tiling window manager
  2. i3lock – Simple screen locker
  3. dunst – A notification daemon
  4. rofi – Window switcher & application launcher

For i3lock, dunst and rofi I use the default configuration that comes out of the box but all of these are quite configurable.

  • i3lock: this man page lists supported arguments.
  • rofi: I found this blog that has a series of posts describing what rofi can do.
  • dunst: ArchWiki goes into some configuration details.

Before starting with the next step, let’s confirm that everything done till now works well. Restart the machine, and we should first be greeted with the drive decryption prompt, followed by the login manager. Once we login, we should see i3 with the default configuration.

i3 configuration

My entire dot-config is available here and the i3 configuration is available here. It utilizes various scripts present in the bin folder at the root of the repository. It also references a few applications that I will be outlining in the next blog.

Third party fonts used, all open source, are listed here and can be installed by following the approaches outlined on the Debian wiki.

Here’s how my desktop looks with a single monitor:

A screenshot from the social tab of my i3 window manager. Single monitor.
A screenshot from the social tab of my i3 window manager. Single monitor.
The full desktop with the second monitor connected via HDMI.
The full desktop with the second monitor connected via HDMI.

Workspace configuration

In i3, workspaces are an easy way to group a set of windows.

I have 5 workspace dedicated to:

  1. Coding,
  2. Browsing,
  3. Social apps (In screenshot),
  4. Terminal / Editor,
  5. Media / Others.

Commonly used applications are mapped to specific workspace via the i3 configuration file. The workspace 1: Coding, 2: Browsing and 5: Media / Others appear on the secondary monitory if it is connected. All of this is configured using the i3 config file. The social workspace has a slightly complicated layout defined in it’s layout file, generated using the i3-save-tree utility.

i3 status bar configuration

I use the i3status-rust status bar’s toggle icons to make common actions easier to perform. The associated scripts for these toggle icons are located here and the i3rust bar configuration is here. The touch pad toggle also has a global keyboard shortcut configured via xbindkeys. I’ll discuss this in some more detail later. When the external display is connected another i3rust bar is displayed with additional information. The configuration for that can be found here.

Custom scripts / Toggles

My i3status bar links has a few toggles that trigger custom scripts. Here’s a brief description of these:

  1. Limit BAT – I often have my laptop connected to AC power. To preserve battery life it’s generally a good idea to limit the maximum battery charge to about 70-80%. Enabling this switch limits the battery charging to 75%.
  2. HDMI – Toggles the external monitor if connected. Two scripts are used here: activate_hdmi.sh enables the HDMI display, and laptop_only.sh disables it. Modify the scripts using xrandr to configure it as per your setup.
  3. VPN – Uses wg-quick to toggle the Wireguard interface.
  4. Touchpad – This uses 2 scripts: 1. touchpad_is_enabled.sh and 2. toggle_touchpad.sh. The touchpad’s current state is determined by the first script, and the second one is used to toggle it’s state.

The custom scripts work with my laptop, but may need tweaks to work with your hardware. I’ve found ArchWiki to be a good source of information regarding specific laptops.

In the next blog, we will discuss Laptop keybindings and the applications that I use daily.

Debian Bullseye setup with NVIDIA hybrid graphics

I had been using PopOS on my laptop for a couple of years, but wanted to shift back to using the i3 window manager. My laptop has the NVIDIA MX150 graphics chipset along with the inbuilt Intel GPU and the primary reason to use PopOS was to get switchable NVIDIA graphics working properly. I had trouble getting this to work back in June, 2018 but I expect it to work now with recent versions of the X.Org Server and the NVIDIA graphics driver.

To get the recent version of the Linux kernel and various packages I will be install the testing version of Debian code-named Bullseye.

This is part 1 in a series of blogs regarding setup of Debian Bullseye on a Laptop with i3 window manager.

This blog post will touch on important points to consider when setting up Debian Bullseye on a laptop, and the setup of X.org server with NVIDIA graphics drivers.

Note: A lot of the software recommendations and configurations are my personal preferences. Hence this blog will not always go into details expanding why something is being installed.

Laptop configuration

I use an Asus Vivobook S15, 2018 model. My laptop configuration is as follows:

  • CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
  • RAM: 16 GB
  • Network Chipset: Intel® Dual Band Wireless-AC 8265
  • Storage: 128 GB SATA SSD, 128 GB + 1TB SATA HDD 5400rpm
  • Audio: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
  • Display:
    1. NVIDIA Corporation GP108M [GeForce MX150]
    2. Intel Corporation UHD Graphics 620

Debian installation

We will use the network install ISO (netinst). I will not go into the details of the installation process but just mention a couple of noteworthy things,

  1. I encrypted my home partition by following the instructions here. This will add an additional step during each boot cycle to enter the password, in order to decrypt the hard drive.
  2. The WiFi chip needs a bit of additional configuration which I’ve covered in blog post here.

During the install I did not install any desktop environments, as I will be setting up the i3 window manager later.

Setting up encryption on the drive

Post install setup

Since I did not install any desktop environment, the first boot-up displays a command line prompt.

Let’s get some basic utilities setup,

  1. Install sudo and add the current user to the sudoer’s list – usermod -a -G sudo <username>. Run the previous commands as root.
  2. Install:
    1. ncduNCurses Disk Usage
    2. htopInteractive Process Viewer
    3. lessMan page
    4. unzip & zip – Unzip / zip an archive in Linux
    5. wgetRetrieving files using HTTP, HTTPS, FTP and FTPS
    6. curlcommand line tool and library for transferring data with URLs

The commands below can be used to complete the steps above:

X.Org server setup

I’m using X.Org server with Xinput:

NVIDIA driver installation

All the information regarding NVIDIA driver installation is available in the Debian documentation.

My output for the command: lspci -nn | egrep -i "3d|display|vga" returns:

This means that I have a hybrid graphics chipset, and need to look at this additional documentation after installing the driver. This allows certain applications to be rendered on the dedicated MX150 GPU while the basic UI still uses the low powered Intel HD GPU.

Installation notes

Update apt sources to add non-free:

Then run the following to install the Linux headers and the GPU driver:

This installed NVIDIA driver version: 440.100-2

Using NVIDIA PRIME render offload

At the time of writing this blog, Nvidia driver version 450.xx is available in Debian bullseye repositories, so these should not be necessary anymore. To identify the driver version, you can run: nvidia-settings -v

The documentation states that this should work out of the box, but on my laptop running: xrandr --listproviders did not display a provider named NVIDIA-G0 which is mentioned here.

I decided to install NVIDIA driver version: 450.xx from Debian sid. To do that, I added the following to the sources.list and then used apt-pinning:

Once a window manager is setup (we will do this in the next blog), run nvidia-settings to configure application and power profile for the dedicated GPU.

In the next blog, I will share my i3 window manager configuration and go through some of finer details while setting it up.

Vagrant development environment for PHP

As a developer, I work on projects that require a variety of software, each tuned to different configurations. The easiest way to achieve this is to set up a virtual machine and configure that as per the need of the project. This allows me to keep my host machine clean, and share the virtual machine with other developers on the project.

In this blog, I’ll describe the configuration of a Vagrant machine that I’ve setup for PHP web development. Here’s a link to the box on vagrant cloud.

Vagrant configuration

Recommended configuration

The vagrant box runs Debian 10 Buster. It uses,

  1. 2 dedicated CPU cores
  2. 1560 MB of RAM from the host machine.

Port configuration

Following is the port configuration for the vagrant box,

Other configuration

  • Added vagrant user to www-data and adm group, in order to handle Apache permissions and view application logs.
  • SSH agent forwarding has been enabled.

Installed software

Listed below are software that have been installed on the system,

  1. Apache 2.4.38
  2. MariaDB 10.3.18
  3. htop, ncdu, curl, git, unzip
  4. PHP 7.3 and extensions
  5. Composer 1.9.1 (globally)
  6. Redis 5.0.3
  7. Node 12.14. 1 and npm 6.13.4 (via nvm)

Software configuration

  1. The base directory for Apache2 is configured to /vagrant/code. The vagrant user has been added to the www-data group to handle permission issues.
  2. Apache2 mod_rewrite module has been enabled.
  3. MariaDB has been configured with the following users,
    • Username: root / Password: T0P!33L
    • Username: admin / Password: C00La!d
  4. Following changes have been made to MariaDB configuration,
    • Increased innodb_buffer_pool_size to 768MB
    • Set innodb_file_per_table to 1.
    • Set max_allowed_packet to 256MB for MySQL, and 192MB for mysqldump
    • Enabled slow query logging. Long query time has been set to 5 seconds. Slow logs will be written to /var/log/mysql/mysql_slow.log.
  5. All PHP extensions required to run Laravel 6 have been installed. In addition, the tidy, xdebug, redis, and yaml extensions have been installed.
  6. Following changes have been made to PHP configuration file,
    • upload_max_filesize and post_max_size have been set to 20MB.
    • memory_limit has been set to 256MB.
    • Enabled error logging for both Apache and CLI.
  7. For Redis, maxmemory has been set to 256MB.
  8. Composer bin folder has been added to the PATH via .bashrc

PHP debugging support

Debugging support for PHP has been added via Xdebug and tested using VSCode with the PHP Debug extension.

Consider a sample VSCode project – debugging, created under /vagrant/code/debugging. This project has a file called index.php. Following is the configuration that needs to be put under the VSCode launch file. (/vagrant/code/debugging/.vscode/launch.json).

Following is the configuration for Xdebug,


Future improvements

I currently have the following things in mind,

  • The box is set to use 1536MB of RAM, and I might have to tweak this a little higher.
  • Test debugging support for applications run via the PHP server and on the PHP CLI
  • Install and setup XHProf and XHProf UI.

I plan on keeping this box up-to-date for the foreseeable future. I’m open to suggestions on how this box can be improved, and made more useful for PHP developers to quickly start their development.

Git hooks: Permission denied on a new HDD

I recently got a new Samsung 860 EVO 1TB SSD to add to my existing 128GB SSD that was filling up fast. After setting up the SSD on my machine using fstab, I started moving all my vagrant boxes and projects to a new partition dedicated to development. I mounted all the partitions under my home folder, and gave myself ownership of the respective folders.

I was ready to submit a patch to Wikimedia’s Gerrit platform. When you commit code, Gerrit runs a git commit-msg hook to add a Change-Id to every patch that is submitted for review. Committing code locally gave me the following error,

Continue reading “Git hooks: Permission denied on a new HDD”

Setting up MediaWiki, Vagrant and VSCode

The guide describes how to setup MediaWiki for development on Vagrant while adding support for debugging on VSCode using the XDebug PHP extension.

Various documents have been linked to which contain relevant information rather than copying it here again.

Continue reading “Setting up MediaWiki, Vagrant and VSCode”

Kerala Log 6 – Willingdon island and Folklore museum

Day 21 – Jan 8th

Emerging from the need for a new port in Kochi is the largest artificial island in India – Willingdon island. We had an early start from Orchid Homestay to visit the island and a few other places on the way.

Continue reading “Kerala Log 6 – Willingdon island and Folklore museum”