Applying TK Themes to Git Gui

Stashing this here for my own future information since it took me some time to figure out. How to change how Git Gui / Gitk look using different TK themes and how to install and use an external TK theme (such as one of these: https://wiki.tcl-lang.org/page/List+of+ttk+Themes).

How to Check Installed Themes

In Linux, you probably already have everything you need to adjust the TK theme used by Git Gui without installing anything new. To check what themes are available we can use the TK tool "wish". Running "wish" will popup a window into which you can build widgets, we'll just ignore it for our purposes.

We can check the TK version with "info patchlevel" and then list out the built-in themes with "ttk::style theme names":

$ wish
% info patchlevel
8.6.8
% ttk::style theme names
clam alt default classic
% exit
$

We currently have the built-in themes: clam, alt, default, and classic

How to Switch Themes

We can temporarily switch the theme to see if we like it using this magic:
echo '*TkTheme: [insert theme name here]' | xrdb -merge -
For example:

$ echo '*TkTheme: clam' | xrdb -merge -

And then if we run git gui it will be styled slightly differently than the default:

$ git gui

To make the change stick we need to adjust our user settings. Create or edit the file .Xresources in your home directory:

$ nano ~/.Xresources

And add to that file:

*TkTheme: clam

Now when you reboot (or restart the X server), git gui will use the "clam" theme.

How to Install External TK Theme

I grabbed the awthemes.tcl file from the above-linked list of themes. Awthemes provides the "awdark" and "awlight" themes. But then you have to figure out what to do with it to actually use them.

First, let's stash it somewhere useful:

$ mkdir ~/.local/share/tk-themes
$ mkdir ~/.local/share/tk-themes/awthemes
$ mv ~/Downloads/awthemes.tcl ~/.local/share/tk-themes/awthemes/

And now we create a package index file:

$ nano ~/.local/share/tk-themes/awthemes/pkgIndex.tcl

And put in there:

package ifneeded ttk::theme::awdark 2.3 [list source [file join $dir awthemes.tcl]]

Make sure you match the version number you put into pkgIndex.tcl to the one set in awthemes.tcl.

And, finally, we need to let TCL know where to find our external themes. We do this by setting an environment variable in our profile.

$ nano ~/.profile

Add the following to the end of that file:

# TK Themes
export TCLLIBPATH=$HOME/.local/share/tk-themes

Now logout and log back in (or use "source ~/.profile").

In order to see our theme we have to request it so that TK will go look for it:

$ echo '*TkTheme: awdark' | xrdb -merge -

If we check our installed themes again we'll see the "awdark" and "awlight" themes are now available.

$ wish
% ttk::style theme names
awlight clam alt default awdark classic
% exit
$
If we set the theme in ~/.Xresources it will be found and loaded when the X server starts.
$ nano ~/.Xresources

And change it to:

*TkTheme: awdark

Reboot your machine and when you log back in you should be using the new theme when you run git gui or gitk.

Unfortunately, I have not yet figured out how to adjust the ListBoxes and Text widgets using the
::ttk::theme::awdark::setTextColors and
::ttk::theme::awdark::setListboxColors procs as described in the awthemes documentation.

Mint 19 + Kodi 18 + Intel NUC i3

I'm finally upgrading my OS and it's time for a follow up on my popular post on setting up Kodi on Ubuntu 14.04.  It was invaluable to me in re-figuring out bits and pieces and some things have changed.

Rather than write out what's changed explicitly, I'll write this as a fresh guide and make notes when something is different than it was 4 years ago.

I'm using Linux Mint 19 now, which is based off Ubuntu 18.04.  These instructions will likely work fine for Ubuntu 18.04.  I'm using Kodi 18 (Leia) on an Intel NUC i3 D34010WYK.  As I write this Kodi 18 is on Release Candidate 3 (I was really hoping they'd have the final build out by now, but now is when I have time off).  Not a problem though, switching the PPA is easy (see below).

Update NUC’s UEFI

I grabbed the latest firmware from Intel (version 50) and flashed it onto the NUC.  Glad to see Intel used a sane process.  Just grab the .BIO file and put it on a USB flash drive.  Upon boot, hit F7 and navigate to the BIOS Flash Update Tool.

Install Linux Mint 19.1

I then installed Mint 19.1.  I won't cover that in this post.  Plenty of better places to find that information.  I'm using the 64-bit distribution.

Install Kodi 18

The Kodi Wiki install guide is pretty clear:

$ sudo apt install software-properties-common
$ sudo add-apt-repository ppa:team-xbmc/ppa
$ sudo apt update
$ sudo apt install kodi
Note: ppa:team-xbmc/ppa is for the final release versions.  If you want a beta/release-candidate build (as I did for this installation) just switch ppa:team-xbmc/ppa to ppa:team-xbmc/unstable.

When the final version is released, you can switch to the stable build:

$ sudo add-apt-repository -r ppa:team-xbmc/unstable
$ sudo add-apt-repository ppa:team-xbmc/ppa
$ sudo apt update
$ sudo apt upgrade

ALSA, PulseAudio, TrueHD, DTS-HD MA

From what I can tell not much has changed in this aspect of the guide.  You can use PulseAudio directly with Kodi now, but you won't get TrueHD or DTS-HD MA passthrough support.  And your streams are all processed on-system instead of being sent to your receiver for processing.  So we'll continue to drop down to ALSA instead.

We use a custom XSession to accomplish this.  Which means we log in directly to Kodi instead of logging in to a desktop and running Kodi as an application.

Create our custom session launcher:

$ nano ~/kodi_custom_session_launcher

Paste in:

#!/bin/bash
# Kill PulseAudio so KODI will use ALSA for proper passthrough support
echo autospawn = no > ~/.config/pulse/client.conf
killall pulseaudio
# Start KODI
kodi-standalone
# Restore Pulse Audio
rm ~/.config/pulse/client.conf
pulseaudio --start

Make the launcher executable:

$ chmod +x ~/kodi_custom_session_launcher

Now create the custom XSession entry:

$ sudo nano /usr/share/xsessions/Kodi_ALSA.desktop

And paste in:

[Desktop Entry]
Name=Kodi with ALSA
Comment=This session will start KODI Media Center
Exec=/home/kyle/kodi_custom_session_launcher
TryExec=/home/kyle/kodi_custom_session_launcher
Type=Application
Note: Change "kyle" to your username

Now if you log out you should be able to select "Kodi with ALSA" as a session option from your login manager.  In Mint, this is accomplished by clicking the circle to the right of the user name.

Kodi Configuration

Note: Previously I had to workaround a bug with 24p audio/video synchronization.  That's no longer necessary.

I setup some stuff in Kodi's advanced settings file to disable the splash screen, hide the ext4 file system's "lost+found" directories, and increase the network streaming buffer.

Create the file:

$ nano ~/.kodi/userdata/advancedsettings.xml

And paste in:

<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
  <splash>false</splash>
  <video>
    <excludefromlisting>
      <regexp>lost\+found</regexp>
    </excludefromlisting>
    <excludefromscan>
      <regexp>lost\+found</regexp>
    </excludefromscan>
    <excludetvshowsfromscan>
      <regexp>lost\+found</regexp>
    </excludetvshowsfromscan>
  </video>
  <network>
    <cachemembuffersize>15728640</cachemembuffersize>
  </network>
</advancedsettings>

NUC's Remote Control IR Receiver

To use the NUC's built-in IR receiver we need to install the ir-keytable utility:

$ sudo apt install ir-keytable

Then we define the keytable we need for the Onkyo RC-764M remote using the Xbox keycode 33003.  Create the file:

$ sudo mkdir /etc/rc_keymaps
$ sudo nano /etc/rc_keymaps/onkyo_rc-764m_nec_33003

And paste in:

# table onkyo_rc-764m_nec_33003, type: NEC
# Using Onkyo Remote Code 33003
# Code mappings match same buttons when using Original Xbox Dongle Remote Code
# ScanCode LIRC_KEY # Remote button text
# LIRC_KEY is modified to get correct action in XBMC using LIRC-in-kernel fake-keyboard actions

0x2d2d3a KEY_I #Display
0x2d2d59 KEY_LEFT #Left
0x2d2d5a KEY_RIGHT #Right
0x2d2d47 KEY_UP #Up
0x2d2d48 KEY_DOWN #Down
0x2d2d4a KEY_C #Guide/Top Menu -- Context Menu
0x2d2d4b KEY_ESC #Prev CH/Menu
0x2d2d45 KEY_BACK #Return
0x2d2d56 KEY_O #Setup -- Codec Info
0x2d2d58 KEY_ENTER #Enter
# UNUSED 0x2d2d4f #Audio
0x2d2d35 KEY_COMMA #Skip Left
0x2d2d34 KEY_PERIOD #Skip Right
0x2d2d32 KEY_R #Rewind
0x2d2d33 KEY_F #Fastforward
0x2d2d31 KEY_P #Play
0x2d2d38 KEY_SPACE #Pause
0x2d2d39 KEY_X #Stop
0x2d2d3b KEY_1 #1
0x2d2d3c KEY_2 #2
0x2d2d3d KEY_3 #3
0x2d2d3e KEY_4 #4
0x2d2d3f KEY_5 #5
0x2d2d40 KEY_6 #6
0x2d2d41 KEY_7 #7
0x2d2d42 KEY_8 #8
0x2d2d43 KEY_9 #9
0x2d2d44 KEY_0 #0
# UNUSED 0x2d2d4e #+10
# UNUSED 0x2d2d46 #CLR
# UNUSED 0x2d2d7c #Search
# UNUSED 0x2d2d7d #Repeat
# UNUSED 0x2d2d7f #Random
# UNUSED 0x2d2d7e #Play Mode

Now configure a systemd service to load the keytable at boot.  Create the service file:

$ sudo nano /etc/systemd/system/ir_receiver.service

And paste in:

[Unit]
Description=Configure the IR Receiver for the desired keytable

[Service]
Type=oneshot
ExecStart=/usr/bin/ir-keytable -c -p NEC -w /etc/rc_keymaps/onkyo_rc-764m_nec_33003

[Install]
WantedBy=multi-user.target

ExecStart needs the absolute path to the ir-keytable executable.  Here's what the command options do:  "-c" clears the existing keytable.  "-p NEC" puts the receiver in NEC mode. "-w /etc/rc_keymaps/onkyo_rc-764m_nec_33003" loads our custom keytable.

And enable the new service:

$ sudo systemctl enable ir_receiver.service
Change Note:
Previously I had a custom script that would unload and reload the nuvoton-cir kernel module.  That doesn't appear to be needed anymore.  Maybe it never was.

That script also used to run via rc.local.  That is no longer preferred and we use the systemd service instead

Screen Tearing

I have not seen any screen tearing yet, so I don't think this workaround is needed anymore.

Success

Now Kodi is up and running and everything is grand.

Bonus: Logitech Media Server

I also run Logitech Media Server for the fleet of Squeezebox Radios in the house.  Last time I set up a repository which kept installing updates and clobbering my configuration.  This time I just installed directly from a DEB file.

The information for LMS is a mess.  Lots of out-of-date information and lack of clarity on recommended approaches.  The main place to start is the Wiki page for Debian Packages (Mint is a derivative of Ubuntu which is a derivative of Debian).

One of the links on that page will take you to a package repository where you can download the latest DEB package (currently 7.9.2).  I grabbed the Debian amd64 package and installed it with:

$ sudo apt install ./logitechmediaserver_7.9.2~1545144292_amd64.deb

Rhythmbox sync error

There is very little information available on the Internet regarding troubleshooting music sync errors in Rhythmbox.  I was getting a "could not open resource for writing" error when trying to sync music.  I finally tracked down the issue.  One issue, anyway, I'm sure this can happen for myriad reasons.  In this case the same file existed in 2 locations within my music folder structure.  When syncing to the phone the file names/directories are normalized.  When the 2nd file was attempting to sync, the file already existed on the phone and the sync process would crash.  By removing the duplicate file from the computer the sync process continued successfully.

 

I'm sticking this next part here so I don't have to go digging around the Internet again in the future.

Unrelated to the file crash, but related to syncing music via Rhythmbox: to sync to an abitrary device (in my case, an SD card), place a file called ".is_audio_player" in the root directory of the device.  In that file I placed this text:

audio_folders=music/
playlist_path=playlists/
folder_depth=2
output_formats=audio/mpeg,audio/mp4,audio/aac,application/ogg,audio/x-ms-wma

Then Rhythmbox will detect it as a "sync-able" location.  You may have to close/re-open Rhythmbox and possibly umount/remount the device.

Home Board

Okay, "Home Board" is a dumb name, but I don't know what else to call it.  Now that we have that out of the way, let's talk about this cool thing I built.

This is a 7.5" e-ink display mounted inside a picture frame.  It's hooked up to a Raspberry Pi and updates the weather and calendar information every 15 minutes.  During "special events" it displays an additional celebration message (see example below).

This is a product I've wanted for a long time, but no one made such a thing as far as I could find.  So I finally decided to make it myself.

As you can see, the back is a bit of a mess; but it's all attached, so you only have to run the power cord.

It would be cleaner if I were using a newer Raspberry Pi. The display comes with a "hat" (zip-tied to the frame stand in this picture) that fits directly on the GPIO pins of the newer Raspberry Pi.  It doesn't fit on the version 1 (which I'm using here), so I had to use the provided multi-colored wires and connect the pins myself.

Also, the newer RPis use microSD cards that don't hang over the edge of the case (behind the power connectors).  And they have built-in Wi-Fi so there'd be no additional dongle (the blue glow at the bottom).

The 7.5" screen was the largest e-ink display I could find.  Someone used to make a 10.2" one, but it appears to be discontinued.  The refresh rate is terrible (about 15 seconds to change images, with lots of flashing throughout).  But for my purposes that's fine.  I'm only updating it every 15 minutes.

Here's a sample image of a birthday display:

I wanted a e-ink display for 2 reasons.  The first is that it doesn't glow, so being on all night isn't annoying. And the second is that it's super low power.  Power is only needed while updating the display.  It pulls its power from the Raspberry Pi, which, at full draw, maxes out at ~2 watts.  Which means, assuming some loss in the power adapter, is less than $5 a year (I'm pretty sure I did that math right).

It's awesome.

Parts

  1. Waveshare 7.5 inch e-ink 3-color display with Raspberry Pi connector.
  2. Raspberry Pi with case and power supply (I'm using a version 1, but the display works with 1, 2, or 3).
  3. 5x7" Picture frame
  4. Some miscellaneous mounting hardware to attach Pi to back of frame

The total cost of hardware is about $125 (display, RPi, SD card, case, power supply, cord, frame, mounting hardware).

Software

  1. Weather Underground API (low-volume developer key is free)
  2. Google Calendar Python API
  3. Waveshare driver to interact with the display (included in my code, below)
  4. My custom written Python application that pulls the data together, generates the image, and sends it to the display.

Understanding Meltdown

I've been trying to understand the Meltdown vulnerability that's been in the news lately (a vulnerability in Intel's CPU design allowing an attacker to obtain access to any data in memory on the system).  I understand it at a high level, but every time I've tried to dive into the details to understand an example it falls apart on me.  So I'm going to write this to force myself to fully dissect the parts I'm missing and maybe help someone else in the same boat.

This is not a post intended for a general audience.  I don't expect it will be meaningful or useful to anyone that doesn't already understand programming to some degree.

Eben Upton has a great write up over at RaspberryPi.org which will be the basis of my post.  I'm not going to recreate his work, but instead I'm going to dive into greater detail starting at "Putting it all together".

We start with his pseudocode:

t = a+b
u = t+c
v = u+d
if v:
   w = kern_mem[address]   # if we get here, fault
   x = w & 0b100           # * Modified, See Note
   y = user_mem[x]
* Modification Note:
The original was "x = w&0x100" which I've replaced with "x = w & 0b100".  0x100 is hexadecimal shorthand for the binary 000100000000.  I'm going to use an 8-bit example, so I'm replacing it with 0x4, since my example will only use binary I rewrote it to 0b100.  It is irrelevant to the method of the attack, only changed for convenience.

For those of us that spend our time on higher-level programming languages (like Java, Groovy, Python, JavaScript, etc.) the bit-twiddling needs a little more detail.  That detail is the remainder of my post.

Let's suppose we live in a 8-bit world for this example (mainly so I don't have to write out really long numbers that are irrelevant to the point I'm making).  In our 8-bit world each of our memory locations holds 8-bits.

Now, let's dissect Upton's pseudocode staring inside the "if":

w = kern_mem[address]   # if we get here, fault

This finds the 8-bits contained at "address" in a privileged part of the memory which we shouldn't be able to access, here called "kern_mem".

When the CPU sees us attempt to use that data, it will stop us (i.e., "if we get here, fault").  The crux of this vulnerability is that the CPU will fetch this information for us even though we're not allowed to see it; later it will realize we're not allowed to see it and stop us.  But we do something clever which lets us know what is in that memory even though we never saw it.

Those 8-bits from memory location kern_mem[address] are assigned to the variable "w", let's suppose those bits are 01010101.

w == 01010101 # A Number we're not allowed to see
-----
x = w & 0b100

This is a "masking" operation (think masking-tape when painting).  0b100 is the mask, which is shorthand for 00000100.  This line will "mask" out everything except 1 bit of "w".  The result will always either be 00000000 or 00000100; note that this is either all zeroes or the same value as the mask.  Since both the mask and "w" have 1 as the 3rd bit, the resulting value, in our example, will be 00000100 and assigned to the variable "x".

w == 01010101 # A Number we're not allowed to see
x == 00000100 # A single bit from that number
----
y = user_mem[x]

Now we're going to get the 8-bits contained at "x" in a piece of memory we are allowed to access, here called "user_mem".  "x" is the single bit from the-number-we-cannot-see.  In this case we'll get the 8-bits located at user_mem[00000100] and assign those 8-bits to the variable "y".

We don't care at all what the 8-bits from that location in memory actually are.  The important thing is that the memory system went and got them for us from main memory and loaded them into a local cache.  This process may have taken, say, 100ns.  Next time I ask for the 8-bits in user_mem[00000100] the memory system will say "Oh, I already have that in cache, here ya go" and it will only take, say, 3ns.  Keep this in mind.

w == 01010101 # A Number we're not allowed to see
x == 00000100 # A single bit from that number
y == we_dont_care # Cached value of user_mem[00000100]

These 3 things happen before the CPU realizes we're not allowed to see "w".  Once it makes that realization, it undoes the work so that "w", "x", and "y" no longer have these values so that we can't get to them (effectively at least).

So what good does it do us as an attacker if we can't actually get that data in "w" that we tried to access?

The memory cache still has user_mem[00000100] loaded in to it!

After tricking the CPU into doing this work for me I attempt to access user_mem[00000100].  I know to access user_mem[00000100] because 00000100 was the mask I chose (0b100).  I don't care at all what value is actually stored at user_mem[00000100].  I only care how long it takes to access: I note the current time, access the memory location, and then see how much time has passed.

If it takes ~3ns to access that memory, it must have been in the cache.  It would only be in the cache if "x" had been 00000100.  "x" would only have been 00000100 if the 3rd bit of "w" was 1.

I now know that "w" looks like ?????1??.  That was a lot of work for just a little bit of information (pun intended).  But CPUs are quick and this can all be happening without you being aware of it.  So, now let's repeat the process, but this time we'll change our mask:

w == 01010101 # A Number we're not allowed to see
-----
x = w & 0b10

The mask has been moved over one bit.  Because the 2nd bit of "w" is 0, "x" holds the 8-bits 00000000.

w == 01010101 # A Number we're not allowed to see
x == 00000000 # A single bit from that number
----
y = user_mem[x]

This time we get the 8-bits located at user_mem[00000000] loaded in to the cache.

w == 01010101 # A Number we're not allowed to see
x == 00000000 # A single bit from that number
y == we_dont_care # Cached value of user_mem[00000000]

This time the mask was 00000010, so we time how long it takes us to access user_mem[00000010].  This time it takes ~100ns, by which we determine that it must not have been in the cache.  That could only be true if "x" had been 00000000.  "x" could only have been 00000000 if the 2nd bit of "w" had been 0.

Now we know that "w" looks like ?????10?.  Keep doing this over and over again and we can read any data we like, we just have to piece it together.

Is it not a strange fate that we should suffer so much fear and doubt for so small a thing? So small a thing!

-- Boromir, "The Fellowship of the Ring"

Like Sauron's One Ring, this truly is a small thing, but will bring about much pain and anguish.

One [Flaw] to bring them all and in the darkness bind them.