"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

See also my Mastodon page.

Sun Mon Tue Wed Thu Fri Sat
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Raspberry pi powerdown and powerup button

Raspberry Pi Zero

TL;DR: This post describes an easy way to add a power button to a raspberryp pi that:

  • Only needs a button and wires, no other hardware components.
  • Allows graceful shutdown and powerup.
  • Only needs modification of config files and does not need a dedicated daemon to read GPIO pins.

There are two caveats:

  • This shuts down in the same way as shutdown -h now or halt does. It does not completely cut the power (like some hardware add-ons do).
  • To allow powerup, the I²C SCL pin (aka GPIO3) must be used, conflicting with externally added I²C devices.

If you use Raspbian stretch 2017.08.16 or newer, all that is required is to add a line to /boot/config.txt:


Make sure to reboot after adding this line. If you need to use a different gpio, or different settings, lookup gpio-shutdown in the docs.

Then, if you connect a pushbutton between GPIO3 and GND (pin 5 and 6 on the 40-pin header), you can let your raspberry shutdown and startup using this button.

If you use an original Pi 1 B (non-plus) revision 1.0 (without mounting holes), pin 5 will be GPIO1 instead of GPIO3 and you will need to specify gpio_pin=1 instead. The newer revision 2.0 (with 2 mounting holes in the board) and all other rpi models do have GPIO3 and work as above.

All this was tested on a Rpi Zero W, Rpi B (rev 1.0 and 2.0) and a Rpi B+.

If you have an older Raspbian version, or want to know how this works, read on below.

Powering down your pi

To gracefully power down a Raspberry Pi (or any Linux system), it has to be shut down before cutting power. On the rpi, which has no power button, this means using SSH to log in and running a shutdown command. Or, as everybody usually does, cutting the power and accepting the risk of data corruption.

Googling around shows a ton of solutions to this problem, where a button is connected to a GPIO pin. The GPIO pin is monitored and when it changes, a shutdown command is given. However, all of these seem to involve a custom daemon, usually written in Python, to monitor the GPIO pin. A separate daemon just for handling the powerbutton does not sound great, and if it is not apt-get installable, it seems too fragile for my tastes. Ideally, this should be handled by standard system components only.

Another thing is that a lot of these tutorials recommend wiring a pullup or pulldown resistor along with the button, while the raspberry pi has builtin pullups and pulldowns on all of its I/O pins which can just as easily be used.

It turns out a combination of systemd power key handling, combined with the kernel gpio-keys driver and devicetree overlay can be used to handle graceful shutdown completely with existing system components.

Shutdown using systemd-logind

Having a shutdown button connected to a GPIO pin is probably not so uncommon, so I Googled some more. I came across the 70-power-switch.rules udev file from systemd-logind, which adds the "power-switch" tag to some kernel event sources representing dedicated power buttons. Since v225 does this for selected gpio sources as well (commit). A bit of digging shows that:

  • The udev rules add the "power-switch" tag to selected devices. Udev does not use these tags itself, but other programs can.
  • The "power-switch" udev tag causes systemd-logind to open the event source as a possible source of power events.
  • When a KEY_POWER keypress is received, systemd-logind initiates a shutdown. It also handles some suspend-related keys.
  • Since last week, 70-power-switch.rules tags all event sources as "power-switch" (commit) and lets systemd-logind figure out which could potentially fire KEY_POWER events (commit) and monitor only those (though this change does not really change things for this usecase).

Linux gpio-keys driver

So, how to let a GPIO pin generate a KEY_POWER event? The first logind commit linked above has an example device tree snippet that sets up the kernel gpio-keys driver which does exactly that: Generate key events based on gpio changes.

Normally, the devicetree is fixed when compiling the kernel, but using a devicetree overlay (see the Rpi device tree docs) we can insert extra configuration at boot time. I found an example that ties multiple buttons to GPIO pins and configures them as a tiny keyboard. Then I found an example in the the gpio-button package that does the same with a single button and also shows how to configure a pulldown on the pin.

I've created a devicetree overlay based on that example, that sets up the gpio-keys driver with a single GPIO to trigger a KEY_POWER event. The overlay is just a text file and I added elaborate comments, so look inside if you are curious.

This overlay was merged into the official kernel repository and is shipped in Rasbpian images from 2017.08.16 and onwards. See below for instructions on manually compiling and installing this overlay on older images.

Waking up

With the above, you get a shutdown button: Press it to initiate a clean shutdown procedure, after which the raspberry pi will turn off (note that it does not completely cut power, that would require additional hardware. Instead, the system goes into a very deep sleep configuration while still drawing some current).

After shutdown, starting the system back up means removing and reinserting the USB cable to momentarily cut power. This begs the question: Can you not start the system again through one of the GPIO pins?

I found one post that pointed out the RUN pin, present on Rpi 2 and up, which can be shorted to GND to reset the CPU (without clean shutdown!), but can also power the system up. However, having two buttons, along with the risk of accidentally pressing reset instead of shutdown did not seem appealing to me.

After more digging I found a forum post saying that shorting GPIO3 or GPIO1 to GND wakes up the Rpi after shutdown. Official docs on this feature seem to be lacking, I found one note on the wiki saying bootcode.bin (version 12/04/2012 and later) puts the system in sleep mode, and starts the system when GPIO1 or GPIO3 goes low.

Conveniently, all Rpi versions either expose GPIO3 or GPIO1 at pin 5 of their 26-pin or 40-pin header, so that pin can always be used for waking up.

Since GPIO3/GPIO1 is also a normal IO pin, this is perfect: By configuring the shutdown handling on GPIO3 or GPIO1, the same button can be used to shutdown and wake up. Note that GPIO3 and GPIO1 are also an I²C pin, so if you need to also connect I²C-devices, another pin must be used for shutdown and you cannot use the wakeup feature. Also note that GPIO3 (and GPIO2) have external pullups at least on the Rpi Zero.

Setting this up on older Rasbpian versions

On Rasbpian versions older than 2018.08.16, two additional steps need to be taken:

  1. Older images do not include the overlay yet. You will need to get and build the DT overlay yourself. Download the devicetree overlay file. The easiest is to run wget on the raspberry pi itself:

    $ wget

    Then compile the devicetreefile:

    $ dtc -@ -I dts -O dtb -o gpio-shutdown.dtbo gpio-shutdown-overlay.dts

    Ignore any "Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property" messages you might get.

    Copy the compiled file to /boot/overlays where the loader can find it:

    $ sudo cp gpio-shutdown.dtbo /boot/overlays/
  2. Older images run a systemd version older than v225 (check with systemd --version), which only handles KEY_POWER events from specific devices. To make it work with gpio-keys as well, create a file called /etc/udev/rules.d/99-gpio-power.rules containing these lines:

    ACTION!="REMOVE", SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform", \
        DRIVERS=="gpio-keys", ATTRS{keys}=="116", TAG+="power-switch"

Update 2018-04: I restructured this post to reflect that Rasbpian has merged the needed changes and make the instructions focus on making things work with a recent Rasbpian image (while keeping the extended instructions for older images at the bottom).

Update 2019-01: Turns out the orginal Pi1 B rev1.0 has a different pinout, so include instructions for that. Thanks to P Lindgren for suggesting and testing this.

Update 2019-07: It seems that the Pi4 bootloader does not currently support wakeup using GPIO3. This is expected to be changed in the near future (bootloader version RC3.3 has the fix) so newly manufactured Pi4 boards have this fixed), but you might need to update the bootloader (using the recovery process) of the pi4 if you have one with the older version. See this thread for more details. Thanks to Tyler for noticing this.

Gamemaster wrote at 2017-07-24 09:33

Sadly this did not work for me. However, the solution at 8bitjunkie did if you want to compare notes.

Matthijs wrote at 2017-07-24 09:41

Hm, pity. I wonder what part is failing exactly (the link you gave has a completely different software approach, so hard to compare). If you want to help out debugging this, drop me an e-mail at and I'll be happy to suggest some tests to see what is failing exactly.

Windy City Jess wrote at 2017-08-03 06:13

Matthijs, I've tried many solutions with no luck. It works for me now that I followed your directions. You were right on all accounts, the RPi device-tree page you linked above is very helpful and systemd 215 did require 99-gpio-power.rules. Initially skipped over this step because I assumed it was optional. I should learn to read and follow directions :) Thank you for sharing this. - Jess

Blistex77 wrote at 2017-08-18 10:55

I've been looking for a simple solution for a while, I'm quite a noob, but it looks simple enough to achieve, thanks a lot! I have only one question, to be sure, I would only need a jumber cable and a power button (one in this kit for example

Matthijs Kooijman wrote at 2017-08-18 11:31

That's correct, you basically only need something that can momentarily connect two pins together. A screwdriver would suffice, but two jumperwires (or one cut in half soldered to the button) and a pushbutton would be more obvious :-)

Blistex7 wrote at 2017-08-18 11:59

Thanks for the fast reply, I'll try this asap!

John w wrote at 2017-08-22 19:04

does the dt overlay collide with i2c? I want both. On this project ill probably resort to an on off ic but not having i2c if you want this functionality with out ic is kinda a deal breaker. pi doesnt have a lot of io to begin with

Matthijs Kooijman wrote at 2017-08-22 19:21

Yeah, this overlay collides with I²C. I haven't tried myself, but got a report from someone that ran into problems. Note that you can easily switch to another pin for the shutdown feature, you'll just lose the button-based power-on (but if you really need it, you could wire a separate reset button to the RUN pin, which should also power on after power off).

Dom C wrote at 2017-08-24 00:22

What would happen if your switch was latching?

I have s nice LED lit one around that would be perfect for this but feel it might not work in this case?

Matthijs Kooijman wrote at 2017-08-24 00:54

I believe that when the pi is powered on, it behaves like a keyboard key, so it sends a keydown when the switch is closed and a keyup when the switch is opened. I'm not sure what systemd responds to, probably both. When the pi is powered down, I believe it only responds to a falling edge, so the switch closing.

This means that if you use a latching switch, things might just work - close the switch to power up, open the switch to generate a keyup and power down. It could be that a keyup is not sufficient, or that on startup a keydown is generated. In that case, it might be needed to set the active_low flag to 0, so you get a keydown on a rising edge instead. One risk of this approach is that the pi state and the button state might become out of sync, but that should be easily fixable by just toggling the button once or twice.

Dom C wrote at 2017-08-27 19:06

I bit the bullet an bought a push-to-make button anyway. All working great until i tried to add a seperate GPIO pin for a Power LED.

I added; dtoverlay=gpio-poweroff,gpiopin=6,active_low

But this seemed to cause some kind of clash? No longer did my button (using GPIO3 as suggested) all me to power back on (although shutdown continued to work fine)

Any thoughts?

Matthijs Kooijman wrote at 2017-08-29 18:46

@Dom, I'm not entirely sure what you're saying, but if you change the pin number in the overlay, that only influences the shutdown, the power-on is hardcoded in the bootloader (or something like that). For you it seems to be reversed, which I can't quite explain?

Also, note that active_low should normally get a value of 0 or 1, and it defaults to 1 (active low). To make it active high, use active_low=0.

uzanto wrote at 2017-08-30 12:25

Thank you mate!

Working in my RPi without the udev rule.

Raspberry Pi 3 B

Raspbian Stretch with kernel 4.9.41-v7+ SystemD 232

I need to make the directory overlays inside /boot/

Simon wrote at 2017-09-01 21:42

Pi ZeroW with Stretch. This seems to shutdown kind-of (ssh and other servers become unreachable, even usb otg serial console dies) but it still responds to ping, then won't start up again. Any ideas?

Matthijs Kooijman wrote at 2017-09-04 10:11

@Simon, interesting, seems like the shutdown fails somehow. Did you install extra packages that might interfere? Does it work with a clean stretch system? Does a normal shutdown from the commandline (shutdown -h now and systemctl poweroff) work? Anything interesting in the syslogs? Perhaps redirect the primary console to serial (with the console= kernel commandline option, not sure how to set that or if that works with an USB-otg serial port) and see if anything shows there?

Arjen wrote at 2017-09-23 17:43

Is there a way to insert a delayed reaction to the button pressed? I do not want it to shut down if I accidentally hit the button, it should be pressed for e.g. 1 sec?

Matthijs Kooijman wrote at 2017-09-25 12:05

Looking at the gpio-keys documentation, it does not support a "delayed press":

However, IIRC the gpio-keys driver does generate proper keydown and keyup events, so systemd could, in theory, detect the length of a press and require a minimum length before shutting down the system. I do not think systemd supports this now, but perhaps the maintainers would be willing to add it. You could see if there's a feature request for this already at and, if not, add one? If you find or add one, please post the link here!

John Shearing wrote at 2017-09-26 08:07

Worked perfectly! Thank you so much for the solution, the explanation, and for taking the time to link this page in other forums so that it could be found.

John Shearing wrote at 2017-09-28 22:34

I have three questions please:

  1. Pin 5 is quite sensitive. Just attaching or removing a small wire which is not connected to anything else causes the pi to shut down or start up. Can something be done to make this pin less sensitive?

  2. I am powering the pi with a battery and charging it a circuit which is capable of completely removing power from the pi after your shutdown process has completed it's work. A URL to the charging device is as follows: In order to tell the charger to kill power I need a pin on the pi which goes from 3.5 volt to 0 volts after your shutdown process has run. Is there a way to make a pin behave this way? If so, please tell me how.

  3. I am running the GDM3 display manager because it is the only login screen I have found which incorporates a virtual onscreen keyboard. If I have started the pi but have not yet logged in and I short pins 5 and 6 together then your process will blank the screen but will not shut down the pi. Shorting the wires again immediately returns the login screen. My question is: Is it safe to completely remove power when the pi is in this condition or must I first find a way to execute the shut down command.

Any further guidance you can give would be greatly appreciated. Thanks again for all your help. John

Matthijs Kooijman wrote at 2017-10-01 10:31

@John, I'll try answering your questions.

  1. The pin should have a pullup resistor (internal to the CPU and external because of I²C) that prevents it from being super-sensitive. Perhaps your using a raspberry pi without an external pullup? In any case, using a smaller pullup (which needs more current to drop 3.3V) could help there. Typical values are between 1k and 100k. You could try 1k (or even smaller, but the smaller the pullup, the more current flows when you press the button).

  2. I believe there is a "gpio-poweroff" kernel module and overlay for this usecase, but I haven't looked at it at all.

  3. The handling of the power button normally happens in systemd. I suspect that GDM3 "inhibits" the power key handling in systemd and then handles it in a different way itself. Perhaps you could configure GDM3 to not handle the power keys at all, or to handle the power key by doing a shutdown just like systemd normally does?

John Shearing wrote at 2017-10-07 02:41

Hi Matthijs Sorry for the late response. It has taken me some time to absorb all the information you have given us. Truly everything we need to work with overlays is referenced in your post.

Thanks for explaining how to use a pull up resistor.

The gpio-poweroff overlay worked perfectly. It was already on the pi in the overlays directory. I called it in config.txt right after calling your overlay.


Directions for using all the overlays found in the overlays directory are in the README which is found in the same overlays directory.

For some reason the gpio-poweroff overlay interferes with restart functionality of pin 5 but that doesn't matter for what I am doing. It still halts the pi just fine.

I am now researching the problem where the overlays don't seem to load until after GDM3 login or as you suggest, the overlay behavior is overridden by GDM at the systemd level. I will report back if a solution is found.

Thanks again for all your help.

dqbydt wrote at 2017-10-10 01:42

This mechanism works well on a CM3+CMIO3. One question: you mentioned in an earlier comment "the power-on is hardcoded in the bootloader". Do you have any more information regarding this? Is there no way to configure the GPIO pin for powerup? I cannot use GPIO1 or GPIO3 in my application because both are irrevocably tied to other functions. I am able to powerup by grounding the RUN pin, but would be nice to have shutdown as well as powerup on the same GPIO.

Matthijs Kooijman wrote at 2017-10-10 08:55

> Do you have any more information regarding this? Is there no way to configure the GPIO pin for powerup?

All info I have is linked in the post above. AFAIK, the wakeup pin is hardcoded in bootcode.bin, for which no sources are available. However, re-reading the forum post linked above, it says "I've now added a way to wake the board through GPIO.", which suggests that whoever wrote that does have access to the bootloader source. Perhaps you could try asking him or her (or other official rpi engineers) about this? If you find out anything, please report back here!

dqbydt wrote at 2017-10-11 17:57

I did ask on RPi forums, and this is the reply from the engineer (dom) who originally added the wakeup support:

"The low power mode following "halt" is achieved by not powering on a number of power domains/clocks. That means no access to sdcard and hence no support for configuration files to choose wakeup pin."

So I guess you are restricted to using GPIO1/3 for wakeup.

JRoth wrote at 2017-12-02 19:54

Thank you for making this available, it works much better than the python solutions I've tried.

George Poppa wrote at 2020-11-14 07:34

Enjoyed this mod, had it working for some time. Is there a way to gracefully close firefox when I press the sleep button to powerdown the pi? At the moment, it crashes & requires manual intervention on startup to restore the previous session.

Matthijs Kooijman wrote at 2020-11-14 10:02

George, I would actually expect this to gracefully shutdown processes already. The kernel sends out a shutdown signal, similarly to when you press the powerbutton on a regular PC. Systemd picks this up by initiating a system shutdown, I believe in the same way as when you would run shutdown -h now.

I would expect this to gracefully terminate all processes, only resorting to forcibly killing if things do not terminate quickly enough. Here's some ideas:

  • Maybe your Firefox somehow does not respond to the terminate signal, or not fast enough? Maybe systemd can be configured to wait a bit longer?

  • Maybe this kills the X server which cause Firefox to crash abnormally before it can gracefully terminate?

  • You could try shutdown -h now and/or systemctl poweroff and see if the same problem happens there?

  • Is there anything in the system logs after the shutdown? Maybe some error messages from Firefox?

Let me know if you find anything!

Bryan S wrote at 2021-06-02 18:43

I have successfully followed these instructions to shut down my Raspberry Pi 400 when I short pins 5 and 5, but am unable to get my Pi to wake when I short pins 5 and 6.

I tried installing the latest version of the bootloader using raspi-config and checked my eeprom file to see that WAKE_ON_GPIO is set to 1....I also tried setting it to 2 as the docs say that "Pi 400 has a dedicated power button which operates even if the processor is switched off. This behaviour is enabled by default, however, WAKE_ON_GPIO=2 may be set to use an external GPIO power button instead of the dedicated power button." Still no luck.

Any ideas why I cannot start my pi by shorting pins 5 and 6 or ideas for debugging this?

Matthijs Kooijman wrote at 2021-06-02 21:11

Hm, I have not much idea about the Pi 400. I mostly investigated the shutdown part of things, the power-on part is handled by the closed-source bootloader, so not much to debug on.

However, searching for the WAKE_ON_GPIO you mention, I find "... will run in a lower power mode until either GPIO3 or GLOBAL_EN are shorted to ground", so that suggests the bootloader on pi4/pi400 uses GPIO3 like most other pi boards.

However, looking at the pi400 pinout, it looks like the pinout is different, and GPIO3 is not at pin 5, but at pin 15! Maybe shorting pin 15 to GND (which is not at pin 16, btw) would work to power on again?

Let me know if this helps, then I can update my post with some extra info :-)

Bryan Shiffman wrote at 2021-06-03 15:53

Thanks for getting back to me so quickly. I tried connecting pin 15 to pin 6 (ground) and was unable to shutdown or start up.

When I look for the pin layout for pi400 there's conflicting info out there which is making life difficult!

I installed the Python library gpiozero and ran "pinout" to get a look at the GPIO pin layout. It shows GPIO3 on pin 5.

I ran "gpio readall" and it shows GPIO 3 on pin 15.

All that being said, I'm fairly certain that pin 5 is GPIO3 on my board since:

  1. I can shutdown my pi by shorting pins 5 and 6 once I set dtoverlay=gpio-shutdown,gpio_pin=3 in /boot/config.txt.

  2. I looked at /proc/cpuinfo and it lists my Hardware as BCM2711. "pinout" shows GPIO on pin 5 and shows the hardware as BCM2711.

So, I'm back where I started: I can shutdown by shorting pins 5 and 6 but cannot start back up.

Matthijs Kooijman wrote at 2021-06-03 15:59

Bummer, I had hoped this would solve things.

I agree with your assessment that you probably need pin 5, but only based on your first argument (that the gpio-shutdown overlay works with gpio_pin=3).

Your second argument probably does not hold: The BCM2711 just refers to the chip, but which chip pin is routed to which expansion header is determined by the PCB layout, so is not necessarily dictated by the chip used.

Having said that: I have no further suggestions, unfortunately. Maybe you could ask on the raspberry pi forum, I think there are some people there with access to the bootloader source code, which might be able to verify how things are intended to work...

Seamus wrote at 2021-06-16 19:00

So glad to see this thread is still active :) I'd like to confirm something if I could: As I understand your reply of 2017-08-22 19:21, the dtoverlay for gpio-shutdown must be on gpio_pin=3 (a.k.a. I2C SCL) to achieve both power up and power down using a single switch - is that still the case today?

Matthijs Kooijman wrote at 2021-06-16 21:29

> the dtoverlay for gpio-shutdown must be on gpio_pin=3 (a.k.a. I2C SCL) to achieve both power up and power down using a single switch - is that still the case today?

AFAIK that is indeed still the case. The power-up behavior is hardcoded in the bootloader, the dtoverlay does not configure this is in any way (AFAIK the power-up pin is not configurable, if it would be, that would need to happen in config.txt).

Seamus wrote at 2021-06-23 01:30

Re GPIO 3 as the sole means of startup: That seems to agree with the docs, and other things I've read. However, I've seen a recent claim that it's been done using GPIO 21 (no URL as my last post was rejected as spam?!). THe only thing that occurs to me is that with the firmware and hardware being proprietary - we cannot know for certain. :(

Matthijs Kooijman wrote at 2021-06-23 10:00

> However, I've seen a recent claim that it's been done using GPIO 21

Oh, that would be interesting, as it would free up GPIO3 to be used for I²C.

> (no URL as my last post was rejected as spam?!)

Yeah, the spamfilter rejects all post that contain links, since that turned out to reject almost all spam. If you want to post a link, just post it without the protocol prefix (i.e. just, which works well enough to be used by humans (and I often edit the comment manually to make the link clickable again).

Matthijs Kooijman wrote at 2021-06-24 12:22

@Seamus, thanks for the link. Reading that thread, it seems someone has made startup using GPIO21 working on a rpi 4B, but the report is a bit vague. If anyone has a 4B and can verify that GPIO21 does indeed work (and maybe also check if GPIO3 also works), I'll update my post to reflect that.

Seamus wrote at 2021-07-05 22:22

I had hoped to get some feedback from my answer to the gentleman that made that claim - a confirmation of some sort. I'd be willing to try it on my 4B, but up to my ears with my own projects right now. Speaking of, I've prototyped & now tested a "single button on-off" circuit that works with the low power mode on the 4B (WAKE_ON_GPIO=0 and POWER_OFF_ON_HALT=1). Let me know if you're interested in seeing this - working on a "publish-able" schematic now.

Matthijs Kooijman wrote at 2021-07-06 16:10

> Speaking of, I've prototyped & now tested a "single button on-off" circuit that works with the low power mode on the 4B (WAKE_ON_GPIO=0 and POWER_OFF_ON_HALT=1). Let me know if you're interested in seeing this - working on a "publish-able" schematic now.

Cool, sounds good, I would be interested. Not so much for myself (I do not actually have a Rpi4), but would be a good addition to this post. If you publish your work somewhere, I'd be happy to link to it from here.

Seamus wrote at 2021-07-07 04:49

Here you are: I've linked my Name to the page on GitHub. Feel free to use any or all of it.

Bob McCourt wrote at 2022-03-27 15:42

Good morning,

I am running a Pi 4B with Volumio installed as a music streamer. I have been trying to install a power button for several days to no avail. I have tried several different ways with no success. I have tried using physical pin 5 and 6 as well as physical pins 39 and 40. I did manage to get the power LED working off of physical pins 9 and 10 but cannot seem to get the button to work on power down. I can wake to Pi but shutdown is a no go. ANY help would be greatly appreciated! Thanks!

Matthijs Kooijman wrote at 2022-03-28 13:08

Hey Bob, bummer that it's not working for you. One thing I would try to confirm first is to see if the kernel gpio-keys driver is successfully loaded and generating KEY_POWER presses. The kernel startup messages (dmesg) might offer some info on this, and you can try to log keypresses (using a command like libinput debug-events, which I think should show these buttonpresses). Depending on the results, you could also try manually reading the gpio pin state to rule out hardware issues, or look into the systemd-logind logs and udev rules to see if that correctly sees the keypresses).

I hope this helps figure this out, feel free to comment more if you need more help further on :-)

RogerWhiteley wrote at 2024-03-16 09:29

@Bob McCourt, I use physical pins 39 and 40 to shutdown using the overlay, what I forgot was that the gpio number != physical number, so the line should read dtoverlay=gpio-shutdown,gpio=21 this works with a momentary pushbutton attached to a two pin header. I use a custom case, 3D printed with a dedicated hole for the button.

Kevin Vincent wrote at 2024-03-28 16:51

Is there a way to do this so that you can set it up to not be a momentary button press, more like using a switch so if you pulled 2 gpio pins to ground it would always shutdown immediately after starting as long as those 2 pins were bridged?

Matthijs Kooijman wrote at 2024-03-28 20:17

If you mean it should shutdown ASAP if the pins are bridge already on startup, then I'm doubtful that will work - the gpio-keys driver probably needs to see a transition to generate a keypress. One thing I could image is that autorepeat could be helpful (i.e. keep generating the same keypress as long as the key is kept "pressed"), but I suspect this will only start from an initial transition, not if the key is already "pressed" on startup.

You could try though - this is triggered by setting the autorepeat in the devicetree (see

This requires modifying and compiling the devicetree overlay - the instructions in the "" section in the blogpost above should be helpful. The linked .dts file should be slightly modified: below the line compatible = "gpio-keys"; you should add a line autorepeat;

If that does not work, there might be other solution (different kernel drivers or something in userspace), but I have no ready suggestions.


Comment can contain markdown formatting

45 comments -:- permalink -:- 14:54
Copyright by Matthijs Kooijman - most content WTFPL