Miscellaneous Monday quickies: volume adjustment via keyboard

Being an enthusiast of minimalist GUI systems, I'd heard some time ago of the i3 window manager and liked what I'd read. Recently, I switched over a couple of my computers to it and have been quite happy with it.

I ran across a news item the other day that was touting the virtues of i3 and which therefore caught my interest. Especially intriguing was the author's description of how, using that WM, certain keyboard keys or key combinations could be mapped so as to govern the computer's sound ouput--intriguing, that is, even apart from the fact that it was a description of a system configured to use pulse audio for sound output (my preference for ALSA over pulse is material for another entry). Still, I felt it should not be too hard to modify those directions to suit my systems.

As in the article referenced, it was a simple matter of modifying ~/.i3/config, adding some lines. In my case, the lines were as follows:

bindcode 171 exec amixer -q set Master 2dB- unmute bindcode 173 exec amixer -q set Master 2dB+ unmute bindcode 121 exec amixer -q set Master toggle

The keyboard on that particular machine is what I believe is called a "multimedia keyboard," meaning that it has a few keys dedicated, rather than to alphanumeric characters, to multimedia functions such as volume control. Finding which key codes to place in that file was a simple matter of using the xev utility. The ALSA--as opposed to pulse audio-- commands for raising, lowering, and muting volume were readily found in an internet search.

After a few trial runs and further tweaks, a quick restart of i3 revealed that things were working as expected. Flush with success from that project, I decided I might get the same thing working on another computer in my apartment--though that computer, since it needs to be usable for my wife, runs a different WM; incidentally, it runs JWM with a home-brewed Gnome 2 mock-up interface (I plan to do a write-up someday describing the Gnome 2 mock-up I created).

The basic idea of getting keyboard keys controlling volume is the same, though it involves editing a different configuration file--named ~/.jwmrc--that uses alternate syntax. Since the keyboard attched to this machine is not a multimedia keybaord, I ended up repurposing some seldom-used keys, in combination with the Alt key, for volume control functions. The entries in that file are as follows:

<key mask="A" key="Delete">exec:amixer set Master 3%-</Key> <key mask="A" key="End">exec:amixer set Master 3%+</Key> <key mask="A" key="Next">exec:amixer set Master toggle amixer</Key>

That pretty much sums it up this quickie entry.

Miscellaneous Saturday quickies: udev rules and you

PREFACE: "udev is a device manager for the Linux kernel. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware loading." (Wikipedia entry for udev) Those wanting a better orientation to udev may wish to do some further reading of material found at some of the links provided in this entry.

I felt a great sense of triumph when, oh, 5 or 6 years ago, I managed to create a udev rule that would make a scanner I was trying to use be identified in a certain way to the system. In the wake of that project I was also able to craft some udev rules for some external hard drives I was using. Since then, I've learned, however, that computer tech is a quickly moving target; the things I took such great pains to learn and apply back then, as I now know, might be of little use to me in just a few short years.

Case in point: fast forward to yesterday, when, after a Mythtv/Mythbuntu upgrade, one of the capture cards I'd written a udev rule for was no longer being properly identified to the system. The reason being, of course, that some changes had been made to udev conventions and the old trick I'd used to identify that card to the system was no longer working.

So I had to rewrite the rule. It turns out some parts of the routine for identifying and naming devices have been a bit simplified. The new incantation I needed to run to find out details about the catpure card which I could incorporate into the udev rule goes like this:

udevadm info -a -p  $(udevadm info -q path -n /dev/sdb)

(where sdb is replaced by the device name of the hardware you're querying--in my case, video0)

That bit was lifted from a 2009 entry from a blog located here. He references an even older web page as a source for his information, one I'd used in my first attempts 5 or 6 years ago, and which looks to be pretty outdated now. That page is called "recativated" and can be found here.

In any case, an even simpler rendition of the incanation above is offered in the "comments" section of that blog, as follows:

udevadm info -a -n /dev/sdb

Both gave the results I needed and helped me resolve the issue of the card being identified and labelled as I wanted it to be. Maybe this information will be useful to you as well--at least so long as you find and try to apply it before the next big change comes to udev, or udev gets superseeded by some other, "better" utility.