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.
My target system does not have keyboard or mouse…
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.
Thank you for your contribution!
Some more details from my side:
- 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 would appreciate your help!
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.
Thank you again!
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…
So, the question is still open for me.
Can you share your steps how to put TX1 in sleep mode?
when long-pressing power key, shutdown/reboot/xxx dialog will popup.
I can light-on LCD with power key after ubuntu turns off screen.
Thank you for your reply.
First of all I should describe my system:
- I’m staying on L4T 23.2 (because it is more or less stable for my application)
- I’m using MIPI DSI LCD ()
- Set Turn screen off when inactive for: 1 min
- Wait until the screen turns off (backlight off)
- Press power key
When we are talking about HDMI display, please note, system just draw a black rectangle, but not turns a display off at all!
- Suspend system
- Try to wake up (keyboard and mouse works, but not power key of touchscreen)
I’ve checked more and found:
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.
In case of MIPI DSI LCD power key works never…
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:
tegradc tegradc.0: blank - powerdown
with power-key pressed, console shows:
[ 740.245184] tegradc tegradc.0: unblank
[ 740.322672] tegradc tegradc.0: nominal-pclk:3333000 parent:9998987 div:3.0 pclk:3332995 3299670~3632970
[ 740.386258] tegra_mipi_cal 700e3000.mipical: Mipi cal timeout,val:10016eb0, lanes:30000000
[ 740.428661] tegradc tegradc.1: unblank
[ 740.434951] tegradc tegradc.1: nominal-pclk:148500000 parent:148500000 div:1.0 pclk:148500000 147015000~161865000
and desktop comes back normally.
Please clarify this first. And then check DSI LCD issue.
I’ve checked it on 23.2
As I said it works with HDMI
I cannot check 24.1 with MIPI DSI LCD due to system failure.
Moreover, system cannot wake from system suspend by pressing the power key at all.
Finally I’ve successfully moved onto r24.2.
DSI LCD is working on this version.
But, power key is not unblanking neither DSI LCD nor HDMI when DSILCD is connected…
[ 1905.496899] tegradc tegradc.0: blank - powerdown
[ 1905.582382] tegradc tegradc.1: blank - powerdown
Pressing the button changes nothing. But USB kbd or mouse does.
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).
Perhaps you are right. It would be nice to know how and where to catch such events…
The power key doesn’t have any /dev/event* nodes…
Unfortunately xorg cannot work as a mirror with my DSI display due to portrait normal orientation 720x1280.
It fails during setting up a mirror…
This way, I can use only DSI as a primary and HDMI as a secondary display.
Moreover, I’m using HDMI for debug purposes only. My target device doesn’t have an HDMI at all…
What is your xorg.conf configuration? I’d be curious if there is any XInput or keyboard/pointer configuration.
# Disable extensions not useful on Tegra.
Option "omit xfree86-dga"
# Allow X server to be started even if no display devices are connected.
Option "AllowEmptyInitialConfiguration" "true"
Option "SwapAxes" "1"
Option "InvertX" "true"
Option "InvertY" "true"
But default config works the same way
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…