Author Topic: Final call for TP3 (Read 44290 times)

Adam Boardman · « **on:** January 30, 2019, 03:31:33 am »

Are there any changes you think should be included before we release DebianTP3?

Ideally quick easy fixes or tested pull requests for bigger changes.

I was wondering about:

Splitting of the bottom bar to a left and right one?
Graphical updates for wall papers or lock screen backgrounds?

Kiriririn · « **Reply #1 on:** January 30, 2019, 05:15:56 am »

The one big thing I think would go down well is defaulting to no Glamor - disabling it transformed my device from alpha-quality to daily driver. It's a massive improvement in performance - scrolling feels as smooth as full size laptops afterwards. You do lose Chromium and VLC, but considering how well Firefox works with Glamor off I think it's a worthy default. Also needs a new login screen as sddm doesn't take kindly to it, so maybe too big a change for TP3...

Other smaller things:
- https://www.oesf.org/forum/index.php?showtopic=35185 (better to build from source and disable acceleration) - can't imagine using Gemini without this
- I've found a vertical panel works well, not something I'd normally use but it feels natural on the Gemini. (I don't think you need two bars, one double-width icon-only one is plenty)
- I can't remember if it's in already, but I've got lxqt-runner bound to alt+space, nicer than the fiddly start menu imo

Eric BF · « **Reply #2 on:** January 30, 2019, 05:41:19 am »

Quote from: Kiriririn

The one big thing I think would go down well is defaulting to no Glamor - disabling it transformed my device from alpha-quality to daily driver.

How do you disable Glamor? I would like to try. Thanks.

Kiriririn · « **Reply #3 on:** January 30, 2019, 06:33:24 am »

Quote from: Eric BF

Quote from: Kiriririn
The one big thing I think would go down well is defaulting to no Glamor - disabling it transformed my device from alpha-quality to daily driver.
How do you disable Glamor? I would like to try. Thanks.

I believe I rebuilt xf86-video-hwcomposer without --enable-glamor-hybris, cant remember if there was more to it than that

Eric BF · « **Reply #4 on:** January 30, 2019, 06:43:25 am »

Ah, okay; I was hoping to avoid having to build anything from source. (used to do this all the time in the old days of Linux in the 90s mind you...)

jornada720 · « **Reply #5 on:** January 30, 2019, 08:49:13 am »

Any chance you could fix the KDE keyboard situation?

It's soooo much more powerful and better suited for the high-dpi screen than LxQT. Among its many advantages, you can actually use the taskbar. Icons can be probably sized as well.

Kiriririn · « **Reply #6 on:** January 30, 2019, 12:12:19 pm »

Quote from: jornada720

Any chance you could fix the KDE keyboard situation?

It's soooo much more powerful and better suited for the high-dpi screen than LxQT. Among its many advantages, you can actually use the taskbar. Icons can be probably sized as well.

I've got no issues with DPI scaling on lxqt, it works excellently

I have the following env vars set:

GDK_DPI_SCALE=1.75
GTK_CSD=0
GTK_OVERLAY_SCROLLING=1
QT_AUTO_SCREEN_SCALE_FACTOR=1
XCURSOR_SIZE=48

And xdefaults

Xft.dpi: 192
Xcursor.size: 48

And 96 dpi set in lxqt

Basically all from https://wiki.archlinux.org/index.php/HiDPI

TheKit · « **Reply #7 on:** January 30, 2019, 02:04:58 pm »

Quote from: Kiriririn

Quote from: Eric BF
How do you disable Glamor? I would like to try. Thanks.
I believe I rebuilt xf86-video-hwcomposer without --enable-glamor-hybris, cant remember if there was more to it than that

It can be disabled by setting Option "AccelMethod" "None" in the device section of /etc/X11/xorg.conf, for example:

Quote

Section "Device"
Identifier "MediaTek HWC"
Driver "hwcomposer"
Option "AccelMethod" "None"
EndSection

If you update to latest libhybris and xf86-video-hwcomposer from Gemian repos, chromium will still work, but with color channels flipped. Might be interesting to compare performance though. If it is really much better without glamor, we could look into dri3 support without glamor, which would allow EGL applications to still work, although a bit slower due to buffer copy involved.

Kiriririn · « **Reply #8 on:** January 30, 2019, 02:17:25 pm »

Quote from: TheKit

Quote from: Kiriririn
Quote from: Eric BF
Quote from: Kiriririn
The one big thing I think would go down well is defaulting to no Glamor - disabling it transformed my device from alpha-quality to daily driver.
How do you disable Glamor? I would like to try. Thanks.

I believe I rebuilt xf86-video-hwcomposer without --enable-glamor-hybris, cant remember if there was more to it than that
It can be disabled by setting Option "AccelMethod" "None" in the device section of /etc/X11/xorg.conf, for example:
Quote
Section "Device"
Identifier "MediaTek HWC"
Driver "hwcomposer"
Option "AccelMethod" "None"
EndSection
If you update to latest xf86-video-hwcomposer from Gemian repos, chromium will still work, but with color channels flipped. Might be interesting to compare performance though. If it is really much better without glamor, we could look into dri3 support without glamor, which would allow EGL applications to still work, although a bit slower due to buffer copy involved.

That would be a good idea if possible

I've done a lot of work with gl + mali on android, it's borderline impossible to upload textures without heavy stalling using the standard GLES userspace api (even with pixel buffers etc), as glamor is doing (or was when I last checked). It must be possible at some level though for android itself and apps using things like hardwarebuffer/graphicbuffer to be unaffected

TheKit · « **Reply #9 on:** January 30, 2019, 02:33:06 pm »

Quote from: Kiriririn

That would be a good idea if possible

I've done a lot of work with gl + mali on android, it's borderline impossible to upload textures without heavy stalling using the standard GLES userspace api (even with pixel buffers etc), as glamor is doing (or was when I last checked). It must be possible at some level though for android itself and apps using things like hardwarebuffer/graphicbuffer to be unaffected

Would be nice to have some comparisons/measurements beforehand though. I think when you last used glamor it was a bit slower than current due to glFinish hack from Rockchip.

The ultimate solution is switching to Wayland, as then the compositor renders with GLES and it is fast even with texture uploads for shmem windows, but that's outside of TP3 scope. The problem with Wayland though is that there is no standard server implementation like Xorg, each compositor is an implementation of its own.

mithrandir · « **Reply #10 on:** January 30, 2019, 02:51:49 pm »

With switching to Wayland we would loose X11 and many applications with it. This would be nearly the same as switching to Sailfish. So I would vote against it.

mithrandir · « **Reply #11 on:** January 30, 2019, 02:54:01 pm »

Any chance to get cameras and GPS?

mithrandir · « **Reply #12 on:** January 30, 2019, 03:08:55 pm »

Maybe it is worth to wait until the Android update. There might be a chance for a 4.x kernel with it. Well, or does anybody know the upcoming Oreo update sticks with the 3.18 kernel?

Anyways, the kernel should be upgraded (if not already happened, I am using a custom one) to current git. The latest fix, disabling the keyboard on lid close works quite well. Before, when recognizing the Gemini in the pocket getting hot, already a quarter of battery juice has been lost...

TheKit · « **Reply #13 on:** January 30, 2019, 03:21:26 pm »

Quote from: mithrandir

With switching to Wayland we would loose X11 and many applications with it. This would be nearly the same as switching to Sailfish. So I would vote against it.

Desktop Wayland compositors have XWayland support, which is basically running Xorg server on top of Wayland and it works pretty good. It is just Sailfish choose not to support legacy apps for obvious reasons.

Quote from: mithrandir

Any chance to get cameras and GPS?

For cameras, either libcamera_compat_layer from Ubuntu Touch or gst-droid from Sailfish can be used as middleware, but then we need respective camera app ported. For GPS, are there actually any "desktop" apps capable of utilizing it?

Quote from: mithrandir

Maybe it is worth to wait until the Android update. There might be a chance for a 4.x kernel with it. Well, or does anybody know the upcoming Oreo update sticks with the 3.18 kernel?

Anyways, the kernel should be upgraded (if not already happened, I am using a custom one) to current git. The latest fix, disabling the keyboard on lid close works quite well. Before, when recognizing the Gemini in the pocket getting hot, already a quarter of battery juice has been lost...

It sticks with 3.18 as MediaTek did not port mt6797 support onto 4.x.

mithrandir · « **Reply #14 on:** January 30, 2019, 03:32:34 pm »

@TheKit:
Thanks, good to know.

Then (obviously) I would also like the Wayland solution, but as you told, this would be too much for TP3. The kernel part is a bit unfortunate, really hoped for an update. 3.18 is pretty much EOL... Also hoped for a newer kernel fixing the sd card performance after sleep issue, present in both, Android and Debian.

Regarding GPS apps, it should be possible to run navit on the gemini, still using this on my old n900, but there are quite some more, i.e. kismet supports GPS, via gpsd if I remember correctly.

News:

Author Topic: Final call for TP3 (Read 44290 times)