Friday Fun: Linux on an old point-of-sale

On the bench today: a mysterious black point-of-sale system recently retired from use at a Parks facility. This victim of the end-of-XP upgrades landed on my desk since it wouldn’t run Windows 7, to see if it could be made useful with Linux.

The hardware

This unit is an all-in-one point-of-sale system, with a touchscreen monitor attached via a hinge to a lockable CPU case. I couldn’t find a make on it, but the model number is “Mercury-150”. It appears to have a Pentium 4, 1024 MB of RAM, and a 40 GB HDD. The touch screen is a 15 inch LCD capable of 1024×768. It smells of old overheated circuits and dust, but it’s in good shape. There’s a jack to connect a cash drawer, along with the usual assortment of PC connections (Serial, USB, PS/2, ethernet), but we don’t have anything but the basic unit.

Test drive

Despite finding a “LAN” boot option in the BIOS, I wasn’t able to PXE boot the device; fortunately, it booted to my USB thumb drive just fine. I fired up Xubuntu 14.04 just to check it out. It took a few minutes to get to the desktop, but once there the basic components seemed functional. Apart from the Realtek network card, the system is pretty much Intel top to bottom, with an 855GM graphics chip and ICH4 audio, so naturally things “just worked” without fiddling.

The only thing that didn’t immediately work was the touch screen, which was hardly surprising. None of the user-friendly tools picked it up, and lsusb didn’t find it either, so clearly more investigation was necessary. I tried to fiddle with it some during live mode, but ultimately decided I’d hold off until the OS was actually installed.

Performance, apart from the slow boot, was pretty decent; the system is a little slow on the uptake launching programs, but once things are loaded they mostly run at acceptable speeds. Unfortunately when I tried to install, the live desktop just locked up on me; this is possibly the result of me installing several things to the RAM drive and poking around with drivers while trying to get the touch screen going, so no biggie.

Installing an OS

I opted to install Lubuntu, just to save a few more CPU cycles over Xubuntu. I suppose if I’d really wanted to do this right I’d start up a Debian net install, but… y’know, Friday, right? Lubuntu was slow to boot like Xubuntu was, but the installer launched without trouble and I breezed through it, taking defaults all the way.

So long, XP!

That darned touch screen

Now that Lubuntu was installed, it was time to see about making that touch screen work. Some judicious Googling around the terms “Mercury 150”, “POS”, and “touch screen” turned up the fact that the touch screen on this model is RS-232 (serial port, for you youngsters). Well, that explains why lsusb won’t find it.

Of course this thing’s loaded with serial ports for all the peripherals, so which one is it? I decided to find out using trial and error; one by one, I cat’d each serial port under /dev while touching the screen, like so:

sudo cat /dev/ttyS#

Nothing was happening until I hit /dev/ttyS2, and suddenly each movement of a finger on the screen produced a screen-full of random symbols. BINGO!

Having found the port, I now had to figure out a driver for it. There was no way to query the device over serial, as far as I knew; and there were no markings on the case indicating make or model of the screen. Nothing I could find about the Mercury 150 told me what sort of screen was attached, so it was back to trial-and-error.

The inputattach command, used to set up serial pointing devices, lets you select from available drivers as a command-line switch. There are about a dozen touch-screen drivers included, so I went through trying them all one by one, like so:

sudo inputattach --(drivername) /dev/ttyS2

I tried nearly all of them, with mixed results. Some simply failed, saying the hardware couldn’t be initialized; others caused the cursor to jump around erratically in response to touch. Finally I tried the “elo” driver, and found that the cursor responded almost (but not quite sanely). In fact, it was mirroring my hand movement, so that touching the top of the screen put the cursor on the bottom, and left put the cursor right, etc. It was wrong, but it was consistently wrong, so that made me think that maybe it just needed calibration.

A quick search of the repositories found the xinput-calibrator package, which I installed and ran. It brought up a screen where I had to touch a series of crosses to calibrate the screen.

Seconds later, my touch screen was working perfectly. Yay!

The calibrator spit out a snippet to paste into the Xorg configutation so that the calibration would remain permanent, so I dropped this in /etc/Xorg/xorg.conf.d as it instructed. I also added the inputattach command1 to /etc/rc.local. Once I’d done this, I rebooted to test persistence, and found that everything worked just fine on reboot.


To test out the system, I decided to install tuxpaint and set it to load full-screen on boot. I set the new tuxpaint system in the hallway for a while and everyone had a bit of fun “fingerpainting” on it. The accuracy wasn’t great, maybe some more careful calibration would fix this, but I get the feeling it’s not the most precise touch screen ever made. Screen edges weren’t very responsive, and dragging around the screen skipped pixels now and then.

Overall, though, I think I’ve managed to rescue this system from the garbage, assuming we can find a use for a touchscreen kiosk elsewhere in our organization. In the meantime, KTuberling is begging to be tried…



The final command was “inputattach -elo /dev/ttyS2”.

Leave a Reply

Your email address will not be published.