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)

Drawings n' that

PIBEES

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.)

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!.

 

Drawings n' that

PIBEES

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.

The cards in that documentation look chunky - presumably mixing Pi extension cards can quickly give rise to compatibility/connectivity issues.

But it's been a long day and I only just remembered that my plan was to go via MDI connection, so the audio on the Pi is irrelevant. \o/