How we got hardware acceleration of graphics to work in Ubuntu 18.04.2 with an Intel Core i7-9700K Coffee Lake processor

Intel Core I7.pngWe recently set up a new system using an Intel Core i7-9700K Coffee Lake processor, and discovered that the Intel® UHD Graphics 630 is not yet supported in Ubuntu, at least not in the 18.04 Long Term Support release. Therefore hardware acceleration of video did not work in Kodi or any other program. We first realized this when none of the VAAPI settings were shown in Kodi’s settings (they are normally found in Settings Player Settings Videos Processing).  Then we installed the vainfo program (using sudo apt install vainfo), and when we ran it we got this output:

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Obviously this is not what you want to see, so we knew we had a problem.  Much additional research led us to the conclusion that the Intel Core i7-9700K processor is so new that it’s not yet supported in Ubuntu 18.04.

After searching many pages and sites, the answer appeared in a post by user yasij in the Kodi forum, although it seems he thought you’d need to start with Ubuntu 18.10 or 19.04 (the latter should have support for this processor built in, but it’s not a Long Term Support release).

What we found was that support for this processor could be added to Ubuntu 18.04.2 – note the point version here, you need at least the 4.18 Linux kernel in that version for this to work. Check your kernel version using uname -a if you aren’t sure.

The method is rather simple, actually. First you run this command to add the necessary repository:

sudo add-apt-repository ppa:mamarley/updates

Then you need to edit the file etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list

nano etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list
(Or use your preferred text editor).

Look for the line:
deb http://ppa.launchpad.net/mamarley/updates/ubuntu bionic main

and change bionic to cosmic:

deb http://ppa.launchpad.net/mamarley/updates/ubuntu cosmic main

Exit nano (Ctrl-X) and save your changes. Then run:
sudo apt update
sudo apt install i965-va-driver va-driver-all
sudo apt install libasound2 libasound2-plugins

The last two packages were needed to get sound to work in Kodi. We use ALSA audio, so if you use PulseAudio you may not need those, or you may need to upgrade different packages. Additional dependencies may be installed when you install or upgrade these packages.

Then either delete etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list or comment out that repository (add # to the start of the line, like this):
# deb http://ppa.launchpad.net/mamarley/updates/ubuntu cosmic main

Then run:
sudo apt update
again so that no additional packages from that repository are inadvertently added.

Reboot the system.

Now when you run vainfo the output should look something like this (with no errors):

libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSlice
      VAProfileVP9Profile2            :	VAEntrypointVLD

Note that if you run vainfo in a ssh session, you will probably see one error message right at the beginning of the output:

error: can't connect to X server!

This is to be expected in a ssh session, but that error should not appear if you run vainfo from a terminal window on the desktop.

That should be all you need to do — at least it was all we needed to do to get support for this processor into Ubuntu 18.04.2. We hope it works for you, too!  Note that you are mixing packages intended for different versions of Ubuntu, so there’s always a chance that doing this might cause some unintended breakage somewhere, but so far we haven’t encountered any problems.

Extending the remote control capabilities of LIRC

If you have installed the LIRC package on your computer so that it can receive signals from an infrared remote control (as we showed how to do in Ubuntu 18.04 in our previous article, Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi), you may have thought that you could only utilize it inside programs that have remote control support built-in, such as Kodi.  But did you know that you can also use your remote to execute any command that can be executed from a Linux command prompt, or even run a shell script to execute multiple commands?

In order to do that you need to do at least two things.  First, you need to run the irexec program (which is installed as part of the LIRC package), and second, you need to create a .lircrc file in your user directory.  In addition, you may wish to create shell scripts to do whatever you want.

An example may make things easier to understand.  Let’s take the case of starting or restarting Kodi from the desktop.  Let’s say you have just started up your system and it is sitting at the desktop waiting for you to start a program, and you want to start Kodi.  Sure, you could use your mouse to select Kodi and start it, but it’s more convenient to just be able to push a button on the remote to do it.  Or maybe you have been using Kodi and it has simply frozen up on you – wouldn’t it be nice to be able to push a button, kill the frozen instance of Kodi, and then restart Kodi?

Windows Media Center Edition compatible remote controlMost Windows Media Center Edition compatible remotes have four colored buttons, colored red, green, yellow, and blue, that don’t do anything inside Kodi by default. But, LIRC still recognizes them, and they are perfect for use in such an application.

The first thing you would need is a script to start Kodi.  Here’s a bash script that we use with Kodi 17.  Note that in Kodi 18 (at least in beta versions) some changes will need to be made, and these are noted in comment lines. Also note the comment about changing the value of yourusername in the “export USER=” line:

#!/bin/bash
# For Kodi V18 change AE_SINK=ALSA to KODI_AE_SINK=ALSA and
# all instances of kodi.bin to kodi-x11

# In the line below replace yourusername with your actual
# user name in Ubuntu (this will probably be the same as
# the name of your user directory)
export USER=yourusername

# Now try to kill existing Kodi if it is running
if ps -ef|grep -v grep|grep -i kodi.bin
then
ps aux|grep -i $USER|grep -v grep|grep -i kodi.bin|awk '{print $2}'|xargs kill
sleep 3
fi

# If it's still running, force kill it using kill -9
if ps -ef|grep -v grep|grep -i kodi.bin
then
ps aux|grep -i $USER|grep -v grep|grep -i kodi.bin|awk '{print $2}'|xargs kill -9
sleep 3
fi

# If it's STILL running it won't die, so exit
if ps -ef|grep -v grep|grep -i kodi.bin
then
exit
fi

# Delete old Kodi crashlogs (optional)
/bin/rm -f ~/kodi_crashlog-????????_??????.log

# Start Kodi using ALSA sound system
AE_SINK=ALSA nice -20 kodi --standalone &
exit

We saved this script as startkodi.sh and made it executable:

chmod +x startkodi.sh

Please note that we start Kodi with some specific options that you may or may not wish to use. To break them down:

AE_SINK=ALSA (this will change to KODI_AE_SINK=ALSA in Kodi 18): This usually forces Kodi to use the ALSA sound system rather than PulseAudio, which can give better performance if you are using passthrough audio in a multichannel system (5.1 or 7.1 audio). We say usually because on at least one system it was necessary to take more aggressive steps to kill PulseAudio before this would work (see the section headed “Disabling daemon autospawn” on this wiki page if you have this problem). You will know if it is working because you’ll need to reset your audio output under System Settings | System | Audio to use the ALSA output (and the PulseAudio options will disappear). If you are not using passthrough audio (using the “Allow passthrough” setting, and selecting a Passthrough audio device), then there is probably no reason to use this.

nice -20: This gives Kodi more CPU time than other processes that may be running at the same time, and therefore helps avoid jerkiness and dropped frames during playback.

kodi - -standalone: The recommended way to run Kodi from a shell script. (Please note there is a hidden character between the two – (hyphen) characters in this line, to force WordPress to display it correctly, so if you copy and paste this it won’t work if you don’t remove that hidden character.  Unfortunately, this is the case anyplace you see two adjacent hyphens in this article, except when they are within a code block.)

&: The ampersand at the end allows the script to exit immediately, without shutting down Kodi. It effectively makes Kodi a background task.

So that is the script we use to start Kodi, and of course we could run that from a terminal window (which you may want to do in order to check for errors), but that would not be very convenient. So, we use the .lircrc file (in the user’s home directory) to start the script when a button is pressed. We’ll use the green button in this example. Start by editing the file .lircrc (if it doesn’t already exist, this should create it):

nano ~/.lircrc

And just paste in these lines:

begin
 prog = irexec
 button = KEY_GREEN
 config = ~/startkodi.sh &
 repeat = 0
end

Then you can use Ctrl-X to exit nano (be sure to save the file).

The only other thing you need to do is make sure that the irexec program runs at startup. To do that, from the Ubuntu desktop bring up Startup Applications, and when it comes up click the Add button and enter these values:

Name: irexec
Command: irexec -d
Comment: Whatever you want, we used “Infrared Remote Control”

Add irexec to startup programs
Click the Add button to save it.

Then REBOOT THE SYSTEM.

Once the system has rebooted, you should be able to press the green button and it should run the startkodi.sh script and start Kodi. If it doesn’t, it’s probably because your remote is using different labels for the buttons, and we’ll cover how to determine that in a moment.  In case you are wondering, the -d option used with irexec is what makes it run as a background task.

Now maybe you’d like to be able to push the red button to stop Kodi in case it is hung, but without restarting it.  All you need to do is copy the startkodi.sh script to another script (call it stopkodi.sh), then edit that script to remove the line that starts Kodi, and then edit the .lircrc configuration to add another section:

begin
 prog = irexec
 button = KEY_RED
 config = ~/stopkodi.sh &
 repeat = 0
end

We can also run system commands directly from the .lircrc file. Let’s say we wanted to use the blue button to reboot the system, in case things really get messed up. We could add this to .lircrc:

begin
 prog = irexec
 button = KEY_BLUE
 config = sudo reboot
 repeat = 0
end

You would think this would work, but it won’t because when it tries to run sudo it will prompt for your password, and the script can’t deal with that. In order to avoid that, you’ll need to edit the /etc/sudoers file:

sudo nano /etc/sudoers

Move the cursor to the end of the file and on a new line add this:

yourusername ALL = NOPASSWD: /sbin/reboot

Replace yourusername with your your actual user name in Ubuntu. Use Ctrl-X to exit nano, and save the file. This allows running “sudo reboot” without needing to enter a password.

Remember that you will need to REBOOT THE SYSTEM before any changes take effect!

Now, if you are lucky these .lircrc configurations will work as shown. But if you have a different type of remote, you may need to use different buttons, or maybe the buttons aren’t returning the values that .lircrc is expecting to see. To determine that, from a Linux command prompt run this:

irw

Then while watching the terminal window or ssh session, press the buttons you are trying to use on the remote. As an example, here is what we see when we press the green button:

$ irw
000000037ff07ba3 00 KEY_GREEN mceusb
000000037ff07ba3 01 KEY_GREEN mceusb

Press Ctrl-C to exit irw. The thing you are looking for here is the button name, in this case it is KEY_GREEN as shown in the .lircrc section that starts Kodi above, but if your remote returns something other than that, that’s what you’ll need to use in the .lircrc file.  By the way, it is not unusual for a remote to send a button press two or three times in a row, just in case the infrared receiver misses it the first time.  This is not a cause for concern.

When you use irw as shown above, remember that lirc is still running, so don’t press any buttons that would take any action you don’t want to have happen, such as rebooting the system or launching Kodi or something else.

ADDING ADDITIONAL BUTTONS FROM THE SAME OR A DIFFERENT REMOTE

When you use irw, there’s a slight chance you might notice that your remote has one or more buttons that don’t generate any output at all, and maybe you’d like to make them recognized. Or, maybe you’d like to use a second remote (perhaps one that came with a device that you no longer use) to control some additional functions. These things are possible (usually) but the procedure is slightly complicated. One thing to keep in mind is that infrared receivers are only responsive to a certain part of the spectrum of infrared light, and some remotes may generate light pulses outside that range, in which case a particular remote may not work with a particular infrared receiver. But it’s worth a try.

Here’s the basic procedure for getting LIRC to recognize additional buttons:

Open the file /etc/lirc/lircd.conf in a text editor, or just do cat /etc/lirc/lircd.conf from a Linux command prompt, and note the contents – more than likely it will contain an “include” statement such as

include "/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb"

Open THAT file in a text editor and note how it is constructed. You will probably see definitions for one or more remotes, in sections between “begin remote” and “end remote” tags. In each such section you will see a list of codes, in sections between “begin codes” and “end codes”, and in such sections you will see two columns. The first is a list of names that have already been used for existing remote buttons, and that you therefore should not use when adding new buttons.

However, you cannot just go using any button names you like for your new buttons. You can only use the button names that are shown when you run this command from a Linux command prompt:

irrecord - -list-namespace

(Please note there is a hidden character between the two – (hyphen) characters in the above line, to force WordPress to display the line correctly, so if you copy and paste the above it won’t work if you don’t remove that hidden character.)

So to try to make this clear, when naming a new button you can only use names that appear in the list you get when you run irrecord - -list-namespace but you should NOT use names that appear in the /etc/lirc/lircd.conf file, or in any file that is mentioned in an include statement within that file, because you run the risk of specifying the same button name for two different buttons.

You may have to read that a couple of times for it to sink in, but it’s important. You will probably want to find a way to keep both lists visible during the next steps. You could open them in two different Text Editor windows, or two different terminal windows, or two different ssh sessions from another computer – it really doesn’t matter as long as you can refer to both lists, and know which is which.

Now you are ready to try to map new buttons. During this process, lircd cannot be running, so do this:

sudo killall lircd

Next, run this command:

sudo irrecord -d /dev/lirc0 ~/newremote.txt

The character at the end of lirc0 is a zero, not a letter O. You can use any filename you want rather than “newremote.txt”, just make sure it’s a filename you aren’t already using. When using irrecord, don’t try to add buttons from more than one remote in a single run, and if you make a mistake just Ctrl-C out, delete the “newremote.txt” file, and start over. Also, note the above line assumes that /dev/lirc0 is the correct path for LIRC’s connection to your infrared receiver, which is almost always the case.

The irrecord program will walk you through the entire procedure for adding new buttons — just follow the instructions it gives precisely. It will first have you perform some tasks so it can determine basic timing information about your remote.  If irrecord can’t seem to detect your remote, it may be that the remote isn’t compatible with your infrared receiver, or it may be that the batteries are dead in the remote! Don’t give up on a remote without at least trying new batteries.

After the preliminary tasks are completed, irrecord will ask you to enter the name of a button. This is when you will refer to the two lists — remember, you want to use a name that DOES appear in the irrecord - -list-namespace list, but that does NOT currently appear in /etc/lirc/lircd.conf or in any file referenced by an include statement therein (such as /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb in our example above).  Just to be clear, there is no requirement that the names you use in this procedure be in any way related to the names of the buttons on the remote, since you will be defining what the button press actually does in the .lircrc file.  It may be convenient to use a related name (if it’s not already used in another remote’s codes list) to help you remember which button is associated with which name, but if you can’t find an unused name that comes close to the name of the button on your remote,  it’s perfectly okay to pick any unused name from the irrecord - -list-namespace list and use that, though in that case you may want to make notes about which names are associated with which buttons.

After you enter the name, it will ask you to hold down the button on the remote. After a few moments it should ask you to enter the name for your next button – that is your confirmation that the button was accepted by your infrared receiver. You can keep on adding new buttons from the same remote, or exit by pressing only the Enter key when asked for the name of the next button.

Once you have exited irrecord, you must open the file it created (~/newremote.txt, or whatever name you used) in a text editor, and change the value on the name line (right below the line that reads “begin remote”) to something that is all lowercase letters with NO SPACES – underscore characters are okay, though.  So, something like

 name new_remote

would be fine.  The name must not duplicate the name in any of your existing remote definitions.  Also, we always remove all the commented-out lines produced by irrecord (lines that begin with a # character), since they are not needed.

After you have made those changes, copy the section starting with “begin remote” and ending with “end remote” to the clipboard, and then open the file containing your other remote definitions and carefully paste your new remote definitions to the end of that file (leave at least one blank line after the existing contents of the file before pasting).  By “the file containing your other remote definitions” we mean either /etc/lirc/lircd.conf or the file that is mentioned in an include statement within /etc/lirc/lircd.conf, such as /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb in our above example (we used the latter).  The basic idea is you want to put your new remote definitions and codes at the end of the same file that contains all the other remote definitions and codes. BE CAREFUL when doing this because if you somehow screw up this file, your remote may not work at all!  It probably isn’t the worst idea to make a backup of the file prior to making any changes.

If you don’t want to mess with your existing remote definitions file, you could probably add a new include line within /etc/lirc/lircd.conf and point that to a new file that you have created that contains your new remote definitions.  That is supposed to work, according to the LIRC documentation, but we haven’t actually tested doing it that way (please note that the LIRC documentation link takes you to the documentation for the latest version of LIRC, and therefore some parts may not be applicable if you are using an older LIRC version).

Note that if you were trying to add buttons from your main remote that LIRC has not previously recognized for some reason, you will probably want to add just those new codes directly to the existing codes list for that remote, rather than copying the entire new block of remote definitions.

You will probably want to save a backup of your new remote definitions someplace, so you don’t have to go through this process again the next time you upgrade the system!  This comment comes from experience — during our most recent Ubuntu upgrade, we backed up the entire home directory and some specific configurations from the /etc directory, but we totally forgot about the remote definitions that we had put into the /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb file, so we had to do redo this process.

Once you have added your new remote definitions and codes to the file containing your existing remote definitions and codes and saved it, you should REBOOT THE SYSTEM so that lircd will restart and read in the new codes.  After the system is rebooted, you can once again run irw and now when you press one of the buttons you added, it should show the name that you assigned to the button.  And if that works, you can then use that button name in the .lircrc file to launch shell scripts or system commands, or do just about anything you could do from a Linux command prompt.

Addendum:  Mind the Gap!  No, we haven’t been riding the London underground, but we have discovered that on some systems, but not others for some weird reason, if you add remote definitions that contain a “gap” value in the headers — which almost all added definitions will — it may cause LIRC to stop working altogether if for whatever reason irexec doesn’t like the gap value.  So if you have a gap value that is a bit on the high side (near or above 100000) you may need to reduce the gap value to get things working again.  For example in one case the gap value should have been 108382, but we wound up having to reduce it to 80000 on just one system for it to work, even though the higher value works fine on several other systems, and even though some of the other remote definitions had higher gap values.  The real issue is that if you get bitten by this, your remote won’t work at all until you change the gap value to something that irexec approves of — it will just silently fail to recognize your remote! This may even be a problem when you are copying remote definitions from one system to another — the gap value that works just fine on one system will cause the failure of your remote control to work at all on a different system.

Convert an older model USB printer to a networked printer using a Raspberry Pi or other Linux-based computer — also works well for making an older printer compatible with a newer version of MacOS

We originally set out to do this because we were having problems getting an older model laser printer, specifically a Konica Minolta PP1350W, to work with MacOS High Sierra (10.13).  With previous versions of MacOS we’d been able to connect the printer directly to the computer, and with some fiddling with drivers and other software, get it to work.  But newer versions of MacOS seem to be far less tolerant of this, and we had a spare Raspberry Pi, so the idea came to us to use the Raspberry Pi as a bridge between the printer and any computers on the local network from which we wanted to be able to print.  The bonus is that the printer is no longer tethered to a single machine, but instead can potentially be used by any computer on the local network.

You do not need to have a Raspberry Pi to make this work – any computer that can run Linux will do.  And of course the Raspberry Pi or other Linux computer can be used for other purposes besides this.  We do not guarantee that this technique will work for every older printer out there, but this will work with a surprising number of them.

If you use a Raspberry Pi, it should already have some version of Raspbian installed, but it can be either Raspbian Lite or the full version of Raspbian.  If you use a different type of computer, be aware that our instructions are geared toward users of Debian, Raspbian, Ubuntu, Linux Mint, or similar Debian-based distributions, though we imagine that with a little modification they could be adapted to other Linux distributions.

Because the Raspberry Pi is so (relatively) inexpensive, from here on we will just refer to the Raspberry Pi, but if you are using a different computer running Linux that term applies to your computer as well.

Assuming your operating system is already installed, we also suggest that if you have not done so, you give your Raspberry Pi a static IP address on your network.  This can be done in your router settings, by reserving a specific IP address for your Raspberry Pi’s MAC address, or by changing the networking settings on the Raspberry Pi itself.  If you don’t do this, other computers on your network may not be able to find your Raspberry Pi when you want to print something, if its IP address has changed.

With that out of the way, here is how you make this work.  Commands shown below are entered in the terminal program, or in a ssh session (in other words you must be at a Linux command prompt):

1. Install CUPS:

sudo apt upgrade
sudo apt install cups

This will install CUPS (the Common Unix Printing System) and several dependencies.  Okay, a LOT of dependencies.  Just let them all install.

2. Look to see if there is a specific driver for your printer:

apt-cache search printer-driver

This will return a list of available printer drivers.  Look though the list and see if any of them look like ones that might be used with your printer.  For example, we found this:

printer-driver-min12xxw - printer driver for KonicaMinolta PagePro 1[234]xxW

Since this definitely covers our model PP1350W printer, we installed it using:

sudo apt install printer-driver-min12xxw

Of course you would substitute the driver for your printer, if one is available.  Alternately, some printer manufacturers may offer a Linux printer driver on their web sites, but you may need to compile it yourself, or they may provide a script that will compile it for you.  In any case, it is almost always better to install the printer driver for your printer, because then CUPS can find and use it.  Otherwise it may try to use a more generic printer driver that doesn’t work as well (or at all).

If all else fails, try putting “Linux printer driver for (your make and model of printer)” into a search engine and see if anything relevant is returned.  But beware of installing pre-compiled printer drivers on a Raspberry Pi – you would need a version built for an ARM-based device, not one built for a standard Intel/AMD CPU architecture.

3. Add your user to the lpadmin group:

sudo usermod -a -G lpadmin username

Replace username with your user name.  For example, on a Raspberry Pi, you would probably use sudo usermod -a -G lpadmin pi unless you have created another user.  The “-a -G” options add the user to the supplementary group, in this case the lpadmin group.

4. (Optional) At this point you could edit the CUPS configuration in a web browser on your Raspberry Pi, if you are running a desktop version of Raspbian.  But if you want to be able to modify the CUPS configuration from another computer on your network, you need edit the /etc/cups/cupsd.conf file to allow it:

sudo nano /etc/cups/cupsd.conf

Feel free to use any text editor of your choosing if you don’t care for nano.  Here are the sections that need to be modified – the modifications are shown in red:

# Only listen for connections from the local machine.
# Listen localhost:631
Port 631
Listen /var/run/cups/cups.sock

Please note that the line “Listen localhost:631” has been commented out. Then, a bit further down in the file:

# Restrict access to the server...
<Location />
Order allow,deny
Allow @local
</Location>

# Restrict access to the admin pages...
<Location /admin>
Order allow,deny
Allow @local
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
Allow @local
</Location>

5. (Optional unless you have performed step 4, or made any other changes to the cupsd.conf file) Restart the CUPS server:

sudo /etc/init.d/cups restart

6. In a web browser go to one of the following addresses.  If you are using a web browser on the Raspberry Pi itself, go to:

https://localhost:631

If you are using a web browser on any other machine on your local network (and assuming you completed steps 4 and 5), go to:

https://ip address or host name of raspberry pi:631

Note that your browser will probably complain about the site being insecure because you have a self-signed certificate – just go ahead and tell the browser it’s okay to connect to this site.  You actually can connect to the main page using http rather than https, but the moment you try to do any actual configuration it will force you to switch to https, so you may as well start out there.

7. Configure your printer.  If you haven’t already done so, you should power up your printer now. You should be at a page that looks something like this:

CUPS home page
You want to click the Administration link, which is highlighted in yellow above.  On the next page you will see this at the top:

Top of CUPS administration page
On that page you want to click the Add Printer button, which again we have highlighted in yellow. You may be asked to login at this point, if so, use the username and password you’d use to login to your Raspberry Pi. Next, you should see something like this:

CUPS - first add printer screen
Hopefully you will see your printer as shown above — if not, try rebooting the Raspberry Pi while the printer remains powered up.  When you do see it, select it and click the Continue button, and then you should see something like this:

CUPS - second add printer screen
The two things you need to do on the above screen are fill in the location, which can be anything you want, but the most important thing is to check the “Share This Printer” checkbox, which we have highlighted in yellow above. Then click Continue, and you should get a screen like this:

CUPS - third add printer screen
All you have to do in this screen is pick the make of your printer from the list and click Continue.  If you wonder why ours is in ALL CAPS, that’s because we installed printer-driver-min12xxw back up in step 2, and that’s what CUPS is finding here.  You want to use the entry associated with any printer driver you might have installed, which hopefully will be this obvious.  Then you click Continue.  An alternative is to upload a PPD (PostScript Printer Description) file on this page, but we didn’t need to do that.  After you click Continue, you may see another screen such as this:

CUPS - fourth add printer screen
The purpose of the above screen is to allow you to pick a specific model printer.  You should pick the one that corresponds to your printer.  This screen also gives you one more opportunity to provide a PPD file, in case your printer model isn’t listed.  After you have selected your printer, you click the Add Printer button. At that point you will have the opportunity to set your default printer options:

CUPS set default printer options
Most of these options will probably be filled in correctly but one or two might not be – for us, the page size was set to A4 and we had to change it to Letter.  Set them as you wish, but keep in mind that most software with printing capabilities can override the defaults if you instruct the software to do so in a printer setup dialog.  After you have made any changes, click the Set Default Options button.  After you do that, the system may display an intermediate page but then should take you to the Printers page:

CUPS Printers page
This shows that your printer has been set up. You could use it now from the Raspberry Pi itself, but of course the goal it to use it from other computers on your local network. In most cases, this should be very easy – you just go to your system’s printers dialog and add the printer. For example, in MacOS you would go to System Preferences, then Printers & Scanners. Then click the + at the bottom of the printers list, and your printer should appear in a panel like the one shown below, assuming that the Raspberry Pi and the printer are both powered up:

MacOS add printer dialog
Click on the printer to select it, and the fields at the bottom of the panel should populate with the printer information:

MacOS add printer dialog - printer selected
Just click the Add button and now the printer should show up in your printers list, and be available for use:

Mac OS Printers Panel showing added printer
Be sure to select your newly added printer as the Default printer, if that’s what you want.  Note there is a “Share this printer on the network” checkbox, but you should NOT check that because the printer is not being shared from your Mac, it is being shared by the Raspberry Pi.

The procedure for adding the printer would likely be similar on a Windows or Linux machine.  In fact you may not need to do anything; on one Ubuntu system we checked the printer just appeared and was available from printing applications without any additional action on our part.

We hope this will give some added life to some of those USB-connected printers that still are capable of working quite well, but that are no longer directly supported by modern operating systems.

How to install Kodi media player to Ubuntu 18.04 (Bionic Beaver) Desktop

Kodi Startup Logo

We recently wanted to install the Kodi media player software to a system running Ubuntu 18.04 desktop.  Here is the procedure we followed.  Not all of these steps are necessary, and we will tell you which ones are optional.

1. Optional – Install openssh-server and/or vino

If you install openssh-server you will be able to ssh into your system from another computer on your network (which gets you to a Linux command prompt, similar to running the Terminal program), and this will make things easier if you wish to do any of the installation steps from a different system. Similarly, vino allows you to use any VNC client to remotely access the desktop on your system. If you plan to do all the configuration directly on the Ubuntu desktop system then you do not need either of these. To install openssh-server do this:

sudo apt install openssh-server

If you want to install vino there is a two step process, and the second step must be done directly from the system running Ubuntu 18.04 desktop – you cannot do it through a ssh connection. The first step is probably only necessary if you did a minimal install of Ubuntu, but you can try it anyway just to make sure it’s installed:

sudo apt install vino

Then, to make it possible to connect from a remote client (particularly one running on a non-Linux system), open a Terminal window on the Ubuntu system and enter this:

gsettings set org.gnome.Vino require-encryption false

Note that “Vino” is capitalized in the above line – it won’t work if the V is lowercase. After doing this you should be able to set up Screen Sharing from the System Settings menu. If you aren’t familiar with that process, see this tutorial.

2. Optional – Set a static IP address

If this is going to be primarily a media center or home theater computer, you may want to be able to always find it at the same IP address on the network. If that is the case, consider giving it a static IP address. This is done by clicking on the Network icon in the upper right of the desktop and changing the settings associated with the correct network interface. If you are not familiar with this process, see this page but scroll down to the section headed “Ubuntu Desktop” – it’s where you will find the first screenshot on the page.

3. Optional – If you are using wired Ethernet, disable the Wi-Fi interface

While you are in the network settings, it’s a good idea to disable the Wi-Fi interface if you don’t plan on using it. If you try to connect to any type of streaming content, such as YouTube, you will generally have a far more reliable connection if only a wired connection is available.

4. Install Kodi

Now that we have the preliminaries out of the way, it is time to install Kodi. The process is quite simple and can be found at their page, HOW-TO:Install Kodi for Linux but it is so easy we can tell you how to do it here. Just open a terminal window or ssh session and enter the following. The first line is probably not needed, because the “software-properties-common” package appears to be already installed in Ubuntu, but just to be on the safe side you may want to run it anyway:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:team-xbmc/ppa
sudo apt-get update
sudo apt-get install kodi

5. Optional – If you run a backend system such as Tvheadend in order to use the Live TV and PVR features of Kodi, install the appropriate PVR client add-on. Instructions can be found on this page. If you don’t know what a backend system is, you can skip this step for now, but at some point you may want to read up on Tvheadend and how it is used with Kodi.

At this point you should find the icon for Kodi among your applications, and you should be able to launch it and control it with your keyboard. You will want to go through the settings and set it up the way you like. Also, if you installed a PVR add-on, you will need to configure and enable it. And, you may want to install some additional Kodi add-ons, which can be found on this page.

PLEASE NOTE: The add-ons at the above link are free and legal addons from the official Kodi site. We STRONGLY recommend that you DO NOT install add-ons from any other site. If an add-on has not been accepted into the official Kodi repository, there is a good chance it is illegal in many parts of the world, and that it could irreparably damage your Kodi installation or even your system. In the worst case, it may contain a virus or a “trojan horse” program designed to steal your personal information and passwords. There are a few benign Kodi add-ons from third-party sites, mostly ones still in the development stage where the author hopes to get them accepted into the official Kodi repository, but unless you are knowledgeable enough to figure out which add-ons can damage your system and which cannot, we’d recommending avoiding add-ons from third-party sites like the plague. If you have ever read any negative articles about “illegal Kodi boxes”, these are boxes that have been pre-loaded with illegal and often poor quality add-on software, that are usually sold at a highly inflated price and that contain apps that will stop working in a matter of days or weeks, at which point you find out the seller has left town never to be seen again. Kodi itself is a free and legal program, as are the add-ons that are found at the official Kodi site.

6. Optional – Make a Windows MCE compatible remote work correctly in Kodi

If you have a Windows Media Center Edition compatible remote attached to your system and you have its infrared receiver connected, you will probably find that some buttons (such as ENTER or OK) do not work in Kodi. In past versions of Ubuntu the simple solution was to install a program called LIRC, but the version of LIRC in the Ubuntu 18.04 repository is buggy and doesn’t work correctly. The fix for that is found in our previous article, Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi.

7. Optional, for users with Intel graphics only – Create a Xorg configuration for smoother video playback (this section added October 2, 2018):

We’ve been watching a thread on the Kodi forum called “v18 – Is there a guide to perfect playback in Ubuntu 18.04 Deskop using VAAPI graphics?” that you may want to read.  But the gist of it seems to be that starting in Ubuntu 18.04, by default the video driver used is not the best driver for use with Kodi.  As user “yasij” wrote:

…Xorg has been the default in every [Ubuntu] release except 17.10, which has Wayland.

In 16.10, Ubuntu switched to using the modesetting driver with glamor on Intel gen4 graphics and newer instead of xserver-xorg-video-intel.

But Kodi works best with the xserver-xorg-video-intel driver – Team-Kodi Developer “FernetMenta” wrote:

You really should create a xorg.conf that forces intel driver. Otherwise it would use modeset driver that causes stuttering on most hardware.

And in an earlier message he wrote:

Make sure you have TripleBuffer disabled in xorg.conf. This is enabled by default

If you don’t already have a Xorg configuration file, the easiest way to do this seems to be this:

sudo mkdir -p /etc/X11/xorg.conf.d
sudo cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11/xorg.conf.d/10-intel.conf

(Note there are only two lines above; if the second one wraps on your screen it’s still all one line.)

Then edit the 10-intel.conf file – this shows using nano, but feel free to use another text editor if you prefer:

sudo nano /etc/X11/xorg.conf.d/10-intel.conf

Right after the existing line Driver "intel" add this new line:

Option "TripleBuffer" "false"

Check to make sure you have not made any mistakes. At this point it should look something like this (the commented out line may or may not be present):

Section "Device"
        Identifier "Intel"
        Driver "intel"
        Option "TripleBuffer" "false"
#       Option "AccelMethod" "uxa"
EndSection

Press Ctrl-X to exit, and save the file.

It might be a good idea at this point to make sure you can ssh into your system, just in case your hardware is different and this change prevents the desktop from starting up.

Reboot the system, and after it comes back up you should hopefully find that video playback in Kodi is steadier.  If for any reason this change has caused problems, simply remove the new file:

sudo rm /etc/X11/xorg.conf.d/10-intel.conf

And reboot. Note that if your desktop won’t start up, you’ll need to do this in a ssh session or from a command prompt. If the desktop won’t start, it may mean you have incompatible hardware (are you certain you have Intel graphics?).

Also, if you are an AMD user, you may have to perform some additional steps – see at least the second post in this thread. At the very minimum, it appears you may need to use Kodi version 18 (Leia) and do this (again, this is for AMD users only):

AMD users that want to use kodi v18 with vaapi (Take care: v17 won’t work), you need to install mesa 18.0.1 or later. You can do this via Paulo’s ppa:

sudo add-apt-repository ppa:paulo-miguel-dias/pkppa
sudo apt-get update
sudo apt-get dist-upgrade

We are not AMD users, so you are kind of on your own with the instructions in that thread – good luck!

8. Optional – Install Gnome Tweaks

One other thing you may wish to do is install Gnome Tweaks if you have not done so already. Just go to the Ubuntu Software Center and search for “Gnome Tweaks” and install it, and you will have more control over how your desktop looks and operates. For example, if you want to remove the trashcan icon from the desktop, see this article. But a better use might be to turn off animations, which could slow down an underpowered system and which some users find annoying. You can turn off animations in the Gnome Tweaks Appearance tab.

Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi

remote.png

If you are a Kodi user and have recently tried to upgrade your system to Ubuntu 18.04, and then tried to install and use LIRC to make your infrared remote control work the way it should, you may have discovered that it doesn’t work. For one thing, you don’t get the configuration menu during the install process, so you can’t select your make and model of remote. Even the old standby of using sudo dpkg-reconfigure lirc to bring up the configuration menu doesn’t work anymore.

Chances are you searched the web for an answer, but perhaps you never found anything that would make your remote work as smoothly as it used to in past versions of Ubuntu. Even if you got the remote to work in Kodi, you probably got double button presses or a lack of response to button presses on some buttons at random times, and maybe certain buttons would not work at all. We have heard of Kodi users giving up and going back to Ubuntu 16.04 because of this issue!

It turns out that the issue may not be with Ubuntu OR Kodi.  It appears the problem is that the Ubuntu 18.04 repositories contain a newer version of LIRC, that just doesn’t work properly.  We found that going back to an old version, specifically LIRC 0.9.0, is the answer – install that, and you do get a version of LIRC that works in Ubuntu 18.04 and that makes your remote work smooth as silk in Kodi.  Well, at least it did for ours, which is a standard Windows MCE compatible remote similar to the one pictured above.

So how do you do that?  Well, as the title of this blog implies, we are two “sort of” tech guys, and one thing we are not is Linux experts.  So, we took an approach that is relatively easy and that works, even if it may not be the “most correct” way to do it.  Here’s the procedure we used:

First, remove any existing installs of ir-keytable and/or lirc – from Linux command line do:

sudo apt purge ir-keytable lirc

Also, if you have added any other software in an attempt to get the remote to work, you probably should remove that as well.

Next, we’re going to temporarily edit /etc/apt/sources.list – we will use nano, but feel free to use vi or vim if that’s your thing:

sudo nano /etc/apt/sources.list

Add this line at the bottom of the /etc/apt/sources.list file:

deb http://ca.archive.ubuntu.com/ubuntu/ xenial universe

Use Ctrl-X to exit nano; be sure to save the file (unless you made a mistake, then just exit without saving and start over).

Then, from the Linux command line:

sudo apt update
sudo apt install lirc/xenial

You should see it install lirc and a few dependencies.  Somewhere in the process you should see “Setting up lirc (0.9.0-0ubuntu6) …” and also you should get the configuration screen, from which you can pick the type of infrared remote you use (such as “Windows Media Center Transceivers/Remotes (all)”, which is down near the bottom of the list).

lirc configuration screenClick on the image to enlarge

After that is finished, do this so Ubuntu won’t try to upgrade lirc to the newer bad version:

sudo apt-mark hold lirc

Now that lirc is installed, you need to go back and remove the line you just added to /etc/apt/sources.list:

sudo nano /etc/apt/sources.list

Scroll down to the bottom of the file and put the cursor at the start of this line and press Ctrl-K to delete it:

deb http://ca.archive.ubuntu.com/ubuntu/ xenial universe

As before use Ctrl-X to exit nano, and be sure to save the file.

Now from the command line you should immediately do this so that your system doesn’t inadvertently try to get any other packages from the xenial universe repository:

sudo apt update

And that’s it!  What we have done here is to temporarily enable the Ubuntu 16.04 (xenial) universe repository, where a copy of lirc 0.9.0 is available, and then we installed it using the apt command.

We do realize that there may be alternative way to do this, such as downloading the lirc package from the xenial repository (the amd64 version is here) and then installing it using dpkg, but we’d be a little concerned that doing it that way either might not bring in the necessary dependencies, or might not show the configuration menu.  But, feel free to try doing it that way if you’re much more conversant with Linux than we are.

We hope this helps others who have struggled to get their infrared remote working with Kodi in Ubuntu 18.04!

If you liked this article, you may also want to read our followup article: Extending the remote control capabilities of LIRC.