Hopefully it should be easy.
Could you help me to find a way to make a Jetson TX1 to awake by pressing the Power Key.
By default it wakes by keyboard pressing or mouse moving, but not by power key.
There is probably a way to do this, but with no mouse or keyboard, there may be better solutions. Are you just trying to get a graphical desktop to show up? The Jetson as a whole remains running even if it goes to a low power mode. In the case of a graphical display, you’d need to have someone logged in to the display before activity would matter…having activity trigger a login screen when there is no keyboard or mouse to log in with might be a problem.
So…what is the behavior you are looking for, e.g., is this something like a dedicated multimedia appliance? The nature of what you want it to do might change the answer.
I’m using L4T 23.2 is most stable one with fixed PCIe driver.
Now I have configured the Ubuntu with autologin and no locking screen. Finally I will replace a desktop manager with our own simple one.
We are planning to have only Power key as real button and LCD with CTP.
There are two scenarios:
System wide suspend and wake up
Wake just a graphical display after it goes into low power mode
I need a wake behavior bu touching CTP, like mouse.
In both scenarios keyboard and mouse work. But not a I2C CTP. I’m keeping a power on the CTP in suspended mode, so it should not be an issue.
I also saw that TS INT is a WAKE pin, but by default it has no effect. Perhaps I should configure a pin in special way, but I don’t know how.
I can’t answer this, but perhaps this information will help.
Keyboard and mouse on X11 uses the XInput API. When you read the “/var/log/Xorg.0.log”, you’ll see an ABI version for numerous things, one of which is the input extension. Mouse and keyboard are monitored by this extension. These extensions normally auto-configure and look for events from the proper classes of devices in “/dev/input/*”.
Since you don’t have a mouse or keyboard, what you basically need to do is somehow tell the XInput extension to watch for events from an alternate source, e.g., from a GPIO key. Someone may also know of whether the power button itself generates events which are exposed somewhere already, e.g., perhaps power button generates events somewhere in “/sys”. My hope would be that instead of auto-detect of event sources, perhaps you could manually configure one of these sources in the xorg.conf file. If not, you may need to create a mouse or keyboard proxy which pretends to be a real mouse or keyboard, and have it generate an entry in “/dev/input” which the server could pick up automatically (for something exposed in “/sys” you’d point to it manually).
I doubt it is what you want, but you could also just disable sleep in X11. The board as a whole could probably still be put into sleep/low-power mode.
My CTP is already configured as Xinput indeed.
Unfortunately, I was not able to make events from CTP to wake X11.
I have to allow power saving modes because I’m running on the battery…
System suspend is another story at all. I can see that USB mouse can wake the system, but not I2C CTP…
Since I added a backlight to the device tree the “Bright & Lock” system settings panel had a Dim screen to save power option. With this option (even it is not activated) systems turns off even HDMI display. It cannot fully awake after power key pressed. It turns on, but stay black until mouse movement or keyboard pressing…
Moreover sometimes system ignore power key at all, but mouse or keyboard never.
Hello, Alex_Sharapov:
Would you please use a Jetson TX1 board by R24.1 image, with HDMI attached, to test this issue first?
In ‘All Settings’ → ‘Brightness & Lock’, with ‘Dim screen to save power’ checked, and ‘Turn screen off when inactive for: 1 minute’. After a while, HDMI will turn off, and console shows:
I’ll guess that the power key is not being treated as a human interface device (that key is not USB so it would make sense that it never touches that driver), and thus events generated are only handled by some specific driver which never passes the event to any other part of the system (include XInput extension to X11). Typically for an input device to unblank X11 (versus doing something with system suspend mode…it is possible to wake from suspend and still have X11 sleep or power save) the device has to be configured in X11 to be a pointer or input device of that screen.
As I wrote before, HDMI display is waking up by pressing a power key!
But when MIPI DSI display is also connected something changes and power key loose such effect… :(
This way I believe it is possible to enforce power key pressing treat as wake, but I have no idea how…
It is possible that the code in the HDMI wake is catching the event and not passing it along. There is also the corollary, that the event is passed along but the MIPI DSI is ignoring the event. This latter would be normal operation for any event producing device which is not configured in the xorg.conf to be of interest.
Are both displays configured to mirror the same session? Or are the sessions independent? Assuming the sessions are mirrors (meaning a single session on two displays) it would make sense that HDMI wake is catching the event and not passing it down to MIPI DSI. If the two displays are independent, then it would be consistent with an xorg.conf configuration issue (in which case the MIPI DSI needs to be told that the input device is to be associated).
It looks like the power button is mapped in R24.2 kernel file “drivers/pinctrl/pinctrl-tegra210.c” by this GPIO line:
#define TEGRA_PIN_BUTTON_POWER_ON_PX5 _GPIO(189)
On the JTX1 carrier board this goes to module pin B50, label “POWER_BTN”. I would have expected this pin to be dedicated to power without GPIO function option (I would have expected SFIO…something has set up this pin for use with power before the boot loader itself has been installed…perhaps it is in tboot where this is initially configured for use).
Looking at “/sys/kernel/debug/gpio” I see:
gpio-189 (Power ) in hi
So apparently if a change of state in this pin can be monitored on a running Jetson, then that state change could be used to create a “/dev/input/event#” useful with xorg.conf or input events in general (the original function would not have to change at all). I have not traced the path of where gpio-189 is used, but making this pin’s events useful without intruding on anything else should be possible by tracing down the actual code triggered by this GPIO and mirroring changes to “/dev” (the file could be rw, but for these purposes the file could simplify and be read-only). Obviously the power on itself is monitored by software, but a “/dev/input/event#” file to mirror power button press events would allow a very simple and powerful way to develop software which uses only standard input device code which has no knowledge of power state code.
You are right, the power button is not only a special pin, but also GPIO.
I’m afraid that L4T already uses some mechanisms for capturing events from this pin (system turns on a sleeping HDMI display after pressing the pwr btn) and using it twice we have a chance to cause a collision…
So, from my point of view the best way is to understand how X11 handing power key pressing when only HDMI display is connected…
Perhaps, I should trace an X11 to find a handler, but actually I cannot do at the moment…