
Wayland and LVGL on PinePhone with Ubuntu Touch - lupyuen
https://lupyuen.github.io/pinetime-rust-mynewt/articles/wayland
======
josteink
Like other people here have mentioned Ubuntu touch/UBports is probably not the
most Linuxy thing you can run on this phone, and there’s a wide choice of
distros to choose from. It’s almost like _real_ Linux! ;)

That said I love seeing the momentum and attention the PinePhone is
attracting. Can’t wait until my order arrives.

------
lupyuen
Learn about Wayland and Ubuntu Touch on PinePhone... And how we build
PinePhone Apps with LVGL

------
ncmncm
> _Do we really have to code LVGL Apps for PinePhone in C? Rust is supported
> too!_

Fortunately, C++ works. Modern C++ coding is very fun, and gets more fun with
each new Standard.

------
iuguy
Honestly, that post triggered me. I've had really horrible experiences using
LVGL on low powered devices.

~~~
lupyuen
Would you mind sharing why? We are adopting LVGL for PineTime Smart Watch,
hope we won't fall into a trap. Thanks!

~~~
iuguy
I was using it here[1] because the TTGO libraries were using it and it looked
like a solid GUI. Unfortunately I took the TTGO samples and extended them
instead of doing things from scratch and tbh the code for AWatch is an
embarrasing mess that just happens to function enough to pass as working.

However... When I was doing all this, TTGO used LVGLv6. LVGL had just released
7, changed everything on their site and all their support. Documentation were
pointing to a mix of v6 and v7 items, and there are breaking changes.

When I say breaking changes I mean the entire freaking toolkit is different in
the way styles and widgets are handled. I have to rewrite everything by hand
to go from 6 to 7.

Lilygo updated to v7 recently but I haven't had a chance to update the AWatch
code for it, nor am I inclined to. For a do-over. I get that LVGL is good for
say, Arm project size stuff but on ESP32 in the Arduino IDE it's no fun, a
sentiment well expressed here in the current docs[2].

One other pitfall I found was that I wanted to be able to dynamically draw
items on the screen so I could create a decent Protracker VU-meter for AWatch
and possibly a little finger note thing. I ended up falling down a Canvas[3]
rabbit hole. Do not touch Canvas if you can avoid it, especially on a low
memory platform like ESP32. I had massive memory problems with it. Again, this
was 6, not 7 so YMMV but it's put me off for life.

I'm looking for something simpler with limited inheritence. I don't forsee a
need for something as complex as LVGL on a simpler watch like the TTGO T-Watch
series.

[1] -
[https://github.com/stevelord/AWatch](https://github.com/stevelord/AWatch)

[2] - [https://docs.lvgl.io/latest/en/html/get-
started/espressif.ht...](https://docs.lvgl.io/latest/en/html/get-
started/espressif.html)

[3] -
[https://docs.lvgl.io/latest/en/html/widgets/canvas.html](https://docs.lvgl.io/latest/en/html/widgets/canvas.html)

------
ncmncm
Interesting, this page reliably crashes Firefox on my phone. This is
immediately after Firefox decided on its own to "upgrade", and erased all my
tabs.

Hoping my PinePhone arrives soon.

~~~
ben-schaaf
Odd, it's working fine on my android phone using firefox (as well as desktop
firefox). I've also never had an upgrade lose any tabs.

~~~
lupyuen
I have just resized my images. Thanks for reading :-)

------
floatboth
> Hopefully someday we'll move on to newer, simpler app frameworks (like LVGL
> and Flutter) as we discard our Old Underwear: X11, SDL, GTK, Qt, ...

Ummmm what?

SDL is basically timeless as it's just a layer that abstracts various
platforms (Wayland, X11, Mac, Windows, game consoles…) to offer one single API
for just making a window with a GPU context, receiving input and stuff.

GTK is a really solid toolkit with a strong, consistent UI design philosophy.
The upcoming GTK 4 transitions everything to GPU-based rendering _without_
reinventing the whole toolkit from scratch (unlike Qt with QML, Windows with
WPF and UWP…). GTK suffers from lack of funding sadly, so it's a slow project,
but the current state of GTK4 is already pretty impressive.

Qt is a monster framework with corporate interests working on it, but it's
also really solid and QML/QtQuick was basically Flutter years before Flutter
(so actual Flutter is just Google NIH syndrome…).

"Simple" UI libraries like LVGL are always bound to make your life not simple.
They usually don't support accessibility, lack support for various platforms
(you've just had to port that one to Wayland), have various limitations and so
on.

Flutter is not even simple.. it needs the whole Dart VM or compiler whatever
monstrosity to run.

~~~
panpanna
> so actual Flutter is just Google NIH syndrome…

So true.

If Google can't control it, they build a competitor. If Google can't figure it
out, or if it is not 100% what they need, they will build a competitor.

This has caused tons of problems for both the industry and consumers. For
example, Android updates would be much less of a mess if Google had used
linus' LTS kernel...

~~~
vlovich123
How does sticking to an LTS solve the lack of stable driver ABI? That’s what
project Treble from Google was about - providing a stable ABI driver
authors/vendors can target so that an OS update can build and function
correctly.

Also I don’t know how closely you followed the ARM tree of the Linux kerne but
pre-Google the authors were resistant to the board config approach because you
don’t have that on x86 because there isn’t an SoC that bundles a lot of the
functionality. It wasn’t until Android that the Linux tree started taking ARM
more seriously (which arguably it wasn’t really before anyway)

~~~
panpanna
Well, for one thing you have only one ABI to consider if you go with the LTS
instead of hundreds we have today.

Treble is Google's attempt to fix a problem they - at least mostly - created
themselves thanks to their NIH attitude.

Not sure I would attribute use of device trees to Google. I think the ARM-
fication of the kernel happened a few years before Android.

~~~
vlovich123
You may want to brush up on your history:
[https://elinux.org/Device_tree_history](https://elinux.org/Device_tree_history)

Russell King as recently as 2009 was against it. It got merged around ~2013 so
it took about 4 years. The first Android phone was supposed to be 2009 but
IIRC it got delayed to 2010 because of the iPhone (announced 2008). I think my
characterization of this is fair and accurate.

> Well, for one thing you have only one ABI to consider if you go with the LTS
> instead of hundreds we have today.

I don't follow. You have 1 Android release per year. There is a new LTS kernel
every year. I don't see how sticking to LTS solves the problem. You have to
actively hold off on Linux kernel releases to get any advantage of this
process. For something like Android this means they'd be forking LTS & it
would be even more work to move to a new kernel (all the out-of-tree
development + all your driver vendors switching kernels). So now you'd be
complaining why Android is using such an ancient Android kernel. Treble solves
a real problem and has nothing to do with NIH unless you just define all
kernel development happening at Google as NIH (which would be strange
considering how many Linux kernel developers and maintainers they employ).

------
HugThem
I wonder why one would chose a phone with Ubuntu Touch over some non-linux
phone.

With Ubuntu Touch, you can not install anything on the phone. It has a read-
only root filesystem that gets updated over the air.

So just like with the locked down phones (iOS, Android), to gain control over
the filesystem, you would have to root it. But then your changes would get
wiped with the next update.

This seems just as far from a "Linux Phone" as Android to me.

I am looking forward to one day having a phone that runs Linux. But then I
want the same freedom I have on my laptop. To install whatever I want from the
Debian repos via apt-get and update via apt-update / apt-upgrade.

~~~
zozbot234
> It has a read-only root filesystem that gets updated over the air. ... you
> would have to root it. But then your changes would get wiped with the next
> update.

No, given root access you can simply overlay a separate read-write filesystem
over the readonly system partition. It can be as "Linux" as any Live
distribution with persistence.

~~~
HugThem
What are the "easy" steps to "overlay a separate read-write filesystem over
the readonly system partition"? I would not even know where to start.

~~~
lupyuen
Just a simple line :-)

sudo mount -o remount,rw /

Then we can sudo apt install anything...

sudo apt install gcc gdb git make libgles2-mesa-dev

~~~
panta
This is re-mounting R/W the root, not mounting an overlay. What you install
this way will be wiped out on next update.

