Turning an Old Laptop into a Video Kiosk

My father-in-law came to me with an interesting idea. He wanted to create video kiosk for our church which would play videos on different mission organizations we’re involved with. The wall – previously – had photos and text about each missionary or organization, but he wanted to revamp.

We initially tried to use PowerPoint and a custom keyboard to jump to different slides, but maintaining and updating that system wasn’t going to be very elegant or user friendly. So, about a year later, I had an “oh, duh” moment and realized we could do it as a static, locally-hosted website. It would be easy to build and even easier to maintain, so that’s what we did.

In this post, I’ll talk about the hardware and software we used to get it finished. There are still some things to hammer out, but the bones of the project are done and tested successfully, so it seems like a good time to document it.

The Hardware

Our initial idea was to use a Raspberry Pi 3 to do everything because of it’s low price point and small size. Unfortunately, the RPi, in general, doesn’t handle web video too well. I looked into using the [kweb](https://www.raspberrypi.org/forums/viewtopic.php?t=40860) minimal web browser, which hooks into the native OMX Video Player on the Pi, but you can’t customize the look and playing full screen video had lots of menus. In the end, it was turning into a huge job to make it look polished, so we moved away from the Pi.

My brother-in-law had an old HP laptop that had died when he tried to update it to Windows 8 (insert snarky Microsoft joke here). So, he donated it to the cause.

I wiped the hard drive and installed Ubuntu Linux 16.04 LTS. It’s pretty lightweight and gets consistent updates. It’s also really user-friendly in case there is a problem with the laptop, so one of the office assistants can troubleshoot if I can’t make it. I also chose to stick with Linux because I can use SSH to log in via my Chromebook on Sunday mornings and run updates remotely if I need to.


[flickr photo](https://flickr.com/photos/bennettscience/29893031255 “High security”) shared by [bennettscience](https://flickr.com/people/bennettscience) under a [Creative Commons ( BY ) license](https://creativecommons.org/licenses/by/2.0/)

You could definitely argue that running a full desktop environment for a simple web kiosk slows the machine and introduces a bunch of variables that could cause things to go wrong, which is 100% accurate. [OMG! Ubuntu! has a good article](http://www.omgubuntu.co.uk/2014/07/create-ubuntu-kiosk) on how to either convert a full machine to a dedicated kiosk **or** how to build one from scratch, but since I didn’t find the article until we were almost done, I decided not to go back and rework everything.

For user interaction, we grabbed an [Intuos Art Small tablet](https://us-store.wacom.com/Catalog/Pen-Tablets/Intuos/Intuos-Art-Small-S01#undefined2) from Wacom for $100. It’s seated in a wall mount to lock it in place and hide the wires. Essentially, it’s a giant touchpad.


[flickr photo](https://flickr.com/photos/bennettscience/29599235790 “Human/computer interface”) shared by [bennettscience](https://flickr.com/people/bennettscience) under a [Creative Commons ( BY ) license](https://creativecommons.org/licenses/by/2.0/)

Finally, we bought a 55″ wall mounted TV. The laptop had an HDMI port, so that took care of high-definition video and audio.

The Software

I built the page with plain HTML and JavaScript. It’s currently being hosted locally on the machine to ensure smooth video with no buffering. I’m planning on testing the broadband rates via ethernet next time in church because over wifi we ran into issues. If I can get a good download rate, I’ll switch the site over to GitHub Pages so I can update remotely.


The HTML and CSS is pretty standard. I didn’t want a ton of bloat, so I coded everything from scratch. You can take a [look at the markup on GitHub](https://github.com/bennettscience/church). There’s also a [live example](http://dev.ohheybrian.com/church) so you can see how it’s rendered.

First, this is a hallway display. There will probably be times where people aren’t watching videos, in which case I want to avoid burning an image into the screen of the TV. I added a small jQuery function to bring up a prompt if no one touches the trackpad for 30 seconds. This also turned out to be handy because a lot of people walked up to the tv and tried touching it directly rather than using the trackpad input.

To play the videos, I wanted each container to reference a hidden video `div`. I use jQuery to handle the element selection and JavaScript to pay attention to the play state. When a user clicks the tile, a fullscreen video starts playing. There is no keyboard for them to quit out of the video, so I don’t worry about `keypress` events. If they jump out of fullscreen using the playback controls, it saves the video location.

Ubuntu tweaks

There were also some software tweaks I needed to make on the machine itself.

I wanted a standard user to log in automatically. So, I created a generic user on the system and dropped the source files onto the desktop (more on that in a minute). Theoretically, the user will never get out of Chrome because there’s no keyboard available. When the computer boots, it logs into the generic user right away.

Then, I edited the Startup Applications option. You can launch Chrome from the Terminal and you can specify which command to use in the settings. Using:

`chromium-browser –kiosk [URL]`

launches Chrome in the full screen kiosk mode and displays the website immediately after login.

The laptop is mounted on the wall behind the TV. Ubuntu wasn’t recognizing the monitor when the lid was closed. There is a flag in `etc/systemd/logind.conf` that handles a dock, but we weren’t using one. So, I had to change the `HandleLidSwitch` flag to `ignore` to ignore the lid being closed ([thanks to this answer](http://askubuntu.com/questions/15520/how-can-i-tell-ubuntu-to-do-nothing-when-i-close-my-laptop-lid))

Finally, because the laptop is mounted behind the TV on tracks with a padlock, it’s a pain to take it out to turn it on and off. I was able to automate the daily shutdown pretty easily by specifying a time using `crontab -e` (you have to be root to shut down). Startup was harder.

After some research, I found that most computers have something called a Real Time Clock (RTC) synced with UTC. It can be used to set an alarm to wake the computer. You can test this by setting the clock to zero with:

sudo echo 0 > /sys/class/rtc/rtc0/wakealarm

and then resetting it with:

sudo echo `date '+%s' -d '+ 10 minutes'` > /sys/class/rtc/rtc0/wakealarm

Now that I knew the computer would turn itself back on, I could create a simple `bash` script to run with `cron` that would handle startup and shutdown daily:

I stored the file in `/usr/bin` and made it executable with `chmod +x`.

Then, I edited `crontab -e` to run the script daily. **Note that this specifies the shutdown time.** At 8 PM every day, the computer will shut down. The `shutwake` script resets the RTC alarm:

0 8 * * * * /usr/bin/shutwake

`cron` can be picky, so if you need more help, [this article helped a lot](http://www.nncron.ru/help/EN/working/cron-format.htm).

The last thing we needed to work out was muting the audio during sermons so someone didn’t crank out a video in the middle of church. The video will still play with captions (accessibility FTW) and muting the audio turned out to be not too bad. I can toggle the pulse audio driver in Ubuntu with a simple cron job that runs on Sundays at 9:00 and 12:00 to turn the audio on and off:

0 9 * * * 0 amixer -q -D pulse sset Master toggle


[flickr photo](https://flickr.com/photos/bennettscience/29548284500 “The new mission video display in action at church. Blog post on construction and code coming.”) shared by [bennettscience](https://flickr.com/people/bennettscience) under a [Creative Commons ( BY ) license](https://creativecommons.org/licenses/by/2.0/)

In the end, I’m really happy with how it turned out. Remote management and simple setup led to a really effective display for the wall.

If you want more specifics about software or construction, leave a comment.

Defining the Problem

Consider the train problem:

A train is barreling down the tracks. At a fork, you have the option of flipping the train to the left branch or the right branch. On the left side is someone you know, tied to the rails. On the right, there are five strangers.

Which way do you throw the switch?

A philosophy professor posed the question to his two-year old.

The great thing about this is that he was still solving a problem…it just wasn’t the expected problem.

I think a lot of frustration can come up in a classroom comes from ambiguity. I may have a problem and anticipated solution, but if that isn’t clear to students, conflict can pop up when they take a different path. Even more, defining specific solutions to problems worth discussion is a poor teaching method.

Next time you’re given an unexpected solution, consider the validity of a different point of view.