Glanceable Displays: Setting Up Our Display

Preface¶

This is the fourth article in a series about Glanceable Displays and my efforts to create one for my household. For other articles in the series, click on the title of the article under the heading “Glanceable Displays” on the right side of the webpage.

Introduction¶

In the first article, Glanceable Displays: What Are They?, I introduced the concept of a Glanceable Display, describing a number of things to consider if you decided to embark on a project like this. Assuming you decided to proceed, the article Glanceable Displays: Installing Raspbian on a Raspberry Pi detailed how I went from an unformatted Raspberry Pi to one with the Raspbian operating system installed. As I prefer working from my own workstation, I also detailed the setup of the SSH service on the Raspberry Pi to allow for remote connections. Finally, the article Glanceable Displays: Fine Tuning A Raspberry Pi Installation showed how I filled in a number of gaps that I encountered with the normal installation, namely setting up a wireless connection with my network and ensuring the Raspberry Pi has a solid understanding of the current time.

Having taken all of those steps to be confident that setting up the actual display will work, it is time to jump right in and set the display up. But what is it actually that I was setting up?

What Are Our Display’s Implementation Requirements?¶

When it comes down to it, the articles in the series have been building up to this point. I now have a glanceable display is a Raspberry Pi. Upon boot, it will start a web browser pointing at a specific webpage. It’s that simple. However, the devil is in the requirements.

The high level requirements for the display were covered in the first article in this series, Glanceable Displays: What Are They?. What is left are the specific requirements that will realize those high level requirements into an actual display: the implementation requirements.

The first set of implementation requirements is that any administration of the machine can be performed from my desktop. With the exception of the Raspberry Pi seizing up, which I have noticed from time to time, I should not have to touch the Raspberry Pi itself. For the most part, I will be running sudo reboot to restart the machine, but all of that should be done without the need to plug a keyboard into the Raspberry Pi. Thanks to the documentation in the previous articles, these requirements have been completed.

The second set of implementation requirements is that after a reboot of the machine, I shouldn’t need to plug in a keyboard and type some commands to get it started. After the machine starts, it should open a browser and display the page or pages that are required. To be clear, on reboot with no keyboard and no mouse, the display should start by itself. The physical cost of plugging a keyboard into the machine kind of defeats the “appliance” feel that I want it to have.

The final set of implementation requirements is that, to the best extent possible, any processing of what to show on the display should be performed on a machine other than the Raspberry Pi. While some of the more recent machines have more power on them, I want to be able to use lower cost Raspberry Pi machines for the display. If I must also run scripts to pull information to generate information for the display, it means I need a heftier machine. While this may change later, I believe that starting with the lower machine requirements is the right thing to do.

Installing the Right Tools¶

To make sure that I had the right browser and other utilities I needed, I ran the following command:

sudo apt-get install chromium-browser x11-xserver-utils unclutter

A lot of Raspbian installations will come with chromium-browser package already installed, but I included it just to make sure it is there. The x11-xserver-utils package has one or two small utilities that will make the display look cleaner. The unclutter package allows me to hide the mouse cursor after inactivity, perfect for a display where I know there will be no mouse attached.

Creating a Local Startup file¶

By default, Raspbian comes with a heavily modified version of the LXDE or “Lightweight X-11 Desktop Environment”. According to the documentation, the startup configuration file for the a given user needs to be located at the path /home/$user/.config/lxsession/LXDE-pi/autostart. If it is not there, it will default to the generic file located at the path /etc/xdg/lxsession/LXDE-pi/autostart. As this setup uses the default pi user, the startup configuration file needs to reside at /home/pi/.config/lxsession/LXDE-pi/autostart

Following the advice of various articles, I elected to create a copy of the autostart file under the local /home/pi/ directory. That way, if something bad happens, I can always restart the configuration by copying the default file into the /home/pi/ directory again. To accomplish this, I executed the following commands:

mkdir -p /home/pi/.config/lxsession/LXDE-pi/
cp /etc/xdg/lxsession/LXDE-pi/autostart /home/pi/.config/lxsession/LXDE-pi/autostart

To place the file in the proper directory, I performed a mkdir command as the LXDE-pi directory did not exist with the clean Raspbian installation I was using. Once I had the directory created, I used the cp command to copy the default version of the autostart file into that directory. At that time, the file looked like this:

@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
@xscreensaver -no-splash
@point-rpi

Starting Chromium In Kiosk Mode¶

Now that the local startup file was present, I edited the file with the command nano /home/pi/.config/lxsession/LXDE-pi/autostart in order to add my own startup commands. To be honest, I tried a number of different startup commands recommended by different articles, and each one had good points and bad points. After much experimentation, I ended up with a simple set of startup commands which was as follows:

@unclutter
@xset s off
@xset s noblank
@xset -dpms

@chromium-browser --incognito --start-maximized --disable-notifications --disable-extensions --disable-hang-monitor --disable-infobars --kiosk https://bingwallpaper.anerg.com/

As mentioned above, the unclutter tool makes the mouse disappear when not used, which is perfect for a display that is never going to have a mouse. The xset tools allows for the setting of various XWindows related settings. Specifically, the s setting is for the screen saver and the -dpms setting is for the monitor’s Energy Start features. Finally, the Chromium browser is the browser I chose to start with for displaying the webpages as it has the most documentation on command line switches.

In order, the changes I made to the configuration file:

• hide the mouse
• turn the screen saver off
• don’t blank the screen
• turn off any Energy Star power save monitor features
• start the browser (window maximized, incognito, in kiosk mode) pointing at the Bing wallpaper page

After I finished editing the file, I made sure to save the file (ctrl-X, yes, enter), and then double checked all of my changes. When I confident I had all of them entered correctly, I proceeded to the next step.

Verifying things are Working Properly¶

I issued a sudo reboot to reboot the Raspberry Pi.

And waited.

And waited.

And waited.

If the repetition doesn’t make it clear, it felt like forever. I was sure I had followed my own instructions properly. Even going off of my own notes, there was the anticipation of seeing whether or not it would work. The Raspberry Pi I was using seemed slower than usual, but after a while, everything started up and it was displaying the website https://bingwallpaper.anerg.com/ in the browser.

As I checked the display, I saw the mouse pointer disappear after a few minutes. Check.

After a couple of hours, the screen saver had not kicked in. Check.

After a couple of hours, the monitor was still displaying the website. Check.

For the most part, due to some good notes that I kept, everything was up and running the way it was supposed to.

But What if it Is Not?¶

Let’s be honest. The first 5-10 times that I performed this setup, I didn’t get it right and it was only my notetaking that helped me figure out which things worked and which didn’t. It took a lot of notetaking and a lot of debugging and looking at log files to figure out what was working.

The first log file that I used to debug things was the /home/pi/.xsession-errors file. After executing the cat /home/pi/.xsession-errors command, I noticed that while it didn’t have a lot of useful information, it had two important pieces of information:

** Message: 17:00:13.893: main.vala:101: Session is LXDE-pi
** Message: 17:00:13.894: main.vala:102: DE is LXDE
** Message: 17:00:16.375: main.vala:133: log directory: /home/pi/.cache/lxsession/LXDE-pi
** Message: 17:00:16.376: main.vala:134: log path: /home/pi/.cache/lxsession/LXDE-pi/run.log

This information let me know I was putting the changes in the right place, and where to look for the log for the current user’s session: /home/pi/.cache/lxsession/LXDE-pi/run.log. Also, the fact that it was putting the logs in the /home/pi/.cache/lxsession/LXDE-pi directory meant that it noticed the autostart file that I added, as was using it. That was a useful piece of verification.

When I started looking at that file, I was at first overwhelmed before I found a couple of tricks to help me out. The first trick was to look for a file that looks like this:

** Message: 17:00:16.917: autostart.vala:42: Autostart path : /home/pi/.config/lxsession/LXDE-pi/autostart

Everything before that point are just the other parts of LXDE getting set up, and it really didn’t have any effect on what I was trying to do. After that line were a series of lines that began with Launching, corresponding with each line of the autostart file. The next section of lines complemented those lines, providing for the exit codes of each of the lines in that file. Finally, there is a section starting with Connecting ... that signifies the section of the log where the wired and wireless link status is logged. While the link status is important, the fact that it gets to this point successfully generally means that the display is ready to go!

What Was Accomplished¶

This article detailed the work that was needed to take my Raspberry Pi from a sufficiently set up machine to fulfilling 2 out of the 3 requirements of my a glanceable display. At this point, I have setup a Raspberry Pi that is remotely administered from a machine other than the Raspberry Pi itself, one of our requirements. Another of the requirements is to have the machine start displaying a web browser automatically, without any requirement for a keyboard or mouse to be attached to the machine, which has also been accomplished. Along the way of documenting that setup, I also provided some useful tools to clean up the display and some places to look for debug logs for the setup process.

Specifically, this article took the big step forward from a Raspberry Pi that was remotely administered, to a Raspberry Pi that automatically launches a web browser pointing to a specific webpage on reboot. The next step is to provide that web browser with some content that is not generated on the Raspberry Pi itself.

What’s Next?¶

In the final article in this series, Glanceable Displays: What Do I Want To Display? I walk through the steps I took to determine where to get finalized webpages to display in my glanceable display, while adhering to the final implementation requirement of my glanceable display.

Like this post? Share on: Twitter ❄ Facebook ❄ Email