OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio

IPB

Welcome Guest ( Log In | Register )

6 Pages V   1 2 3 > »   
Reply to this topicStart new topic
> Final call for TP3
Adam Boardman
post Jan 30 2019, 12:31 AM
Post #1





Group: Members
Posts: 173
Joined: 29-December 17
Member No.: 815,489



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?
Go to the top of the page
 
+Quote Post
Kiriririn
post Jan 30 2019, 02:15 AM
Post #2





Group: Members
Posts: 67
Joined: 19-January 18
Member No.: 816,673



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
Go to the top of the page
 
+Quote Post
Eric BF
post Jan 30 2019, 02:41 AM
Post #3





Group: Members
Posts: 78
Joined: 25-June 18
Member No.: 824,997



QUOTE(Kiriririn @ Jan 30 2019, 10:15 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.

How do you disable Glamor? I would like to try. Thanks.
Go to the top of the page
 
+Quote Post
Kiriririn
post Jan 30 2019, 03:33 AM
Post #4





Group: Members
Posts: 67
Joined: 19-January 18
Member No.: 816,673



QUOTE(Eric BF @ Jan 30 2019, 11:41 AM) *
QUOTE(Kiriririn @ Jan 30 2019, 10:15 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.

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
Go to the top of the page
 
+Quote Post
Eric BF
post Jan 30 2019, 03:43 AM
Post #5





Group: Members
Posts: 78
Joined: 25-June 18
Member No.: 824,997



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...)
Go to the top of the page
 
+Quote Post
jornada720
post Jan 30 2019, 05:49 AM
Post #6





Group: Members
Posts: 81
Joined: 8-March 18
Member No.: 818,918



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.
Go to the top of the page
 
+Quote Post
Kiriririn
post Jan 30 2019, 09:12 AM
Post #7





Group: Members
Posts: 67
Joined: 19-January 18
Member No.: 816,673



QUOTE(jornada720 @ Jan 30 2019, 02:49 PM) *
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
Go to the top of the page
 
+Quote Post
TheKit
post Jan 30 2019, 11:04 AM
Post #8





Group: Members
Posts: 28
Joined: 19-February 18
Member No.: 818,021



QUOTE(Kiriririn @ Jan 30 2019, 02:33 PM) *
QUOTE(Eric BF @ Jan 30 2019, 11:41 AM) *

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.
Go to the top of the page
 
+Quote Post
Kiriririn
post Jan 30 2019, 11:17 AM
Post #9





Group: Members
Posts: 67
Joined: 19-January 18
Member No.: 816,673



QUOTE(TheKit @ Jan 30 2019, 08:04 PM) *
QUOTE(Kiriririn @ Jan 30 2019, 02:33 PM) *
QUOTE(Eric BF @ Jan 30 2019, 11:41 AM) *
QUOTE(Kiriririn @ Jan 30 2019, 10:15 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.

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
Go to the top of the page
 
+Quote Post
TheKit
post Jan 30 2019, 11:33 AM
Post #10





Group: Members
Posts: 28
Joined: 19-February 18
Member No.: 818,021



QUOTE(Kiriririn @ Jan 30 2019, 10:17 PM) *
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.
Go to the top of the page
 
+Quote Post
mithrandir
post Jan 30 2019, 11:51 AM
Post #11





Group: Members
Posts: 133
Joined: 7-January 18
Member No.: 815,997



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.
Go to the top of the page
 
+Quote Post
mithrandir
post Jan 30 2019, 11:54 AM
Post #12





Group: Members
Posts: 133
Joined: 7-January 18
Member No.: 815,997



Any chance to get cameras and GPS?
Go to the top of the page
 
+Quote Post
mithrandir
post Jan 30 2019, 12:08 PM
Post #13





Group: Members
Posts: 133
Joined: 7-January 18
Member No.: 815,997



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...
Go to the top of the page
 
+Quote Post
TheKit
post Jan 30 2019, 12:21 PM
Post #14





Group: Members
Posts: 28
Joined: 19-February 18
Member No.: 818,021



QUOTE(mithrandir @ Jan 30 2019, 10:51 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.

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(mithrandir @ Jan 30 2019, 10:54 PM) *
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(mithrandir @ Jan 30 2019, 11:08 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...

It sticks with 3.18 as MediaTek did not port mt6797 support onto 4.x.
Go to the top of the page
 
+Quote Post
mithrandir
post Jan 30 2019, 12:32 PM
Post #15





Group: Members
Posts: 133
Joined: 7-January 18
Member No.: 815,997



@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.
Go to the top of the page
 
+Quote Post

6 Pages V   1 2 3 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 12th December 2019 - 04:59 PM