greetings,

sway is an i3wm replacement window manager for wayland, and my preferred ui. here's a build script for sway-git. working on debian sid arm64.

providing these build scripts as how-tos. the combination of linux 5.5, mesa-git and sway-git works exceptionally well on the pbp, which leverages the latest panfrost graphics and wayland.

after installing sway-git, consider these post-install recommendations:

• copy sway/config.in to ~/.config/sway/config if you are starting from scratch
  
• change $term to your preferred terminal (i use termit)
  
• choose your background image
  
• uncomment the swayidle block and configure to your liking
  
• use the example trackpad input block below
  
• comment/disable swaybar and "exec waybar" at the bottom of the config to use waybar instead
  
• consider adding the included custom settings at the bottom of your file
  
• (additional software referenced is grim light waybar blueman network-manager-gnome pasystray)
  

Quote:input "9610:30:HAILUCK_CO.,LTD_USB_KEYBOARD_Touchpad" {
       dwt enabled
       tap enabled
       natural_scroll enabled
       middle_emulation enabled
   }

Quote:# DEFAULT MOD BINDINGS FOR REFERENCE
# mod+a focus parent
# mod+b splith
# mod+d menu
# mod+e layout toggle split
# mod+f fullscreen
# mod+h focus left
# mod+j focus down
# mod+k focus up
# mod+l focus right
# mod+r resize
# mod+s layout stacking
# mod+v slitv
# mod+w layout tabbed
# mod+Shift+c reload config
# mod+Shift+e exit
# mod+Shift+q kill
 
# CUSTOM KEYBINDS
bindsym $mod+g exec grim -t png ~/Screenshots/screenshot-`date +%Y%m%d.%H%M%S`.png
bindsym $mod+Shift+s exec systemctl suspend
bindsym XF86AudioRaiseVolume exec pactl set-sink-volume @DEFAULT_SINK@ +5%
bindsym XF86AudioLowerVolume exec pactl set-sink-volume @DEFAULT_SINK@ -5%
bindsym XF86AudioMute exec pactl set-sink-mute @DEFAULT_SINK@ toggle
bindsym XF86AudioMicMute exec pactl set-source-mute @DEFAULT_SOURCE@ toggle
bindsym XF86MonBrightnessDown exec light -A 5%
bindsym XF86MonBrightnessUp exec light -U 5%
bindsym XF86AudioPlay exec playerctl play-pause
bindsym XF86AudioNext exec playerctl next
bindsym XF86AudioPrev exec playerctl previous
 
# LAUNCH AT STARTUP 
exec waybar
exec blueman-applet
exec nm-applet --indicator
exec pasystray

Quote:sudo apt-get -y install build-essential ccache meson cmake git \
wayland-protocols libwayland-dev libwayland-egl-backend-dev \
libgles2-mesa-dev libegl1-mesa-dev libdrm-dev libgbm-dev \
libinput-dev libxkbcommon-dev libudev-dev libpixman-1-dev \
libx11-xcb-dev libxcb-xinput-dev libxcb-xfixes0-dev \
libxcb-composite0-dev libxcb-xrender0-dev libpcap-dev \ 
libsystemd-dev libxcb-icccm4-dev libpng-dev libavutil-dev \
libavcodec-dev libavformat-dev \
libjson-c-dev libpcre3-dev libcairo2-dev libpango1.0-dev \
libgdk-pixbuf2.0-dev libevdev-dev libinput-dev \
bash-completion fish scdoc \
libpam-dev libcrypt-dev

Quote:#!/bin/sh
 
### v0.20200205.2251
## BUILD SWAY FROM GIT
 
# VARS
DEVDIR=~/Development/UPSTREAM/SWAY
 
# PREP
mkdir -p $DEVDIR &&\
cd $DEVDIR &&\
 
# GIT
for dir in wlroots sway swaybg swayidle swaylock;do \
test -d $dir || git clone --depth=1 https://github.com/swaywm/$dir.git;
done &&\
 
# UPDATE (RERUN)
for dir in wlroots sway swaybg swayidle swaylock;do \
cd $dir && git clean -f && git reset --hard && git pull && cd ..;
done &&\
 
# BUILD AND INSTALL
for dir in wlroots sway swaybg swayidle swaylock;do \
cd $dir &&\
rm -Rf pbp-build &&\
meson pbp-build -Dprefix=/usr/local -Dbuildtype=release &&\
ninja -C pbp-build &&\
sudo ninja -C pbp-build install &&\
cd ..;
done &&\
sudo ldconfig;
 
# EXIT
exit
 
# ENJOY

I am using the latest stable ayufan bionic

I need to use a few of the gpio pins as input interrupts.   In an RPI that is a simple is setting a line the the /boot/firmware/config.txt file.
ex.  gpio=9,10,24,4=pd   to set pins 0.10,24,4 as pulldowns

But I guess that method has not been copied in the ayufan image.

That leaves me to rebuild the kernel (not wanting to do that) or use a DTO which I understand is a way to add functionality to the kernel without a complete recompile.

So I gotta believe someone has had a need of pins as interrupts on the rock64 and already has a working dts file.

Besides being some pretty arcane syntax I can find no docs on this that pertain specifically to the rock64 let alone a sample dts file.

Can anyone help out here with a working dts file and some details about how to compile/register it so it gets picked up at boot.

here for example is a beagle black dts file about all I could find.

I have received the PinePhone today and, I must say, I'm impressed with it. I'm not sure what I expected, exactly, but I like what I see. 

I have tried the Manjaro image and the UBports image and the latter seems to be the most polished. Not so sure I like Plasma...

First major issue so is that I can't the SIM to be recognized... Didn't see if this was part of the standing issues with phones. But man, is it cool to have a full Linux distro on a phone!

See pic. I can push the SIM card further even until it's almost completely hidden by the metal. Either the way in the pic or completely inserted, the SIM card is not recognized by Ubuntu Touch or by postmarketOS.

Is this the correct way?

Is there an easy way to pull the SIM card out aside from using a sticky tape?



  IMG_0821.jpg (Size: 483.25 KB / Downloads: 912)

I know that Gnome isn't the most popular environment on the Pinebook Pro, with lighter alternatives like Mate and XFCE being default options on most of the popular system images.

I find that I'm very happy with it, running Debian Bullseye, per @danielt Debian installer. Many of the unmodified Ubuntu images will use this as the Canonical desktop as well.

The screen on every one of the distros looks very small for daily use - and Gnome is no exception here. My solution has been to enable the Gnome experimental capability for "Fractional Scaling". The Settings app, gnome-control-center, normally allows only two scaling options under "Devices -> Displays", 100% and 200%. These were designed for users on HiDPI screens, like that in MacbookPro and high-end Dell XPS laptops.

Since at least Gnome 3.2 it's been possible to add a range of 125%-150%-175% as additional scaling options, which are very suitable for other classes of machine, like our PBPs.

This can be enabled within your gnome session by opening a terminal, and entering:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

The control center "Settings" can now be opened with the new preference choices, without logging out of your running session. You needn't worry about putting your desktop in an unusable state. The settings will test adjustment, and revert to previous working configuration if not confirmed.

On the PBP, I find that 125% is a perfect scaling - not losing too much real estate, but keeping me from hitting <CTL-SHIFT-+> on every other page in Firefox!
It keeps me from also doing a bunch of "no-squint" customization on my terminal profiles, too.

The framebuffer text fonts are also small enough by default, to make your eyeballs feel like you've been scouring them with fiberglass, after an hour or so.
On Debian you can get a reasonable sized-typeface by switching to one of the TTYs and running:

sudo dpkg-reconfigure console-setup

The options are pretty simple. I choose UTF-8 as my encoding, because the 90's were a long time ago! Pick Latin1 & Latin5 option for most users, and here's the important part: In font selection choose "Terminus" and move to the next option, picking font size - 16x32 (framebuffer only). Now you can tell the "o" and "c" apart.

These settings will be added to the console setup by init, and be default on all new local TTYs.

Apologies if this has already been posted - I did a search without finding anything relevant.

I have a Raspberry Pi 4 4GB running Manjaro ARM, so I have a good idea of the performance of that SBC. The Raspberry Pi Foundation have said it can replace your PC.. While it's amazing for the money, I don't know that I could use it as an everyday computer. It's close, but I think I'd find it a bit frustrating.

I'm hoping one of you has both an RPi4 and a Pinebook Pro and know how they perform relative to each other. I'm just trying to get a sense of if it would work well for my uses.

My use case is:

• Replace Asus C302 Chromebook Flip - Core m3-7Y30, 4 GB ram
  
• Might also replace Dell Latitude 7370 with Core M7-6Y75, 8 GB ram, alternating Linux Mint, Fedora, Manjaro..
  
• The C302 feels super fast and battery life is great - I'm creeped out by Google's privacy issues, but they know how to build an optimized OS. The 7370 performs ok but feels a bit borderline and battery life is disappointing. They both get Octane scores in the low 20,000s.
  
• Web browsing
  
• Documents, presentations, spreadsheets
  
• No games
  
• Ideally 8+ hours battery
  
• USB-C DisplayPort a must (which the Pinebook has!)
  

So i  borked my os a few times and have reflashed the Debian without issue. But as I'm still new to this it takes me a bit to get back to my setup. I've tried timeshift with some success but would like to learn the process without any apps. What I'm trying to do is set my machine up the way I like it and make an image of that setup for ease of restore. 
1st- I take an image with
     sudo DD if=/dev/mmcblk1 | gzip -c > /media/FeMike/sdcard1 backup.img.gz
Then I take that card bring it to my windows pc and use balena etcher to flash it to another sdcard. I power down my pb64 plug the card in them turn it back on and it is still booting from Emmc. What strep am I missing or is this the wrong way to go about it? Thank you

Summary:

• A stress test of SGEMM (matrix multiplication) using OpenCL will slow down after 150 iterationbs.
  
  • Details:
    • Test is running fine during the first 100 iterations (multiply two matrix of 512 x 512). It will slow down to 1/2 speed after about 150 iterations, and will slow down farther to about 1/4 speed after 200 iterations, etc.
      
    • Note: test is running fine if sleeping for 20 seconds after every 100 iterations
      

• Do the Pinebook pro GPU has a hardware problem (ex: over heating) that prevent running a long OpenCL stress test?
  

1. Pinebook pro setup highlights:
   
   
   1. Ubuntu 18.04 64bit (based on the root file system from: https://github.com/ayufan-rock64/linux-b...m64.img.xz)
      
   2. Compiler: gcc 8.3
      
   3. OpenCL 1.2 (wget --timestamp https://github.com/rockchip-linux/rk-roo..._arm64.deb)
      
   4. ARM Compute Library 19.11.1 (native compile of sources from https://github.com/arm-software/ComputeLibrary)
      
2. [size=undefined]OpenCL is verified with:[/size]
   • clinfo
     
   • clpeak (from https://github.com/krrishnarraj/clpeak)
     
3. [size=undefined]Stress test:[/size]
   • SGEMM (matrix multiplication) using OpenCL of the ARM Compute Library 19.11.1 - the test code is appended below
     

Just a cheap wrap from Amazon and it's my first ever attempt. It is VERY FAR FROM perfect but it's ok. No experience with wrap but I believe it's too thick and not sticky enough to wrap around the edge correctly.. Anyway, if you want to see;

I actually used the Sharpie to darken the edges as it was white when trimmed.

https://imgur.com/4sE8BfQ
https://imgur.com/HjOngaz
https://imgur.com/9Nz3ZoJ
https://imgur.com/Blfb0zd
https://imgur.com/ZqZsrRt

I'll be replacing it when I can find a better wrap material.

I was hoping to see an announcement of a more robust NAS solution from Pine64 at FOSDEM, unfortunately no such luck. By chance is a solution similar to the Helios64 by Kobol in the development pipeline? 

cheers on all the great products released and coming soon!