just in case it helps anyone, I couldn't find a way to open the sd slot cover on mine. A bit of stray glue seem seems to have got onto the inside just there. After taking the back off and removing the excess glue it's now operable, however the alignment of the slot and the case makes it really difficult to insert and remove cards. Is this typical of others experience? I'm just wondering if I haven't put the back on properly.

OG thread for the PinePhone: https://forum.pine64.org/showthread.php?tid=10507

Latest builds can be downloaded here: https://github.com/dreemurrs-embedded/Pi...h/releases

Discussion Channels:

• Discord: https://discord.gg/AvtdRJ3 (#archlinux-pinephone)
  
• Matrix: #archlinux-pinephone:kde.org
  
• Telegram: @archlinux_pinephone
  

Hi,
I'm trying to troubleshoot an unusable PPB I've just received.  I've read here:

Quote:The Pinebook Pro is capable of booting from eMMC, USB 2.0, USB 3.0, or an SD card. It cannot boot from USB-C. The boot order of the hard-coded ROM of its RK3399 SoC is: SPI NOR, eMMC, SD, USB OTG.

Hi all.

After sharing the same experience that @EverythingIsInput @tiagoespinha @Eight Bit @Abandoned Brain @axel and no doubt countless others have had. I joyously unboxed my shiny new Pinebook Pro a couple weeks back, spent a delicious evening enjoying that new laptop glow, closed the lid and went to bed happy.

Only to wake the next day to find in utter dismay that the battery was totally dead. Utterly. Drained. Had to do a full recharge cycle, which, even with the barrel plug takes quite a long time.

Lather, rinse, repeat until I checked here and figured out that sleep / resume just doesn't work and that many others have felt this pain.

So I went on a bit of a quest to try to understand the problem and see if I could discern a fix or at least a usable work-around.

So let's start with:

The (Kinda Sorta) Good

At least now I understand the problem

First, I tracked down Strit, the Manjaro-ARM release manager who was incredibly helpful, informing me that he'd heard that the bug was actually a bug in the Trusted Firmware, and that he'd heard this on the Pinebook Discord/Matrix.

So, I went there and started asking around, and @CrystalGamma said that he understood the issue, but that he's working another project, and if the fix isn't in in about a month when his project completes, he'll dive in and help make that happen. He mentioned that @theotherjimmy had been the one working the fix but that he hadn't been around in about a month.

At that point @theotherjimmy popped up and very helpfully explained that yes, he's been stuck on the latest suspend/resume bug but in fact there are actually *4* related bugs that would need to be solved before end users can get this to work.

He also explained that the bug is in RockChip's vendor code and that he likely wouldn't have time for it for a while since his employer has him working other issues.

They both pointed out that the Git repository containing the firmware is here
but CrystalGamma pointed out that debugging these issues requires the audio jack to USB adapter from the Pine store, but also that this adapter *appears* to have the wrong voltage (5v as opposed to 3 and change volts) and as a result could damage your Pinebook Pro if you try to use it, so there goes any thoughts I had about trying to fix this myself

The Bad

So, the bottom line is, for us end users, we essentially should abandon any hope that suspend/resume as we know and expect it will work anytime soon on the Pinebook Pro. We're talking at *least* months. Possibly longer.

Ultimately, Pine64 made it very clear that we were buying into an open source experiment here, not a polished product, so I bear no ill will against them in this, but I can't lie - I'm extremely disappointed. This situation diminishes the usefulness of the PBPro for me tremendously  - it means I have to shut down and power up from cold boot every single time I want to use the laptop.

At least, for the moment, I have figured out a really UGLY work around that makes me incredibly sad but at least keeps me from forgetting and draining my battery every time I walk away from the laptop for the day.

The (Very) Ugly

So, what I have done in order to semi-mitigate the situation is to configure KDE to shut the laptop down whenever the lid is closed. To say this isn't ideal is the understatement of the century, but what else am I going to do?

In order to do this, click the Manjaro button in the lower left or hit the Pine logo key on your laptop, and type "Energy Saving".

This will bring up a dialog with three 'tabs': "AC Power", "Battery" and "Low Battery".

Under "Button Events" I simply changed "Sleep" to "Shut down" for each of these categories, and that seems to the needful and at least keep the laptop from bleeding out overnight when its lid is closed.

In Closing - Just To Be Perfectly Clear

I knew I was taking a risk when I bought this laptop. Pine said in no uncertain terms that it was selling these at cost and that returns were only allowed for drop dead problems like a totally DOA unit.

I also recognize that this entire venture is an experiment in the spirit of open source - let's take some high value low cost hardware, assemble it in innovative ways and see what the community does with it.

All the people I spoke to about this were incredibly friendly, helpful and forthright. They've all poured blood, sweat and tears into this project and others, and I would ask that anyone who uses this to contact them please treat them with the utmost respect and deference.

I can't lie, I'm disappointed in a number of ways, but I continue to be on board with the experiment and will keep trying to use this hardware until I come to the conclusion that I am absolutely unable to do so.

The PinePhone being an open source option to break free from the Apple/Google duopoly is what I've been waiting on for a long time now.  The potential and freedom this platform demonstrates got me to thinking about a more performant version.

My initial list:
SoC: (ARM/Risc-V) Octo Core SoC with ?? GPU TDP ?? watts (ideally PicoRio RISC-V type SoC)
RAM size, speed, type: 4GB
Display: ??
Onboard storage (NVMe): 64GB
Cellular modem: Worldwide bands major providers
WiFi: 802.11ax
Bluetooth: 5
GNSS module: ??
Rear camera MP: 12 wide
Front camera MP: 6
Extra sensors: ?
Extra radios: NFC
Extra switches: NFC
Extra busses: PCIe
Battery form-factor: ??

BOM cost <= $250
Open firmware, or at least a friendly company that is responsive and maintains support.
Manufacturing, sourcing, recycling, and repair goals similar to the Fairphone.
Total cost <= 500


I'd like to pull together a BOM with costs, openness, etc. to see what the off the shelf options are today.  I'd like to see other ideas around what hardware, requirements, and constraints others are interested in.

I was in a phone call yesterday and after what felt like about five minutes the call disconnected seemingly out of nowhere. Looking at the screen of the phone it was black and after pressing the unlock button, the icon that indicates searching for wifi and the cellular connection signal strength bars appeared. I had a feeling that the screen locked itself automatically and in so doing also ended the active call. I went into settings > power > power saving and deactivated "dim screen when inactive" and next to "blank screen" in the drop down menu I choose "never" because to be honest, I have no idea what the difference between "dim screen when inactive" and "blank screen" is.

I called again and after what felt like the exact same ammount of time as before the call just ended. Black screen, unlocked it, wifi icon and cellular connection signal icon appear. I again went into settings and this time I turned off "Automatic suspend".

Now when I called again it lasted for 40+ minutes until I ended the call myself. It would seem to me that I have an issue where automatic suspend activates even while I am in an active call. I guess this activates crust which shuts off cellular and wifi service to save battery. Looking around the forum I havnt found something similar so not sure if its only a problem for me or anyone else. I do remember that I have been making a call longer than five minutes before without autosuspend kicking in so could be something new or maybe just me messing around to much in terminal.

I did see https://wiki.mobian-project.org/doku.php?id=tweaks mentioning prevent suspend and keep the screen on for different apps but I have no idea to implement that on the nmcli. Not really sure what to do from here..

Be aware, these tests are being executed using an out-of-box testing methodology. All tests are preformed with minimal interaction/setup of devices outside of: OS imaging/updating,  SIM installation, Wifi Configuration,  and Power Cycling the devices.

Results:mobian/2020-09-10-TMobile.html
             mobian/2020-09-10-Verizon.html


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


Notes: The Microphone is still really sensitive. The audio out quality is suffering. Camera still super laggy. Firefox and the settings app are taking 15+ seconds to load. I have noticed that the UI is smoother. Scrolling has improved. Ring Back tone only on TMobile on 3G.

Hi,
I updated my braveheart last night to stable build 6 and I am getting the error message (twice) Failed to add storage device, make sure the storage device device is formated correctly.
I am booting SD card and didn't get this message before.

I am wondering what may be causing this.

Thanks

Ashley

Be aware, these tests are being executed using an out-of-box testing methodology. All tests are preformed with minimal interaction/setup of devices outside of: OS imaging/updating,  SIM installation, Wifi Configuration,  and Power Cycling the devices.

Results: ubports/2020-09-10-TMobile

Conclusion: This OS is not ready for the device to become a daily driver.

Notes: Still open to the idea that the camera button is to reverse the image not switch to the 'selfie camera' if anyone can confirm either way I would appreciate it. Failed 4G outbound call still an issue; the failed call no longer kills audio on all other calls. 3G calls are see a little bit of improvement. Able to connect, wasn't getting a count up on call timer. No audio passed either direction. Rebooted phone and tried again, nothing. Good to see some changes going through that portion of the code base though. 3G SMS outbound issue present today. Hopefully the VoLTE fixes are underway.

Issues:
4G outbound calls broken.
Phone gets stuck in a weird lock state when spamming power button.
Outbound SMS over 3g is broken.
Audio cuts out after "No Calls" error is handled on inbound/outbound calls.

Hi all, 

Received my pinetab today and noticed on first boot the top row of the onscreen keyboard was unresponsive and I was unable to enter most things for the setup. Once I got to the desktop I verified that there is a strip that runs the full width that doesn't respond to any touch input. The plastic screen protector also came with a bunch of scratches and fingerprints, removing it did help touch sensitivity somewhat on the rest of the screen but that strip was still dead. On top of that, the keyboard case only a few keys work. I verified with an external keyboard that it can receive those inputs. 

I'm leaning towards a hardware problem (which is a bummer given how long the wait was) but wanted to check to see if anyone else encountered similar and if there's an easy solution. Thanks.

Edit 1: Tested multiple operating systems, problem persists. Screen rotations don't change where the bad strip is. Gotta be a hardware issue, went ahead and submitted a ticket. Am sad.

Edit 2: Attached image to show what I'm talking about. Drawn horizontal lines with gimp roughly covering the possible y-axis points when in landscape mode. Turns out, there's actually two dead strips. When trying to draw in between those two white spots on the bottom input just goes above or below. Sometimes it would cross over due to momentum and gimp approximating things but it's impossible for anything to register inside those bounds

Attached Files

  pinetab_bad_touchscreen.jpg (Size: 232.74 KB / Downloads: 671)