Can anyone suggest a capacitive stylus with right/lift click buttons? Seems like a basic product that should exist but internet searches have yielded nothing.

Edit: So they're marketed as active pens but seems linux support isn't their strong point. I guess keyboard/mouse will be a safer bet.

Ex-Solus Head Dev Ikey Doherty will be releasing thier new Linux Distro, Serpent with day one support for the PBP! 



"Serpent OS is that it will ship with a full-featured KDE Plasma desktop environment. However, the initial pre-release builds will be shipping with Sway, a tiling window manager and Wayland compositor, since Serpent OS will be a Wayland-only distro."



Link:  https://9to5linux.com/serpent-os-to-offe...kde-plasma

More detail on the SerpentOS.com about page:

"As we’re taking a distro-first, compatibility-later approach, our design decisions will allow us to take some bold steps. We’ll also be able to incorporate all of the more sensible design improvements in Linux distribution design over the last decade or so:

    No more usrbin split
    100% clang-built throughout (including kernel)
    musl as libc, relying on compiler optimisations instead of inline asm
    libc++ instead of libstdc++
    LLVM’s binutils variants (lld, as, etc.)
    Mixed source/binary distribution
    Moving away from x86_64-generic baseline to newer CPUs, including Intel and AMD specific optimisations
    Capability based subscriptions in package manager (Hardware/ user choice / etc)
    UEFI only. No more legacy boot.
    Completely open source, down to the bootstrap / rebuild scripts
    Seriously optimized for serious workloads.
    Third party applications reliant on containers only. No compat-hacks
    Wayland-only. X11 compatibility via containers will be investigated
    Fully stateless with management tools and upstreaming of patches
    Lots, lots more. We’ll blog about it.

Opinionated By Default

A recurring theme that holds back the development of world-class Linux, is high tolerance for those holding Linux back. A perfect example is NVIDIA* and their lack of support for accelerated Wayland support on their GPUs. Consequently, our project won’t tolerate such decisions and will instead blacklist the NVIDIA proprietary drivers from the distribution.

There are other examples that will emerge over time, and will become quite clear.

The time for Linux distributions giving in, with thousands of man hours wasted working around negative actors, had come to an end."


...Very interesting

Results:Mobian/2020-08-24-Verizon.html
           Mobian/2020-08-24-TMoblie.html

Conclusion: OS not Ready for pinephone to be daily driver.

Notes: Hey guys. Im taking over this thread from @plainenough  We have added a few test cases. Also we are testing on more than one carrier. Verizon, only allows for 4G calling, reinforcing the idea that 4G calling is a requirement for the pinephone to become a daily driver on Mobian. With this in mind, 4G and 3G calls are broken on this Mobian build. We will not be incorporating any data tests this week. Feel free to comment with any results on your own tests to share with others.

Results: ubports/2020-08-24-TMobile
               ubports/2020-08-24-Verizon

Conclusion: OS not Ready for pinephone to be daily driver.



Notes: First and foremost: I have added a few test cases. Also I am now testing on more than one carrier. I will always test Tmobile first, so for results on non carrier tests you can simply refer to that link. Verizon, only allows for 4G calling, reinforcing the idea that 4G calling is a requirement for the pinephone to become a daily driver on ubports. With this in mind, 4G outbound calls are broken. Verizon text messaging inbound also appears to be broken. We will not be incorporating any data tests this week. Feel free to comment with any results on your own tests to share with others.



@AmazingNutria Will be taking over my mobian testing.

I ordered a Pinebook Pro in August 2019 and my unit arrived sometime in December. I had a US ANSI keyboard model. However over the last few weeks I started noticed weird power behaviour, the laptop would be left on overnight on charge but in the morning I would find the battery completely depleted or the device had randomly powered itself off for no valid reason. I have not taken the device out of my house, and just move it between a few rooms - so I put it down to linux being linux. I would unplug and replug it, power cycle and notice the battery seemed to be getting a charge but that there did appear to be some kind of power related issue but did not think much of it. Until it died.

Now, the pinebook pro will not even charge on the barrel jack. The pbp died completely 3 days ago, when I connect two different PSU's (which I tested at giving 5V out each with a multimeter) on the barrel jack, I got absolutely no red light indicating power, the laptop was completely dead. I left it charging via USB-C which did give me a charge indicator, it took several hours to get enough charge to power on the laptop. Once I booted the laptop I noticed that the battery indicator stated "discharging 0%" and after a few minutes with the device powered via USB-C, it would just switch off anyway (after a good 12 hour charge).

I opened the case, disconnected the battery, connected the bypass wires and then powered from barrel jack - nothing, the barrel jack is completely dead, however the USB-C power input would work but was not able to give it enough power to complete booting from the NVMe. The pbp is hosed, so I looked to see what the fault could be.

I have identified that one of the transistors besides where the "bypass" cables are wired appears to have let out the magic smoke, additionally I am disappointed at the state of the soldering job on those wires - they are basically soldered on in such a way that undoubtedly these bypass cables have moved around over time introducing a short - the metal contacts of the wires runs right across the flex cable battery connector, this I believe is what has caused the transistor to blow and break the charging circuit. The cables are half exposed when connected to the PCB and are soldered on in a blob method right across the battery contacts and alongside where the blown transistor appears. Picture below.



I have ordered a new replacement pinebook pro mainboard as unfortunately I was using this thing for actual coding work at night time and aside from the exploding transistor of death it's been a rather decent little machine! in the interim I will try to swap out the blown transistor - does anyone know what component that is on the board above, its the middle transistor that has clearly cracked open? One thing I would definitely do on my new unit when it arrives is remove those bypass cables unless I actually intend to power it without a battery direct from DC, as undoubtedly I believe they are the reason the board short circuited on the power circuit at some point (at least that is my best guess right now). Oddly, those are both soldered with VCC + GND connected to the same pads, they should be removed if not required. Is anyone else noticing the poor connectivity of these wires? Is this a known fault? Have others experienced it?

The machine was powered on most days, didn't have anything plugged into it aside from USB controllers and an RTL-SDR so nothing else can seemingly explain the transistor of death.

I post the above linked thread in the Hardware section as I first thought that my emmc is broken. But as I'm able to boot the factory image from May 17 and other distributions, I believe it could be a PM OS issue.

This is the thread from the hardware section and below my last thread with my "workaround":

This is the observed issue:

I have PM Os installed on the emmc, the sd card as an additional drive. It worked very well with the stable branch. Three days later it was dead. When pressing the power button it stucks with the 'led test' and makes a short 'click' (which seems to be specific to pm os) and restarts over and over again. that it quits at the "led test" reminds on the error bieps from bios, when something essential did go wrong. So: no boot screen, nothing.

What I already tried:
- completely charge the battery
- flash the sd card with jumpdrive:
The phone booted into the jumpdrive modus, but: lsblk did not show the emmc nor the sd card (which is strange). I can unplug the usb cable while it runs jumpdrive, so the battery works well.



https://forum.pine64.org/showthread.php?tid=10962

Greetings!





I'm in the process of considering an order for a PinebookPro, PinePhone, and a Rock64. I'm very much interested in low-level coding on this unique hardware (and having an ARM laptop and linux phone!), so I'm interested in collecting information and making good purchases to support that endeavour. As such, I've got several questions, and would like to use this thread to list out the "ultimate hacking kit" of sorts for others who are similarly interested in this area. I'm going to edit this opening post with resources we bring together so it can be an effective one-stop-shop for people who are similarly interested in getting into hacking ARM hardware with the Pine64 products.

Rock64. The device I'm considering is 4GB (store page). Questions I have are about any necessary support hardware:

• Is a heat sink required? They're sold, so it seems like it might be desirable. I do intend on getting a metal case, if that would affect head dissipation enough.
  
• Given the Rock64 uses the same chip as the PineBook, it seems to follow that it can boot off of eMMC, SPI flash, USB, and SD?
  
• I suspect the answer is no, but does the Rock64 come with either of: a power cable and/or a eMMC module? (power cable separate as per store page)
  

• manawyrm recommends the TTL-232R-3V3-AJ for phone/laptop serial. It operates at the appropriate voltage. However, I noticed it only has three post segments, meaning one is missing compared to the broken official cable. I understand he says it works, but I'm concerned there would be a downside to losing that one segment (I'm not an electronics buff, so I would appreciate any explanation anybody could offer).
  
• Does the PinePhone come with an eMMC?
  
• What's the best economy NVMe SSD card that is compatible with the PineBook?
  
• Is the keyboard/touchpad firmware open source? Anybody do any neat hacks on it?
  

• Does the eMMC adapter work with the eMMC modules Pine64 sells? It is reported that it doesn't work with many eMMC modules (lost the thread, there's a wiki page too somewhere it linked to)
  
• Is the so-called "woodpecker" serial console adapter considered safe? The audio jack cable for sale is known to cause significant problems. Also, does it come with the wires necessary to hook it up to the Rock64? Finally, and this might be implicit from the first question, but can it be used to interface with the Phone and PineBook (with an appropriately built adapter)? Also, it is apparently the case this console can prevent correct booting if the TX pin is connected; is this the case with all serial consoles?
  

• The documentation reports an MMU that differs somewhat from the official ARM MMU. Is this the only MMU in the system? Or, is it only for the Cortex-M4? If it is the main MMU, then the documentation on the data structures it uses seems to imply it doesn't support virtualisation (the page table entries do not contain an ASID/VMID that I've seen). I partly suspect that the RK3399 doesn't FULLY document the page table structure (basically, it only shows the directory entries rather than the page table entries, which would be "standard").
  
• Related to the MMU, but is TrustZone supported?
  
• Related to the MMU, is there a No-Execute (NX) support? The pages only seem to have Read and Write flags.
  
• Some resources for comparison if anybody wants to try and interpret it:
  • RK3399 documentation:
    
  • • Chip overview: http://rockchip.wikidot.com/rk3399
      
    • Technical Manual P1: http://opensource.rock-chips.com/images/...170408.pdf
      
    • Technical Manual P2: https://www.rockchip.fr/Rockchip%20RK339...0Part2.pdf
      
  • ARM documentation: https://developer.arm.com/architectures/...ofile/docs
    

I didn't know where to put this, so I put it here. Sorry if that's wrong.

I haven't been able to get into the IRC for a couple days now.
It looks like the system is down.
Any idea when it can be back up?

Also, is there any way to access the #pinephone irc channel with a regular IRC client?

Thanks for any info.

I'm interested in getting a PinePhone to have more control over what my phone actually does.  By comparison, my Moto G6 running some variant of Android is so slow for almost all things I do.  There's even a delay with each character I type in a text message, though it wasn't always this way.  It was never fast, but with my employers control over my phone, it seems to be much worse (they have this Duo and some other admin type thing they installed).  I believe they actually have more control over my phone than I ever had. 

I hate this.  When I click a character, I want it to appear, and not decide to do some other background server task.  Or at least make me think I'm only doing that thing.  Don't be scanning my keys, uploading things somewhere.  If I take a picture, *I* want to decide to send it to AWS, or not.  If I turn that off, I don't want Jeff Bezos turning that back on as it currently happens.

However, I read the start of the PinePhone wiki for installation instructions, and it sounds like I have to buy some separate card, download any supported image and hope that it works on my AT&T phone.  I've installed Linux before on a desktop, I don't mind the command line.  However, I have about a 3-4 hour limit before I start to curse, loose patience.

I'd like to take pictures, have good phone calls, send and receive messages, surf the web including watching youtube videos.

Will this work?

Thanks,
mrb

Here are my first steps with video editing with a PBP.
We really need access to hardware video codecs, but that is another story.

I installed OpenShot and started working on a 720p video.
I only added a simple image before as intro and a simple image after as outro.

The preview in OpenShot already suffered from performance issues and it is really hard to get the right timings when you want to cut a video clip.
In the end I used VidCutter to get the start and end for a clip and used the time markers in a command line with FFMPEG.
VidCutter seems to start cutting from a key frame by default and smart cutting gave a strange jump in my clip.

Here is an example of the command line and the source where I found it.

ffmpeg -ss 00:01: 00 -i input.mp4 -to 00:02:00 -c copy output.mp4

https://stackoverflow.com/questions/1844...ing-ffmpeg

At the moment video editing on a PBP is a bit like torturing yourself.
I really hope we do get access to the hardware video codecs in the future.