Pi install
GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)
oldButtonState1 = True
while True:
#grab the current button state
buttonState1 = GPIO.input(5)
# check to see if button has been pushed
if buttonState1 != oldButtonState1 and buttonState1 == False:
subprocess.call("echo 1 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now", shell=True,
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
oldButtonState1 = buttonState1
time.sleep(.1)
On a click of the button it turns off the backlight and shuts the Pi down. I only need that one line as it automatically turns the backlight back on on a power up. However, although it was working initially on a rebuild, the sound's dropped off again. :C
My sound broke in Arch by doing something that buggered around with PulseAudio, which then fucked up ALSA, because PulseAudio is a buggy bloated piece of shit that nobody actually needs.
So maybe you installed/upgraded (possibly automatically) something that did fiddled with PA?
If you do really want to do it this way, since you only care about shutdown, you don't need to store/check oldButtonState and can simplify it to:
GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)
# endless loop until button is pressed
while GPIO.input(5):
time.sleep(.1)
# verify button state before switching off
if not GPIO.input(5):
subprocess.call("echo 1 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now",
shell=True,stdout=subprocess.PIPE, stderr=subprocess.PIPE)
The if verification is probably not necessary (depending on how Python works), but even so it acts as both a safety against unwanted shutdown (incase something goes wrong), and clarifies the intent slightly. (The event-driven/callback method would make it even clearer.)
IQaudIO produce this document (a pdf download) which seems to be wrriten in multiple styles and changes between being helpful and downright confusing.
I'll check the onboard audio is properly disabled and might go back to a vanilla image, and test the sound after every change made.
Other than being more optimised (and I appreciate the arguments for non-bloated code) does that have a knock on effect on real world performance or not?
Thanks for the suggestions though, I'll try that once I get the sound working again!.
So standard documentation.
Pretty much. There's an indepth walkthrough of how to build a case with diagrams, then when it comes to installing a rotary encoder as a volume knob it's referencing external libraries and assumes ones knows how to call seperate processes as part of the code.
As a linux luddite, I'm able to fumble my way through most of it with online guides and PB's assistance, but it's not something I use everyday, so whatever I learn soon leaves my brain to be replaced with ingratiating one line lyrics from songs that seem to be on a permanent repeat.
And what's wrong with the onboard sound that made you opt for this route?
Dunno - it has the potential to, but I suspect one instance isn't going to have much impact - but if you do get symptoms of the CPU being congested (e.g. stuttering audio or sluggish response), I'd check that first.