I received a Nexdock which is basically a display and a bluetooth keybord. The idea is that with Nexdock you can turn your Pine64 into a laptop.
https://www.indiegogo.com/projects/nexdo.../2028259#/

I'm running RemixOS 2.0 on my Pine64 2GB but I can't change the output resolution of the Pine64 to 1366x768.
1366x718 is the native resolution of the Nexdock.
Nexdock works together with Pine64, but all text is hard to read because of the wrong display setting.

Any solution or Remix OS update to fix this issue?

Thanks, Bart

This mini tutorial is meant for those people providing Android or RemixOS 'DD images'. The DD images currently provided have been created wrong (too large for many SD cards out there). Fortunately it's easy to do it better. Since we're talking here about SBC why not stop wasting time on both creator's and user's side, using an SBC in USB gadget mode, create images with appropriate size and speed up things?

The whole process would work with any Pine64/Pine64+ too but since AFAIK no OS image is around that uses a correctly configured kernel enabling the necessary g_mass_storage module and since a small patch might be necessary to get this working with BSP kernel (can't test right now since ran out of Pine64) we discuss this with H3 devices instead (H3 is A64's little sibling). Ingredients:

• Any H3 device from this list: http://www.armbian.com/download/
  
• A short USB-to-Micro-USB cable (or type A to type A when choosing the Beelink X2 or Pine64 later)
  
• An Armbian image for the device in question using legacy kernel since we need USB OTG support
  
• A 120 GB disk to store the images with 7.8, 15.8, 31.8 and 63.8 GB size (or a 250 disk when both Android and RemixOS images should be stored on the same disk)
  

Hello everybody.
I have kingston 16GB claa 10 SD card. I have downloaded the 16 GB android image but when i try to DD the image on the SD I havn't enough space on the SD.
I have also tryed with Win32Imager but I have the same problem.

How can i solve?

This is the last thing my pine write before shut down and turn off.
Can someone help me what is the problem? ):

Just thought I'd post the current version of the shell script I am using on my Pine64 to make the user controllable System LED (the one that you can attach near the headphones jack, or via the EXP header). I added it to /etc/rc.local (make sure you put an " & " at the end, so it doesn't block rc.local continuing / exiting), so now every time the pine64 starts up, I get a little heartbeat indicator going so I know it's running ok. Since it's a gist, you can also download it via wget or curl... just copy the URL you get from the 'raw' button up the top right. 

Next step will be working out how to intercept the power button... perhaps via udev, since that already responds to the power button interrupt, but doesn't know what to do with it out of the box. 

https://gist.github.com/pfeerick/00b04df...b4e1f7c168

A known issue from Raspberry Pi land that also effects the Pine64 is the need to use sudo in order to manipulate GPIO bits... which gets annoying pretty quickly... and tempts you to stay logged in as the root user, which is a bad idea.

There are some workarounds... i.e. using python GPIO, wiringPi (when available). But there is also a relatively simple fix you can apply in order to fix it up, which is to basically add two startup scripts that automatically fix the permissions. I've just run through this myself, and had to backtrack and check what I'd done, so please let me know if there are any mistakes or corrections needed. So... here we go!

Create a gpio group first:

i like it

I have a nexdoc. The pine64 will drive the display but not well, it is not crisp like it should be.
The display resolution of the nexdoc is 1366*768, but I can't select this under ubuntu on the pine (in fact I an only select one resolution (I can't remember what). Is there some way around this?
..mcf

I have a 'bad' PINE64+ board, running armbian with legacy kernel, powered via micro-USB AC adapter. NIC and UART0 serial are the only active peripherals. 100Mbps is perfectly fine, but there's a major packet loss at 1Gbps, no need for iperf to tell there's an issue.
 
VDD33 voltage is between 3.26V and 3.27V, regardless of
- 1Gbps or 100Mbps or 10Mbps link speed
- CPU idle (/sys/class/thermal/thermal_zone0/temp @ 42 degrees) or busy (/sys/class/thermal/thermal_zone0/temp @ 65 degrees)
- 3 different microUSB AC 5V adapters and cables
 
That voltage is within tolerance range of 2.97V to 3.63V for PHY VDD33 (per PHY DS). PMIC AC input tolerance range is 3.5V to 7V (per PMIC DS), so PHY should be getting conditioned ~3.3V consistently, even when microUSB AC source is used. Unfortunately I don't have a scope to monitor continuously, but if AC-IN voltage drops were affecting 1Gbps communications, I'd expect them to equally affect 100Mbps communications and that is not the case. So the issue with my board doesn't seem to be caused by PHY input voltage fluctuations.
 
However, there is a noticeable difference in the amount of packet loss with different power sources:
1. laptop USB, so <500mA, 2 feet USB cable
PC -> SBC: 30% loss
SBC -> PC: 36% loss
 
2. AC 5V/2A adapter, 6 feet USB cable
PC -> SBC: 5% loss
SBC -> PC: 11% loss
 
3. AC 5V/3A adapter, 3 feet USB cable
PC -> SBC: 15% loss
SBC -> PC: 31% loss
 
I'd speculate that there's possibly another element sensitive to AC input inconsistencies that might not be conditioned by the PMIC or that may have a narrow tolerance range. Alternatively, PINE64+ PCB layout might not be strictly following guidelines for RTL8211E IC as set forth in PHY DS, resulting in EMI affecting its operation or VDD10 conditioned input being outside of a narrow 0.95V to 1.06V tolerance range.
 
References:
PHY DS - http://files.pine64.org/doc/datasheet/pine64/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf
PMIC DS - http://files.pine64.org/doc/datasheet/pi...t_V1.0.pdf

https://plus.google.com/1119478323025725...jxfLtbp4iG

Pine 64 in a pine box The Pine 64 is already augmented with heat sinks and a fan. Added an Odroid wifi module 3 and USB camera. All ready for my computer vision projects. I don't need no stinking laser cutter or 3D printer when I have a rotatory tool. and old cigar box.