OESF Portables Forum
Model Specific Forums => Gemini PDA => Gemini PDA - Linux => Topic started by: psionlover on June 29, 2018, 01:56:16 pm
-
I tested quite a few times now, but if I leave the device in suspend mode overnight it still drains the battery with 2% / hour. I made sure that wifi and bluetooth both where off. I am very curious what other people's experiences on this are. Adam Boardman wrote anywhere that he experiences 2% drain on a full night. What can I do to achieve a better power management on my device ?
[Update]
If I do suspend via the menu 'Start/Leave/Suspend' I get a subscreen asking
Do you want really to suspend your computer?
Suspends the computer into a low power state. System state is not preserved isf the power is lostWhen I confirm this the screen turns black. I can reactivate the screen by pressing Esc. I then get a wordmap with yellow bubbles. While I write my password I get a green circle in the middle turning red if I type wrong and blue if I type right. It finally brings me back to the desktop. Desktops opens with a subscreen message
An error occurred starting screensaver. Action 'activate' faild. Ensure you haave xscreensaver installed and running.After I confirmed desktop works fine again.
I presume the 'suspend' of my system is a real 'suspend' but I don't know for sure. How can I know if suspend really suspends ?
-
Does anyone have suspend actually working on Debian? From my experience, when the device enters actual suspend (no wakelocks and lid closed, or mem /sys/power/state) it gets stuck and cannot be woken again (i.e. black screen on opening lid, completely unresponsive to any keys)
Without proper suspend, the best we can do is SIGSTOP user processes but it still drains battery, in my experience even worse than 2% an hour
I'm waiting on stuff to arrive to build a serial console cable to try and find out exactly why it's freezing in suspend
-
Does anyone have suspend actually working on Debian? From my experience, when the device enters actual suspend (no wakelocks and lid closed, or mem /sys/power/state) it gets stuck and cannot be woken again (i.e. black screen on opening lid, completely unresponsive to any keys)
Without proper suspend, the best we can do is SIGSTOP user processes but it still drains battery, in my experience even worse than 2% an hour
I'm waiting on stuff to arrive to build a serial console cable to try and find out exactly why it's freezing in suspend
If I do 'suspend' I (mostly) don't get a hang or crash but a black screen which I can activate again. But I deinstalled xscreensaver because I realized it (mostly) helps preventing hangs. I updated my post with this information.
-
Does anyone have suspend actually working on Debian? From my experience, when the device enters actual suspend (no wakelocks and lid closed, or mem /sys/power/state) it gets stuck and cannot be woken again (i.e. black screen on opening lid, completely unresponsive to any keys)
Without proper suspend, the best we can do is SIGSTOP user processes but it still drains battery, in my experience even worse than 2% an hour
I'm waiting on stuff to arrive to build a serial console cable to try and find out exactly why it's freezing in suspend
If I do 'suspend' I (mostly) don't get a hang or crash but a black screen which I can activate again. But I deinstalled xscreensaver because I realized it (mostly) helps preventing hangs. I updated my post with this information.
I think you're right that xscreensaver seems to be responsible, but I'm still seeing some identical freezes when left for an extended period in suspend with the stock repowerd/gemian-lock
-
Does anyone have suspend actually working on Debian? From my experience, when the device enters actual suspend (no wakelocks and lid closed, or mem /sys/power/state) it gets stuck and cannot be woken again (i.e. black screen on opening lid, completely unresponsive to any keys)
Without proper suspend, the best we can do is SIGSTOP user processes but it still drains battery, in my experience even worse than 2% an hour
I'm waiting on stuff to arrive to build a serial console cable to try and find out exactly why it's freezing in suspend
If I do 'suspend' I (mostly) don't get a hang or crash but a black screen which I can activate again. But I deinstalled xscreensaver because I realized it (mostly) helps preventing hangs. I updated my post with this information.
I think you're right that xscreensaver seems to be responsible, but I'm still seeing some identical freezes when left for an extended period in suspend with the stock repowerd/gemian-lock
My main question now does it really 'suspend' if I give it command to suspend (when it not hangs). If it does suspend why the power drain of 2% / hour ? Is there a way I can check ?
-
Does anyone have suspend actually working on Debian? From my experience, when the device enters actual suspend (no wakelocks and lid closed, or mem /sys/power/state) it gets stuck and cannot be woken again (i.e. black screen on opening lid, completely unresponsive to any keys)
Without proper suspend, the best we can do is SIGSTOP user processes but it still drains battery, in my experience even worse than 2% an hour
I'm waiting on stuff to arrive to build a serial console cable to try and find out exactly why it's freezing in suspend
If I do 'suspend' I (mostly) don't get a hang or crash but a black screen which I can activate again. But I deinstalled xscreensaver because I realized it (mostly) helps preventing hangs. I updated my post with this information.
I think you're right that xscreensaver seems to be responsible, but I'm still seeing some identical freezes when left for an extended period in suspend with the stock repowerd/gemian-lock
My main question now does it really 'suspend' if I give it command to suspend (when it not hangs). If it does suspend why the power drain of 2% / hour ? Is there a way I can check ?
I'm seeing a lot of CPU time on systemd-logind, polkitd and dbus-daemon so something is getting stuck in a loop while suspended
Edit: Yeah...
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:39 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:40 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
Jun 29 20:54:41 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(2,/org/freedesktop/login1/session/_32,21)
Jun 29 20:54:42 gemini repowerd[5110]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(,/,21)
Jun 29 20:54:42 gemini repowerd[5110]: LogindSessionTracker: deactivate_session(1)
-
Just for the record. Today I have not used my Gemini until now. Its battery drained by 14% (from 100% to 86%) within 12 hours with WiFi+BT enabled and cellular off. Less than 1,2% per hour.
Edit: Just found out that it is not pingable with the lid closed, so WiFi might be off, despite the LED glowing. Maybe the LED is the consumer here...
-
Just for the record. Today I have not used my Gemini until now. Its battery drained by 14% (from 100% to 86%) within 12 hours with WiFi+BT enabled and cellular off. Less than 1,2% per hour.
Thanks, bit better than mine but in the same range.
[Update]
Oops missed that you had wifi+BT enabled, in that case you have much better PM. Would you please check your drain if you suspend with wifi+BT turned off ?
@Kiriririn: I presume this is output of /var/log/repowerd.log ?
I just did a few (successfull, no hangs) suspends (both manual and by idle lock in powermanagement) and checked the resulting input in repowerd.log. It did not lead to any input in repowerd.log at all. Does did mean that my suspends have been successfull or does it mean something different. I also just had one hang and after I rebooted There was input in repowerd.log but it does not suggest me something sticks in a loop
....
2018-06-29T21:00:17.247164+00:00 geminiPDA repowerd[698]: UPowerPowerSourceAndLid: change_device(/org/freedesktop/UPower/devices/DisplayDevice), type=battery, is_present=1, state=charging, percentage=93.00, temperature=0.00
2018-06-29T21:11:32.481693+00:00 geminiPDA repowerd[698]: UPowerPowerSourceAndLid: change_device(/org/freedesktop/UPower/devices/battery_battery), type=battery, is_present=1, state=charging, percentage=93.00, temperature=0.00
2018-06-29T21:12:42.481144+00:00 geminiPDA repowerd[698]: UPowerPowerSourceAndLid: change_device(/org/freedesktop/UPower/devices/battery_battery), type=battery, is_present=1, state=charging, percentage=93.00, temperature=0.00
2018-06-29T21:13:33.460994+00:00 geminiPDA repowerd[698]: LogindSessionTracker: change_seat_properties(/org/freedesktop/login1/seat/seat0), ActiveSession=(6,/org/freedesktop/login1/session/_36,21)
2018-06-29T21:13:33.462365+00:00 geminiPDA repowerd[698]: LogindSessionTracker: track_session(6), type=x11
2018-06-29T21:13:33.463196+00:00 geminiPDA repowerd[698]: LogindSessionTracker: activate_session(6)
2018-06-29T21:13:33.464015+00:00 geminiPDA repowerd[698]: Daemon: handle_session_activated - incompat: 0
2018-06-29T21:13:33.464726+00:00 geminiPDA repowerd[698]: DefaultStateMachineFactory: create_state_machine - DefaultStateMachine - 6
.....
-
I think I've just had a successful suspend by disabling part of the LogindSessionTracker and also adding a script to disable wifi via networkmanager before sleeping (my hacks are here (https://github.com/lukefor/repowerd)), at least in terms of not losing any battery % at all over 30 mins and no increase in process CPU times from when I closed the lid
You can identify a proper suspend by some of the log info printed by the kernel in dmesg (though unmodified kernel is hilariously verbose and it's difficult to pick apart), or also by the fact that the device will be completely cool to the touch (burning 2% an hour produces faint heat)
-
I think I've just had a successful suspend by disabling part of the LogindSessionTracker and also adding a script to disable wifi via networkmanager before sleeping (my hacks are here (https://github.com/lukefor/repowerd)), at least in terms of not losing any battery % at all over 30 mins and no increase in process CPU times from when I closed the lid
Thanks. I have no clue what to do with those scripts. Does it mean I have to rebuild my own kernel to have them implemented ? Any hint on where to begin with that are welcome.
You can identify a proper suspend by some of the log info printed by the kernel in dmesg (though unmodified kernel is hilariously verbose and it's difficult to pick apart), or also by the fact that the device will be completely cool to the touch (burning 2% an hour produces faint heat)
I looked into dmesg and I can't make something sensible out of it I did not feel any noticeable warmth on the device if it is in sleep mode. That said when it is powered on usb I don't feel any noticeable warmth either.
I have been fiddling with the geminiPDA for the whole week now. My conclusion so far is that I can't use it right now for daily use, even not with the very limited goals I had set for myself:
- good power management so that I can be off the socket for at least 4 days.
- music player. sound is fine for me, but if I hook a headset sound on the speakers is not turned off.
- camera not implemented yet.
Things I did already fiddled enough and that would fit the job for me for now are:
- automatic syncing my data stuff with my pc
- thunderbird for contacts, tasks, calendar. just works fine on the device if you remove as many screens and taskbars as possible. it syncs nice with my home pc.
- wikidpad for my personal notes taker. works fine and syncs nice with my wikidpad on my pc.
- gvim for other editing stuff and note taking.
So the device goes back in it's box again, but I will return regularly to test new gemian versions. But my hope to finally carry my own privacy secure device with me is tempered right now. Android is no option for me, no big brothers watching me over my shoulder
-
So something I changed has fixed it! Just left the gemini overnight with a load of applications running and it only dropped 1% and didn't freeze!
I suspect it is the logind dbus removal that did it, but that isn't a totally harmless change as I now have to restart repowerd on login. Needs more investigation...
I also removed power button/esc key handling from gemian-lock - this seems to be one of the reasons that can freeze the gemini in suspend similar to xscreensaver
-
Quick data point: with wifi off, and screensaver disabled (I do not want to keep typing my password every time), my system was at 87% battery last night. Closed lid and went to sleep. Work up, opened system and battery was at 85%.
-
@Kiriririn really appreciate your efforts.
Quick data point: with wifi off, and screensaver disabled (I do not want to keep typing my password every time), my system was at 87% battery last night. Closed lid and went to sleep. Work up, opened system and battery was at 85%.
That sounds promising. Please do a few more checks and tell us if the results are consistent. I presume your device goes in suspend mode (not shutdown) when you close the lid ?
-
The system seems to simply turn off the screen as there are messages in /var/log/syslog throughout the night. The screen reawakens immediately on opening the lid. The battery is now 83%, 6 hours after getting up.
-
The system seems to simply turn off the screen as there are messages in /var/log/syslog throughout the night. The screen reawakens immediately on opening the lid. The battery is now 83%, 6 hours after getting up.
Same experiences here. I can also still ssh from outside to the device and do all kinds of stuff on it while the device is in 'suspend'. That is why I already asked myself is the device really suspended if I do 'suspend'. What does 'suspend' mean anyway ?
But I don't care what suspend means if I would have your version of sleep/suspend/lock on my device and have 2% drain in 6 hours I would be very satisfied. So please find out what you did to get your 0.3% drain / hour and share here
-
Interesting work, I look forward to seeing the final result.
One of the aims of the gemian-lock is to eat key presses that happen when the device is closed due to the fact that the device squashes its keyboard. These are of course more likely when the device is on, but as the esc key is an 'on' key that can happen whilst its closed, or if a call comes in etc.
My thoughts were that those that don't want to be typing their password all the time would add a config setting to turn on/off the password feature within gemian-lock whilst still keeping its other purposes (eg stray key eating, call answering, voice assistant - currently simulated with 'saytime' until such features are added).
For the no-password mode the lock screen would then only unlock on key-presses when the device is open.
In my initial testing I found that closing the device slowly with a terminal open would give me a few lines of key-presses sometimes but also other times it would give me no key-presses. Testing was done with the initial x25 keyboard mat.
-
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
-
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
I just realized @mithrandir also has much better PM, because he has 1.2% drain ph with wifi+BT turned on. So probably my device with poor PM is the special case not yours So I will also check again.
[Edit] I checked two times (unhook device from usb, wifi/BT off, suspend) and both times I had roughly 2% drain ph. No clue why, but if I have more info I will update
-
It will be interesting to see if there is anything special you are doing to have such significantly worse power drain. Keep us posted!
-
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
I just realized @mithrandir also has much better PM, because he has 1.2% drain ph with wifi+BT turned on. So probably my device with poor PM is the special case not yours So I will also check again.
Today it has been different. Same situation as yesterday. 12 hours without use after pulling the plug, but only 2% drain (0.17% per hour).
-
Awesome @psiolover, @Kiriririn, @Eric and other posters here
I'll be joining your efforts as soon as I can make my Gemini boots into Debian (boot #3 here, that should come out when pressing Esc+Side-key on start up)
-
I tested quite a few times now, but if I leave the device in suspend mode overnight it still drains the battery with 2% / hour. I made sure that wifi and bluetooth both where off. I am very curious what other people's experiences on this are. Adam Boardman wrote anywhere that he experiences 2% drain on a full night. What can I do to achieve a better power management on my device
Sorry not knowledgeable enough to contribute ot the Linux threads, but for interest - over on planet android I am getting 4.5% per HOUR with the rooted image on a WiFi only device
https://www.oesf.org/forum/index.php?showtopic=35323 (https://www.oesf.org/forum/index.php?showtopic=35323)
From memory the stock image was a lot lot less than this
-
here are the battery stats on my Gemini with Debian TP2 and system defaults:
| Action | Test duration | % battery used | ~per hour | battery life estimation |
|--------------------|--------------:|---------------:|----------:|------------------------:|
| lxqt suspend | 10:00 | 10 | 1 | 100h |
| lxqt suspend | 1:00 | 1 | 1 | 100h |
| constant light use | 2:30 | 23 | 9 | 11h |
After reading Rubus post above I'll have to check this on my new rooted Android.
-
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
-
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
Thanks. Could you specify if you had wifi/BT off or not. If you did not have wifi/BT off would you please do another check with wifi/BT off ?
[update] just changed a typo
-
I have wifi off and disabled the bluetooth service
-
Looking at this thread we have quite different "suspend" happening here (bold and a couple links added by me).
with wifi off, and screensaver disabled (I do not want to keep typing my password every time), my system was at 87% battery last night. Closed lid and went to sleep. Work up, opened system and battery was at 85%.
---
The system seems to simply turn off the screen as there are messages in /var/log/syslog throughout the night. The screen reawakens immediately on opening the lid. The battery is now 83%, 6 hours after getting up.
Same experiences here. I can also still ssh from outside to the device and do all kinds of stuff on it while the device is in 'suspend'. That is why I already asked myself is the device really suspended if I do 'suspend'. What does 'suspend' mean anyway ?
But I don't care what suspend means if I would have your version of sleep/suspend/lock on my device and have 2% drain in 6 hours I would be very satisfied. So please find out what you did to get your 0.3% drain / hour and share here
You can identify a proper suspend by some of the log info printed by the kernel in dmesg (though unmodified kernel is hilariously verbose and it's difficult to pick apart), or also by the fact that the device will be completely cool to the touch (burning 2% an hour produces faint heat)
I think I've just had a successful suspend by disabling part of the LogindSessionTracker and also adding a script to disable wifi via networkmanager before sleeping (my hacks are here (https://github.com/lukefor/repowerd)), at least in terms of not losing any battery % at all over 30 mins and no increase in process CPU times from when I closed the lid
---
So something I changed has fixed it! Just left the gemini overnight with a load of applications running and it only dropped 1% and didn't freeze!
I suspect it is the logind dbus removal that did it, but that isn't a totally harmless change as I now have to restart repowerd on login. Needs more investigation...
I also removed power button/esc key handling from gemian-lock (https://github.com/gemian/gemini-keyboard-apps/wiki/DebianTP2#sleep-on-close) - this seems to be one of the reasons that can freeze the gemini in suspend similar to xscreensaver
One of the aims of the gemian-lock (https://github.com/gemian/gemini-keyboard-apps/wiki/DebianTP2#sleep-on-close) is to eat key presses that happen when the device is closed due to the fact that the device squashes its keyboard. (...)
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
Please check these links:
- Suspend and hibernate (Arch linux wiki) (https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate)
- How to read the linux journal (systemd, Arch linux wiki) (https://wiki.archlinux.org/index.php/Systemd#Journal)
Continuing testing on Gemini WiFi (MediateK X27) with default LxQt here, I've had both succesfull and aborted suspend happen. With respectfully:
1. Very low battery drain (<1% / hour) and log activity;
2. High battery drain (~5% / hour) and log activity.
Am trying to check how to reproduce both cases. Will report ASAP.
I know the hardware is fine, as I can get ~0.5%/hour drain in (rooted) Android.