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.
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.
When I was testing out the installation instructions, one of the things that made me include instructions on setting up a time server is the
apt-get command. In certain cases, if your Raspberry Pi’s clock is too far in the past, you will not be able to access the right packages with
apt-get. Please make sure your Raspberry Pi’s clock is current before using the
Creating a Local Startup file¶
By default, Raspbian comes with a heavily modified version of the
LXDE or “Lightweight X-11 Desktop Environment”.
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
As this setup uses the default
pi user, the startup configuration file needs to reside at
Following the advice of various articles, I elected to create a copy of the
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
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
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
-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.
When I say the most documentation on command line switches, look at the link. The list is way too large to confidently comprehend. As such, I had to take guesses as to which of the –disable switches I needed.
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.
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
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:
the fact that it was putting the logs in the
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
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.
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.
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.