[SOLVED] Initiating shutdown from a button press

louigi600 · 02-11-2014, 01:48 AM

I've been able to somewhat salvage the tablet my son broke the screen on by making it into a headless machine running (an OS pertinent to the subform this has been posted on: Slackware ARM).
The device only has 3 physical buttons: PWR, VOL+ and VOL-

Can I avoid having to access the machine via ssh to have it shutdown properly ?
Can I have it shutdown properly by pressing the power button ?

sgosnell · 02-11-2014, 10:33 AM

You should be able to shut it down by pressing and holding the power button. That's the usual way to shut down a tablet or smartphone. If you've installed a different OS on the tablet, then you will need to check the documentation for that OS, but it should continue to work as before.

louigi600 · 02-11-2014, 11:03 AM

The press and hold is equivalent to a hard power-off I'm looking for proper shutdown.
Slackware ARM has no official support for that hardware ... in any case this is the right subform to ask Slackware ARM community if anyone knows how to go about it ... maybe someone knows how android detects the vol,power,home,menu and exit buttons being pressed ... so maybe it's also usable on Slackware ARM.

I was looking at both dmes and messages while fiddling with the buttons but there was nothing detected.
On acpi systems things show up when you start pressing unhandled buttons ... I remember customizing acpi actions on my eeepc by looking at dmesg and by using logger as action in the acpi handler script to show me what was going on ... but I think that it's not applicable on ARM.
Could it be that I need to check some gpio pin status ?

sgosnell · 02-12-2014, 09:41 AM

On the tablets I've owned, a quick press of the power button turns off the screen. Pressing and holding for about 2 seconds gives a menu to shut down, reboot, and some other choices. You have to hold the power button for 10 seconds or more for a complete hard shutdown. That said, I have no idea how Slackware or any other Linux distro would interpret any of the power keypresses.

louigi600 · 02-12-2014, 02:14 PM

Maybe my initial post or the subject are a bit too vague ... anyway the screen is broken, the tablet is running slackware ARM 14.0 headless.

sgosnell · 02-12-2014, 05:50 PM

I was aware of the situation. As I said, I don't know how the interpretation of the power button presses is done in Linux. It may be done by the kernel, and you might have to jump through some hoops to get it working. But Android uses a Linux kernel, so it should be possible. In Android, there are three possible actions of the power button - short, medium, and long duration. The medium duration press should initiate shutdown, one way or another. Getting that menu to appear may be difficult, though. I really don't know where else to point you.

louigi600 · 10-05-2014, 07:37 PM

While doing some research I came across this. I found the section about JACK Soc Architecture particularly interesting:

Quote:

The mainline kernel prefers another approach, using our beloved Jack SoC architecture. It also provides a convenient way of reporting button pushes, which is quite nice.

I've been searching for information about this ans apparently the status of the switches can be read in
/proc/asound/card0/codec#0
in the "Pin-ctls:" sections.
but that only holds true on x86 ... anyone know where to get this info on arm devices ?

justwantin · 10-10-2014, 12:58 AM

I'm just guessing, however, the first thing I'd try would be using using [find] to see what if any file has changed in /proc after a button has been pressed or is being continuously pressed. I use a while loop a check if a gpio pin on my pi's goes low and if so then [shutdown -h now] is run. You could probably do the same if [find] can identify which file in /proc changes when a given button is pushed. Wouldn't matter which button, just which file. I once did a similar thing with my daughter's computer. Check the mouse status in /proc/interrupts if the mouse hasn't moved in a given period of time and she isn't watching a video, shut the box down.

louigi600 · 10-10-2014, 01:48 AM

Hum ... I don't think that works because also inotify fails to detect the changes on x86 when /proc/asound/card0/codec#0 changes. I'm not sure if it's a bug or something one should expect because /proc is not a real filesystem ... whatever if inotify does not detect change I doubt find will do either ... but I can give it a go anyway

Yeah the gpio thing would be my next try ... but on the xzpad700 there are no spare pons for GPIO: I'd haveto sacrifice CSI or LVDS but that's no big deal since the lcd is bust (thatnks to my son). But if it's possible to the the buttons that are already wired up to work it would really be the best thing.

justwantin · 10-10-2014, 02:19 AM

Quote:

Hum ... I don't think that works because also inotify fails to detect the changes on x86 when /proc/asound/card0/codec#0 changes.

Might be, and also volume controls might be attached to something on the board instead of interfacing with the system.

I don't know how often you'd be shutting it down so this might not be practical. Does that thing have a usb port? If so you could script the shutdown to be based on something being plugged in. Parse for a given device/hex number. I'd do that before I'd start playing with gpio pins.

louigi600 · 10-10-2014, 03:06 AM

Quote:

Might be, and also volume controls might be attached to something on the board instead of interfacing with the system

Whatever the buttons are attached to android manages the press events via h2r ... there must be a way on mainstream Linux too (just don't know how impervious the route may be).

Quote:

Does that thing have a usb port? If so you could script the shutdown to be based on something being plugged in. Parse for a given device/hex number. I'd do that before I'd start playing with gpio pins

The USB thing could probably be done all via udev without having to make any scripts or code ... but having lost the display it's going to do some sort of headless appliance job and it will probably use it's only USB port so it's a no go for me.
I just want a handy way to turn the thing off without crashing it or having to login to it. I might end up having it mounted readonly and not caring about crashing it (just like my dockstars).

justwantin · 10-10-2014, 04:24 AM

Ok, I see, only one usb port and its in use and ssh undesirable. I thought about udev but didn't want to go there. Without something to play with I'm no help but its a nice problem. If you start playing with the gpio pins watch out for the magic smoke.

Cheers!

mostlyharmless · 10-16-2014, 03:12 PM

Just an idea: I noticed that quite a few A10 support patches have been added to the kernel since kernel 3.10; perhaps compiling the latest version might have support for the button pushes.

louigi600 · 10-17-2014, 04:58 AM

Quote:

Originally Posted by mostlyharmless

Just an idea: I noticed that quite a few A10 support patches have been added to the kernel since kernel 3.10; perhaps compiling the latest version might have support for the button pushes.

Interesting thing but I think that there is a lot of stuff that is not making it to mainstream from linux-sunxi kernel.
I'm not sure what's making it and what not but it may be possible that mainstream kernel might be functional for headless systems: anyone had a go at using mainstream kernel on Allwinner SOC based systems ?

louigi600 · 10-20-2014, 03:39 PM

It appears that on my device the buttons ate interfaced via I2C ...

Code:

[pmu_para]
pmu_used = 1
pmu_twi_addr = 52
pmu_twi_id = 0

But I can't dump the status because 0x34 is in use

Code:

root@headless2:~# i2cdump -y 0 0x34
No size specified (using byte-data access)
Error: Could not set address to 0x34: Device or resource busy
root@headless2:~#

If it's in use it's I may just haveto find the right place in /sys to read the button status.