You need more cat /sys/class/... to look at the actual current flow with the battery, rather than the option negotiated with the (potential) power source (over USB).
e.g. cat /sys/class/power_supply/max170xx_battery/current_now
should be negative if discharging.
It is negative, so it is discharging.
purism@johan-librem5 ~ $ cat /sys/class/power_supply/max170xx_battery/current_now
-145283
Thanks for the tip. After some more investigation it seems like the dock is providing less power than the phone is consuming, so it’s technically true that the battery is discharging (at the same time as it is being charged).
When having the “Power” section open in Settings, it jumps for 4-5 hours expected battery life to 6-10 hours when I plug in the dock. I also found gnome-power-manager which clearly states that while the battery is in “discharge” mode, the “AC adapter” has “Online” set to “yes” when the dock gets plugged in. So I guess that phosh and the battery icon probably just looks at the battery “state” which is “discharging”, which was the only thing that confused me (also the fact that i saw 6-7 hours estimated battery life when plugged in the first few times when I looked at the battery stats, which is what I’d expect from a phone when it’s not plugged in…). I’d prefer if phosh looked at if the charger was “online” rather than if the battery is discharging, would make more sense to me.
Hey Kyle I asked this in the other dock thread, but I noticed with my Nexdock that if I have my samsung connected, even if the phone and dock screen go into screen saver mode the phone continues to charge and the screen can awaken with mouse/keyboard.
With the Librem 5 once it blanks, shortly thereafter the nexdoc shuts down completely and can only be woken with the power button and as a result is also not charging the phone. I discovered this when I left the L5 connected to it thinking it would continue to charge but it just drained as if it was not plugged in. Is this a hardware issue or is it a driver/kernel/whatever issue?
I suspect when the L5 screen blanks it disables not only its own display (to save power) but any displays it is connected to, so the Nexdock thinks it has been disconnected and starts the timer for shutdown.
I personally have automatic blank screen disabled on my own L5, but I do have “Dim Screen When Inactive” enabled.
Ah ok good tip I’ll give that a try. I guess I can turn off the screen manually with the power button.
Another useful thing is to turn off the phone screen and use only the dock one while plugged, I was trying to do it nicely for a while, you can see the discussion here Initial Librem5/Nexdock360 impression but now I just created a .desktop file that calls a script to disable the phone display when open using wlr-randr --output DSI-1 --off then to go back to the phone I just unplug it and it crash and reload phosh to the phone display, not ideal but it works.
Interesting. I am also looking for a way to easily use the lapdock screen as the main screen and turn the phone screen off when I don’t need it. Doing this through gnome-settings is rather cumbersome.
I have noticed when you do this and unplug the phone it does tend to crash. I should inspect the logs to see what’s going on when this happens.
I’d agree that would be important for any setup there not to skip this:
That’s why here linking specifications (again and as orientation) of the one (length is important usage consideration as well) that @Kyle_Rankin already recommended (while it works): https://www.dockcase.com/category/cables.
EDIT: @johan-bjareholt, how about connecting there and powering Librem 5 through REVOXEN − twin USB-C bi-directional switcher?
That is what I said on my comment, my plan was to create a udev rule so every time the nexdock is connected or disconnected it will trigger a script but I couldn’t manage, so I’m just doing it like that by the time being.
So, I finally received my UPERFECT lapdock.
Things mostly work but I’m a bit puzzled about the touch screen as it seems to work for everyone after enabling in the mobile settings…
But here it doesn’t! Touching the screen will trigger the corresponding point on the phone screen. Basically what @Altor said in that post but for another device: when I touch the right side of the lapdock screen it’s as if I touched the right side of the phone screen, if the left of the lapdock screen then the left of the phone screen, and so on. Dragging a finger on the lapdock screen will scroll whatever is on the phone screen.
What does that mobile-settings option do? I don’t see any difference when I enable it or not. Can I somehow configure that by hand? What is the gsetting command that @Kyle_Rankin mentioned?
So in the PureOS Mobile Settings application under convergence you have map built in touch screen enabled?
I will update my initial post. Unfortunately, I can’t open an issue on the git to update mobile setting.
for me, the working gsetting command is
gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/2d1f:524c/ output “[‘Lenovo Group Limited’,‘M14t’,‘V307G6CZ’]”
the touchscreens identification (in my case 2d1…) is found thanks to lsubs (here aftter my output line)
Bus 003 Device 004: ID 2d1f:524c Wacom Taiwan Information Co. Ltd. Pen and multitouch sensor
and the output ([’Lenov…]) is found thanks to journalctl -b 0 _COMM=phoc and then search for Output ‘DP-1’
Output ‘DP-1’ added (‘Lenovo Group Limited’/‘M14t’/‘V307G6CZ’)
just change the / by , in the gsetting command.
Awesome! Thank you @Altor that works. (I’m wondering how you found out how to do all that)
Actually I don’t have the mini, I guess that’s why it wasn’t working (I wanted the mini but it wasn’t in stock so they sent me another one, not sure which model exactly). Maybe mobile settings detects a uperfect something and tries to configure the touchpad of the mini and it doesn’t because it’s not the same ids…
This is the command I ran:
gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/27c0:0819/ output "['Unknown','uperfect','8R33926O00QS']"
I finally got around to learning how udev works and using that to switch off the phone screen when the lapdock is connected.
apt install wlr-randr to be able to change screen configuration from scriptslsusb to trigger the rule. I used this line from the output: Bus 003 Device 004: ID 27c0:0819 Cadwell Laboratories, Inc. WingCoolTouch, i.e. the lapdock touch screen./etc/udev/rules.d/99-lapdock-then-phone-screen-off.rules with following contents:ACTION=="add" \
, ATTRS{idVendor}=="27c0" \
, ATTRS{idProduct}=="0819" \
, ENV{XDG_RUNTIME_DIR}="/run/user/1000" \
, RUN+="/usr/bin/wlr-randr --output DSI-1 --off"
Adapt the vendor and product id to what you found in lsusb if you don’t have the same model as me, and the RUN+= lines if you want to do other stuff when the lapdock is connected.
Hope this helps!
I would bring to other readers’ attention though the following caveats from the man page
This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.
So for any command that you choose to run, you should consider a) how long it would take to execute under normal circumstances, and b) whether there are any abnormal circumstances under which the command would block.
Also
Note that running programs that access the network or mount/unmount filesystems is not allowed inside of udev rules, due to the default sandbox that is enforced on systemd-udevd.service.
(Accessing the network would in many circumstances violate the first quoted paragraph anyway.)
and
Starting daemons or other long-running processes is not allowed; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using the SYSTEMD_WANTS device property. See systemd.device(5) for details.
None of this necessarily applies to the one specific command that you have chosen but other readers may be tempted to get creative ;-), since you invite them to do so, in which case a service is probably a better approach.
I finally got around to trying out my UPERFECT lapdock with my Librem 5.
Is it my imagination or are the left and right audio channels reversed? Does this happen with all sound output from the Librem 5? All sound output via HDMI from the Librem 5? No, Irvine, it’s your imagination?
I normally output sound via a pair of cordless speakers that connect to the Librem 5 via Bluetooth, which means “left” and “right” are meaningless (for two reasons - the speakers can be moved around anywhere, and the way the speakers are “paired” to each other it seems to me results in “left” and “right” being random anyway).
More concerningly, while playing music, the USB-C video seemed to drop out intermittently, frequently enough to be a problem. Without music playing, the video was rock solid. ??? Anyone else seeing this?
Otherwise it seems like a nice combination that works well as a “laptop”.
The gsettings command to make the touchscreen work seems completely inconsistent between UPERFECT models, which is a bit weird and not very helpful. But anyway the touchscreen works fine.
I’m not a fan of touchpads so I also tried out a mini-mouse in the spare USB port on the lapdock. That gives 3 pointing devices (touchpad, touchscreen and mouse). I’m undecided on whether a mouse will be needed for my usage.
PS Oh and of course there’s the known problem that the UPERFECT seemingly doesn’t have enough power to keep both itself and the Librem 5 charged. The supplied USB-C power supply is 30W (max.). Has anyone tried something with more juice?
Looks like this hasn’t been fixed yet. I received 12,000-odd journal entries of this nature from a handful of hours of use. This can’t be good for time-on-battery.
Thanks for the info @irvinewade , that’s really helpful. On a side note, however, that reeks of the kind of thing that drove me (as a programmer) away from Android: things that should work but don’t because Android decided my app takes or requests too much resources, and the app either gets silently killed/suspended, or the request (to run periodic tasks or whatever) gets simply ignored. Even though it’s an app I wrote myself for my own use on my own device. (See https://dontkillmyapp.com/) (Then there’s another new new API to do what could already be expressed in the former API, but it still doesn’t work in some cases for obscure reasons). Still less extreme because we can still find a way to do what we want but I don’t like it.
</side note/rant>
In this case, the justification is, I think, simpler than that. The restrictions exist largely because the command executes synchronously. (There may be some security considerations too.)