Import contacts from VCF file
Syncevolution has been removed from upstream Debian, in the meantime it is straightforward to import contacts from a VCF file via Evolution tooling. First install evolution:
Code:
sudo apt install evolution
Before you import the file you will need to set scale-to-fit for Evolution on, otherwise the import dialog page is unusable.
Code:
scale-to-fit Evolution on
After this I opened the .vcf file via the Files app, it auto-launched the import dialoug. After importing I removed the Evolution app, this step is optional:
My Pine phone (UBPorts) has been in California "on its way to USPS" for a week. How long do they normally sit before getting onto the mail truck?
"Additional Information
A shipping label has been prepared for your item at 4:18 pm on July 9, 2020 in COMPTON, CA 90220. This does not indicate receipt by the USPS or the actual mailing date."
I successfully started a Debian 10 ARM64 rootfs + initrd, preinstalled using QEMU with LXDE and autologin. For a touch screen this is not easy to use, but I expect using keyboard and mouse soon
Using the 5.6.0-pine64 kernel which was provided with Ubuntu at delivery few weeks ago, having included the 5.6.0-pine64 modules into the debian's initrd, and having the "fstab" file corrected into rootfs, it boots fine. I customised the U-Boot boot script too.
However, I tried to do the same with a 5.8.0-rc5 kernel, using the config-5.6.0-pine64 as .config file for building the 5.8.0-rc5 kernel.
But I have no screen. I tried disabling "Enable loadable module support" so that every driver is embedded/preloaded into the kernel, but nothing more.
When comparing resulting .config, the following lines are missing after having 5.8.0-rc5 kernel built :
I've received my Pinephone some days ago. First it did boot fine, but not anymore...
When I press the power-on button this does not work always (not sure how long I should press on the button), but if I try it a few times the phone starts.
I see the LED's and the Pine64 logo. Then I hear a soft "click" sound and the phone is off again.
Is here somebody who knows what this click-sound can be?
Is there a way to access the hardware sensors for temperatures and voltages through the sensors command? Has anyone mapped things to a /etc/sensors.d/rockpro64 file? I can rename the virtual adaptor temps but power management reads out all zeros.
I've got the power adapter plugged in, but the battery still heads toward zero.
Admittedly, I'm compiling Haskell, so it's not a typical workload.
But still, it'd be nice to power up enough to keep from going to sleep mid-compile.
Any recommendations? I've already fiddled with NVMe settings and turned the brightness down. Can the PBP accept more power from an after-market adapter?
After months of running steady through multiple reboots and sudden power failures, all my boards suddenly lost eth0; all simultaneously; all while powered on and otherwise running without issue. No, I was not logged in and doing things with the system at the time. My router alerted me when the connections dropped out.
Things I tried (and failed):
different ports on ethernet switch
power cycling (hard reboot)
hook up monitor and keyboard and investigate
Investigation discovered no eth0 device. dmesg reports no driver.
lshw is not present on system so I cannot probe hardware and maybe get driver working with modprobe.
So I reflashed the OS and ... no network. dmesg reports no driver.
So I flashed a differnt OS -- Armbian Bionic 20.05.2 (kernel 5.4) -- and ... no network. dmesg output below.
Code:
dwmac-sun8i 1c30000.ethernet: IRQ eth_wake_irq not found
dwmac-sun8i 1c30000.ethernet: IRQ eth_lpi not found
dwmac-sun8i 1c30000.ethernet: PTP uses main clock
dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 2001 (expect 0)
dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
dwmac-sun8i 1c30000.ethernet: COE Type 2
dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
dwmac-sun8i 1c30000.ethernet: Normal descriptors
dwmac-sun8i 1c30000.ethernet: Chain mode enabled
...
dwmac-sun8i 1c30000.ethernet: EMAC reset timeout
dwmac-sun8i 1c30000.ethernet eth0: stmmac_dvr_remove: removing driver
dwmac-sun8i: probe of 1c30000.ethernet failed with error -14
First of all a disclaimer; I haven't had a chance to test this on the latest version of Mobian yet.
This will be a quick post about an issue I've discovered but I don't have the time to investigate it (I'll be quite busy in the next few days). Hopefully my research still helps someone.
I managed to capture this in dmesg when it happened (I got lucky and had an SSH session going):
Code:
[ 7251.715549] [drm:lima_sched_timedout_job] *ERROR* lima job timeout
[ 7252.962247] lima 1c40000.gpu: fail to save task state from phoc pid 1663: error task list is full
[ 7252.971463] lima 1c40000.gpu: gp task error int_state=0 status=0
So it looks like the GPU either stalls or falls out of sync with the lima driver for whatever reason. I do suspect it has something to do with power delivery because the same issue won't happen if I do this:
Code:
echo powersave | sudo tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
The most reliable way I've found to trigger the bug on my phone is do start downloading something big over LTE with wget. After somewhere between a few hundred MB and a GB you will notice the scrolling test going back and forth and you stop being able to interact with the phone through the touch screen.
At first I thought it was a hard crash and the power button only kept working through some weird quirk of interrupts offloaded from the main CPU, but as it turns out the rest of the system is fully functional. You can even recover most of the system (GUI tasks will be killed) by issuing this command:
Code:
sudo systemctl restart phosh.service
This should bring back the lock screen as if the system was freshly booted, but any non-GUI tasks are still running as if nothing happened.
That's about as far as I've been able to work things out so far. I think the appropriate thing to do here is to test the hack from the lima issue tracker (raising the scheduling error threshold above 1) and see if it helps the driver towards a successful recover. I'd try it myself if I had a build environment set up. Since this is an upstream issue I didn't post this on the Mobian issue tracker, but in retrospect I probably should've done that as well.
TL;DR: Switched to Picom compositor instead of XFCE's built-in compositing, and everything feels MUCH smoother.
Currently running a vanilla Manjaro ARM XFCE install on my Pinebook Pro. While everything mostly works fine, I've been bugged by how the experience somehow just feels a bit sluggish. In particular, scrolling in Chromium and Firefox is visibly laggy even for fairly lightweight websites.
I would've assumed it's just how the hardware is, but I've seen some videos of Manjaro ARM KDE on the Pinebook Pro that seem to suggest otherwise. Additionally, I happen to have a Chromebook with the same Rockchip RK3399 SoC (ASUS Chromebook Flip C101PA) and browsing and scrolling around on the Chromebook feels much much smoother in comparison.
After some digging around, I started to suspect the lag / sluggishness was related to a lack of OpenGL acceleration in the XFCE desktop. So long story short, I tried switching out XFCE's built-in compositing for the Picom compositor (apparent successor to Compton), and was blown away by how much it improved the experience. Scrolling in Chromium and Firefox felt much smoother, and navigating around apps end menus just felt much snappier.
So really wanted to share this result, and curious to know if switching to Picom may help other Manjaro ARM XFCE users as well.
Steps I used to set up Picom:
1. pacman -Sy picom
2. XFCE Settings -> "Window Manager Tweaks" -> "Compositor" -> uncheck "Enable display compositing"
3. XFCE Settings -> "Session and Startup" -> "Application Autostart" -> add item with the command "picom"
4. Start in current session with "picom -b".
The default settings seemed to work fine for me, so I haven't found the need to create a config file to tweak settings yet.
My setup: manjaro-release 20.07-1 (upgraded from 20.04 install), kernel linux-pinebookpro 5.7.0-3, mesa 20.1.3-1, xfwm4 4.14.2-1
