Hello,
After, I believe, the second update on phosh 11 the system hangs at the manjaro login screen with the tiny characters before the numerical pad usually comes up. I haven't found any similar problems yet. Thanks for any advice or pointers towards resolving this problem.

I don't have half a clue how this happened.  I was trying to install BitWarden desktop app from source and ran into a few snags with node-gyp during build

Below is just some random stuff I was doing in the terminal.

On the first line below, sudo worked. On the last line, sudo suddenly failed and has been broken ever since.  Either something I did in the log below somehow broke sudo, or something in the background of PMOS broke it.

Any idea what's going on here?  Is there any way to recover other than wiping my phone and reinstalling?

This is a mostly clean install.. PMOS only on the device for about 1 hour, and I only installed some dev libs, git.. basic stuff.  

PMOS 21.03.1

Heyoh, I had purchased the PB-Pro Docking Deck recently and seem to be having some issues with it. Primarily, I can't seem to charge my Pinebook Pro off of it, and secondarily, It's not connecting to the plugged in ethernet...
The dock didn't come with any extra charging cables, so I just plugged in the PB-Ps charger directly into the docking bar, then the dock into the PB via the USB-C cable (in the one and only usb-c port). The PB does appear to be able to read SSDs that are plugged into the bar, so I feel like the USB-C itself is fine. The ethernet port is blinking as if it is transferring data, but only WiFi options appear. I'm using Manjaro ARM XFCE 21.04 atm, if that plays into it. Thanks in advance!

Hi! I run manjaro ARM on my pinebook pro. After the latest `pamac upgrade`, I've started to get regular lockups. Checking `journalctl` I have this kernel error in there:

https://pastebin.com/dw1T8x1z

Relevant error messsage seems to be 'Unable to handle kernel NULL pointer dereference', and the call stack looks like this

Jul 06 21:24:57 pinebook kernel: Call trace:
Jul 06 21:24:57 pinebook kernel: drm_ioctl+0x280/0x44c [drm]
Jul 06 21:24:57 pinebook kernel: __arm64_sys_ioctl+0xa8/0xec
Jul 06 21:24:57 pinebook kernel: invoke_syscall+0x48/0x114
Jul 06 21:24:57 pinebook kernel: el0_svc_common.constprop.0+0xbc/0xcc
Jul 06 21:24:57 pinebook kernel: do_el0_svc+0x24/0x90
Jul 06 21:24:57 pinebook kernel: el0_svc+0x2c/0x54
Jul 06 21:24:57 pinebook kernel: el0_sync_handler+0x1a4/0x1b0
Jul 06 21:24:57 pinebook kernel: el0_sync+0x198/0x1c0
Jul 06 21:24:57 pinebook kernel: Code: 35000575 a94573fb 17ffff79 f9401a80 (b940e800)
Jul 06 21:24:57 pinebook kernel: ---[ end trace fe4cd6ccb18f59e7 ]---


It seems the kernel is now version 5.13.0-1, I might try downgrading that.

To date, there are only 3 meaningful types of performant and readily available ARM64 desktop workstations:

- M1 Mac Mini / iMac

- Nvidia Xavier NX/AGX

- Honeycomb LX2


All other "look at me, I haz arm" devices are either laptops, puny tablets trying to imitate laptops or plain devboards with an Android image or a quarter-functional, outdated Debian..

They mostly use smartphone chips, sometimes higher frequency-binned and with a more liberal power limit. And they lack HW documentation. Or they are discontinued.


What is truly needed to kickstart the ARM64 ecosystem further is a good desktop workstation. 

In such a board, I reckon there should be:

• some kind of ATX standard form factor to mount it in a regular PC case with a regular PC power supply
  
• socketed RAM
  
• PCIe, USB, SATA, 3.5mm jack, RJ45..
  
• a power and a force reset button
  
• a chip to keep the bootloader on, so as to make the OS installation simpler
  
• targetting Arm SystemReady certification, which given enough work on proper UEFI, would allow for installing OSes like on a normal PC, from a livecd etc..
  
• an OSS-friendly SoC that can heat up as much as it wants - performance is key in this form factor! (without a broken PCIe implementation, I'm looking at you, Raspberry Pi...)
  
• Intel-/AMD-compatible mounting holes for a cooler
  
• DC/PWM fan headers (may be on a separate controller)
  

I am still in early exploration phases, but I am pretty sure I was able to open and look around in Maps (the default program, which is apparently Gnome Maps) before.  But not lately.

I don't recall doing much (if anything) out of the ordinary.  Also I have been upgrading via terminal with apt update && apt upgrade (after reading of some problems updating via GUI).

Just curious if anyone else have also noticed this?

Hello all,

I would like to utilize the video decoding capabilities of the RK3399, but so far I had no success. Many people seem to underestimate how difficult this is and just assume it works without effort.

Here is how to verify whether it works, using mpv, chromium and firefox:
(the pictures are taken on my x86_64 PC)

1. mpv
CTRL + H toggles hardware decoding. If it can't use cuda/vdpau/vaapi then it will just say 'no' all the time.

2. chromium
open the developer panel with F12, open the Media tab

as you can see, VDA is hardware accelerated. Other decoders (Vpx, Dav1d, FFmpeg) are used for the VP9, AV1, and Theora codecs. Neither my Radeon nor the RK3399 have hardware support for these codecs.

3. firefox
run

So far my major complaint is the touch pad, really keeps me form using it more, largely the need to really press the right/left click buttons (I'm used to ez/soft touch buttons) but the sensitivity's not been something I've been able to dial in to be happy either, 

I've had wireless issues as well, lots of connectivity/dropping and poor streaming, but I don't know that that's not software related

Just feedback I hope helps with future developments 

Number one dislike for me on the hardware is the speaker is too close to the mic, good speaker, but on speaker phone I have to keep the volume pretty low so the caller doesn't hear themselves echo, if the next version chosen could employ a different design, speaker located at the top for instance, that would be great 

Hi,

since I haven't found a tutorial on how to use a usb smartcard (like f.e. Nitrokey/Librem Keys) to unlock the Luks encrypted volume on a Pinephone, I had a look at it myself and found a way to do it (at least on Mobian).
If someone else wants to try this, I've modified the Luks gpg fde configuration script from Purism (https://source.puri.sm/pureos/packages/s...d-key-luks) to automate the configuration on the PinePhone with Mobian.

Feel free to have a look: https://github.com/sam-m7/smartcard-luks-osk

It works by using a modified version of the gnupg-sc keyscript (/usr/lib/cryptsetup/scripts/decrypt_gnupg-sc). The modified version uses the on-screen keyboard (osk-sdl that is also used for normal fde) and forwards the output to gpg (PIN). After 90 seconds there is a fallback and the keyboard pops up, also if no smartcard was detected. You can then type in a passphrase from a different keyslot (without gpg being called). But there is no feedback (at least not on the screen, a little bit on the serial console).

The recognition of the USB Device sometimes takes long. As far as I would say there is a problem with the anx7688 kernel module, because if it doesn't work, this is printed in the serial console (UART adapter) all the time (not only in the initramfs stage):