[star2lte] Desktop freezes when plugging into DEX

[countnoobula]

Hey everyone

I'm new to this environment and recently got a DEX and decided to use my old Samsung Galaxy S9+ to play with.

I flashed successfully through TWRP, but when I plugged it in through DEX, it freezes with a few white rectangles on a black background.

Could anyone advise if there is something I could do to solve this please?

[pdsouza]

Unfortunately this is a known issue for star2lte that we weren't able to track down. Our maintainer is @dianaxxyyzz, who may have an older image he can share with you without the freezing issue.

[solarchemist]

I'm pretty sure I can confirm the existence of this major issue on Galaxy S9+ (star2lte). But I wouldn't characterise it as frozen, more like the desktop is poorly rendered. I have been testing an S9+ with the latest MaruOS release a lot over the holiday, and sometimes parts of the XFCE desktop (most often the top bar with clock) is rendered OK. Other times it's just big white rectangles. But the desktop is never responsive, although the mouse pointer is always visible and can be moved around. But just to be clear, no responsiveness to left clicks, right clicks or anything else I tried.

Note that I am not using the official DeX hardware (I was hoping this issue was limited to it). In fact, I have tested two different USB-C-to-HDMI adapters, with two different HDMI cables, on three different model monitors, and the behaviour is the same in all cases (unresponsive desktop, at worst white rectangles instead of top bar and dock, at best visible top bar, black background and always a movable mouse pointer).

But what makes this issue interesting is that the XFCE desktop is rendered perfectly fine when you connect via VNC (enable SSH via ADB and then VNC, just as described on the Tips page). Now I don't know enough about X11 and whatnot to theorise on what could be going on, but intuitively it feels like if the desktop works normally over VNC, then why should it not over a physical connection?

For reference, below are my observations (like the proverbial blind hen, I leave it to others to determine if there are any valuable nuggets among the gravel).

@pdsouza But first, I must ask: do any older imagesfor star2lte exist (predating this issue), and where could I get a copy? If I understand the release notes correctly, this issue is known to affect all MaruOS releases since 0.6.3, but earlier releases do not feature any star2lte image? And @dianaxxyyzz seems to no longer use that username? Getting a Linux desktop via cable from the phone, even if on an old Android version, would be better for me than having to abandon the PC-in-your-pocket concept and just install regular LineageOS.

I just recently heard about Andronix and UserLand, but as far as I can tell they both support only VNC connections, thus always requiring another computer to connect from. That makes them poor replacements for Maru, except for S9+ of course where all three projects appear limited to VNC connections at present ;-)

And now, the details (to avoid too much output, I have removed most uninteresting lines, and replaced with ellipsis).

taha@asks2:~
$ adb root
restarting adbd as root
$ adb shell
star2lte:/ # lxc-start -n default
lxc-start: external/lxc/src/lxc/conf.c: mk_devtmpfs: 1379 /dev/.lxc is not setup - taking fallback
                                                                                                  systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization lxc.
Detected architecture arm64.
[...]
sys-kernel-debug.mount: Cannot add dependency job, ignoring: Unit sys-kernel-debug.mount is masked.
container-getty@0.service: Cannot add dependency job, ignoring: Unit container-getty@0.service is masked.
container-getty@4.service: Cannot add dependency job, ignoring: Unit container-getty@4.service is masked.
container-getty@3.service: Cannot add dependency job, ignoring: Unit container-getty@3.service is masked.
container-getty@2.service: Cannot add dependency job, ignoring: Unit container-getty@2.service is masked.
container-getty@1.service: Cannot add dependency job, ignoring: Unit container-getty@1.service is masked.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Listening on Journal Socket.
[...]
[  OK  ] Reached target Paths.
         Starting Remount Root and Kernel File Systems...
dev-hugepages.mount: Couldn't determine result for ConditionVirtualization=!private-users, assuming failed: No such file or directory
[  OK  ] Started Load Kernel Modules.
[...]
Debian GNU/Linux 9 stretch console
Linux stretch 4.9.133+ #1 SMP PREEMPT Tue Oct 8 02:27:40 UTC 2019 aarch64
[...]
maru@stretch:~$ sudo apt update
82 packages can be upgraded. 
maru@stretch:~$ sudo apt full-upgrade
maru@stretch:~$ sudo apt autoremove

At this point, I installed nano and took a look in the ~/.xsession-errors file:

/usr/bin/x-session-manager: X server already running on display :0
/etc/xdg/xfce4/xinitrc: 85: /etc/xdg/xfce4/xinitrc: xrdb: not found
** (xfce4-session:105): CRITICAL **: polkit_unix_process_set_property: assertion 'val != -1' failed
sh: 1: /usr/bin/iceauth: not found
(xfce4-session:105): xfce4-session-WARNING **: Failed to setup the ICE authentication data, session management might not work prop$
xfce4-session-Message: SSH authentication agent is already running
[...]
(xfce4-session:105): xfce4-session-WARNING **: xfsm_manager_load_session: Something wrong with /home/maru/.cache/sessions/xfce4-se$
(xfce4-session:105): xfce4-session-WARNING **: ICE connection 0x5b55a2d4d0 rejected
xfce4-panel: Failed to connect to session manager: Failed to connect to the session manager: Authentication Rejected, reason : Non$

Perhaps we can do something about the xrdb not found error. xrdb is part of the x11-xserver-utils package, which was not installed. So I installed it, and restarted MaruOS Desktop.
Opened ~/.xsession-errors again, and interestingly, the xrdb error is gone and we have a new error among the familiar ones:

/usr/bin/x-session-manager: X server already running on display :0
** (xfce4-session:121): CRITICAL **: polkit_unix_process_set_property: assertion 'val != -1' failed
xfce4-session-Message: SSH authentication agent is already running
[...]
(xfce4-session:121): xfce4-session-WARNING **: xfsm_manager_load_session: Something wrong with /home/maru/.cache/sessions/xfce4-session-stretch:0, Does it exist? Permissions issue?
(xfsettingsd:141): xfsettingsd-WARNING **: Failed to get the _NET_NUMBER_OF_DESKTOPS property.
(xfwm4:131): xfwm4-WARNING **: Error opening /dev/dri/card0: No such file or directory
(xfce4-panel:135): Gtk-CRITICAL **: IA__gtk_widget_show: assertion 'GTK_IS_WIDGET (widget)' failed

I took a look at the /var/log/Xorg.0.log file, and found these lines that appear related:

[    87.404] (II) AIGLX: Screen 0 is not DRI2 capable
[    87.404] (EE) AIGLX: reverting to software rendering
[    87.404] (EE) AIGLX error: dlopen of /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/aarch64-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
[    87.404] (EE) GLX: could not load software renderer
[    87.404] (II) GLX: no usable GL providers found for screen 0

I thought I could give it a try to fix the DRI error, since it is mentioned in both logs.
Found out which package the DRI drivers are part of (had to apt install apt-file first):

maru@stretch:~$ sudo apt-file search /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so
libgl1-mesa-dri: /usr/lib/aarch64-linux-gnu/dri/swrast_dri.so

Note that the package libgl1-mesa-dri was not installed (but libgl1-mesa-glx was installed):

maru@stretch:~$ sudo apt install libgl1-mesa-dri
The following NEW packages will be installed:
  libdrm-freedreno1 libgl1-mesa-dri libllvm3.9 libsensors4 libtxc-dxtn-s2tc
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.

After a MaruOS Desktop restart, the ~/.xsession-errors file still contains the exact same line about DRI, but /var/log/Xorg.0.log looks better than before (no longer says "error could not load"):

[   134.074] (II) AIGLX: Screen 0 is not DRI2 capable
[   134.074] (EE) AIGLX: reverting to software rendering
[   134.098] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
[   134.098] (II) IGLX: Loaded and initialized swrast
[   134.099] (II) GLX: Initialized DRISWRAST GL provider for screen 0

No difference in the desktop's behaviour though. All in all, perhaps these warnings/errors about DRI were not consequential.

Finally, I tried to reinstall all Xorg driver packages (following the suggestion of this forum post).

First, I identified which xorg packages were installed:

maru@stretch:~$ dpkg -l | grep xserver-xorg
ii  xserver-xorg                   1:7.7+19                          arm64        X.Org X server
ii  xserver-xorg-core              2:1.19.2-1+deb9u8                 arm64        Xorg X server - core server
ii  xserver-xorg-input-all         1:7.7+19                          arm64        X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput    0.23.0-2                          arm64        X.Org X server -- libinput input driver
ii  xserver-xorg-video-all         1:7.7+19                          arm64        X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu      1.2.0-1+b1                        arm64        X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati         1:7.8.0-1+b1                      arm64        X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-dummy       1:0.3.8-1                         arm64        X.Org X server -- dummy display driver
ii  xserver-xorg-video-fbdev       1:0.4.4-1+b3                      arm64        X.Org X server -- fbdev display driver
ii  xserver-xorg-video-nouveau     1:1.0.13-3                        arm64        X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-radeon      1:7.8.0-1+b1                      arm64        X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa        1:2.3.4-1+b2                      arm64        X.Org X server -- VESA display driver

Then went ahead and forced a reinstall:

$ sudo apt install --reinstall xserver-xorg-video-all xserver-xorg-video-amdgpu xserver-xorg-video-ati xserver-xorg-video-dummy xserver-xorg-video-fbdev xserver-xorg-video-nouveau xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-core

Then

$ sudo dpkg-reconfigure xserver-xorg

But this command produced no output at all, no indication of it doing anything. Too bad.

In summary, all of the above made no difference in the end. The desktop is broken in just the same way as before. Maybe the DRI fix was a necessary but incomplete fix of the main issue? Or in the worst case it's completely irrelevant. I hope others will pick up and pull at this thread.

[chitucgeorgian83]

Just use this files

Desktop linux image is Ubuntu 16.04 arch64 .

Here is the zip you have to flash via TWRP .

https://androidfilehost.com/?fid=11410963190603842634

Also for all lineage os based roms ,for S9+ , you need your vendor files to be BRE5 or camera will not work.

https://androidfilehost.com/?fid=674106145207489374

[solarchemist]

Thanks, you really helped me out! The archive and image you provided work great.

My only complaint (I know, complaints never end) is that I could not figure out how to route sound through the HDMI connection (in order for the sound to play from the monitor's built-in speakers). Will have to connect an audio cable from the 3.5mm jack to the monitor for now.
But I did find this previous issue on the same question. Unfortunately I wasn't really able to follow along in the long thread on Google Groups. Perhaps @pdsouza would like to put down a few pointers on this matter in the MaruOS FAQ? Like, is it indeed possible to route sound via the HDMI cable, and if so, what are the requirements (MaruOS version? Maru container distro (Debian? Ubuntu?), etc.).

Anyway, much better than no desktop at all. Thanks all!

I learned two new things about MaruOS, which may be others can benefit from:

1. Don't attempt to rename the maru Linux user account. Will not work, everything ends up owned by aid_system instead, and subsequent chown ... had no effect.
2. If you create a new user account, make sure it belongs to all the groups that the maru user belongs to, otherwise you will have no networking at all (nor other stuff, but lack of networking is most obvious).

Hope more people find this project, it's still a little rough around the edges, but it's awesome :-)