StarLabsLtd / firmware

73 stars 5 forks source link

Wayland completely unusable on new StarLite V (arch linux) #181

Open isomorphian opened 3 months ago

isomorphian commented 3 months ago

I have just received my StarLite V and so far have had nothing but issues. I have 5 other intel-based devices running Hyprland with no issues. On this device, running Hyprland, any graphical application will crash after about 30 seconds.

In addition, with either Gnome or KDE on wayland, the desktop environment will flicker uncontrollably before crashing after about 30 seconds.

Also, I am experiencing random kernel panics running the stock Arch kernel.

I have had somewhat better experience running X11. Apps will not crash, although every so often, upon starting the X server, the device will lock up completely, and not even allow me to switch virtual terminals. The only way out of this situation is to cut the power by holding the power button.

I am on the latest firmware that was just released to solve the intermittent touchscreen issue.

Sean-StarLabs commented 3 months ago

kernel 6.9 by any chance?

isomorphian commented 3 months ago

kernel 6.9 by any chance?

Yes, 6.9.7-arch1-1 installed with the "linux" package on arch

Sean-StarLabs commented 3 months ago

6.9 has bugs; should be fine if you use 6.8 instead

thmichel commented 3 months ago

Works well with Fedora Kernel 6.9.7 by the way.

isomorphian commented 3 months ago

Thank you for the information. I'm out of town for a few days but when I get back I will try downgrading my kernel.

I'm glad to hear things are working better on Fedora. I'd prefer to stay on Arch because that's what I'm most familiar with, but I'm glad to know that's an option.

stronnag commented 3 months ago

It continues with the latest Arch updates (6.9.8-zen1-1-zen), the journal reporting:

Jul 06 08:26:55 piglet kernel: i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080

Though not as frequently as previously.

PhilT commented 2 months ago

I'm using Wayland on NixOS with Kernel 6.9.7. No flickering problems that I've noticed so far. I do have animations off though but I'll check it out with them on.

isomorphian commented 2 months ago

Seems that the problem is in libwayland-client.so

I noticed that applications only crash after being interacted with via touchscreen. As long as I do not touch the screen at all, there are no problems. But if I interact with applications via touchscreen, they will continue to function for about 30 seconds before crashing.

I recorded a crash in Rnote, and a crash in Firefox.

Dmesg reports this message upon Rnote crashing: rnote[843]: segfault at 603aa950dc8d ip 0000790883a122af sp 00007ffe3dda1e40 error 4 in libwayland-client.so.0.23.0[790883a0d000+6000] likely on CPU 0 (core 0, socket 0)

Dmesg reports another, similar message upon Firefox crashing: traps: crashreporter[1349] general protection fault ip:764328dcfcc4 sp:7ffde78d7ff8 error:0 in libwayland-client.so.0.23.0[764328dce000+6000]

isomorphian commented 2 months ago

apologies for closing and reopening. I have never submitted an issue before, I did not realize how it worked.

isomorphian commented 2 months ago

Ack! Sorry !

isomorphian commented 2 months ago

I tried all three officially supported Arch Linux kernels:

linux 6.9.8 linux-zen 6.9.8 linux-lts 6.6.38

None of them make any difference.

Is it possible that there is some firmware that this device requires, which is not included in the linux-firmware package?

isomorphian commented 2 months ago

Interestingly, this does not affect all applications on my machine, but it does affect most of them.

Apps that crash upon touch input: Firefox Rnote LibreOffice Pavucontrol Thunar File Manager PCManFM (GTK3 version)

Apps that do not crash upon touch input: KeepassXC Blueman GNU Octave PCManFM (QT6 version) qBittorrent Discord

isomorphian commented 2 months ago

Just finished recovering my system from a kernel panic that interrupted a system upgrade. This machine really is not happy to be running Arch Linux.

isomorphian commented 2 months ago

I think the kernel panics during system upgrade could be an upstream issue with Arch, according to this forum post:

https://forum.endeavouros.com/t/kernel-panic-during-update-broke-my-system-thanks-god-and-linux-community-for-the-arch-chroot/51839/20?page=3

(they are talking about Endeavour, not Arch, but close enough to make me think it could be upstream issue)

Although I have never had this happen on any of my other machines that are also running Arch (and those installs are way more bloated than my StarLite) so I don't know.

isomorphian commented 2 months ago

I made the mistake of enabling gdm.service to see if starting Gnome that way would work. But I should have started it instead of enabling. Now I am trapped inside a completely unusable Gnome that freezes my system after a few seconds of runtime. Impossible to get to a terminal. Have to boot into recovery USB for the 50th time since I got this machine.

isomorphian commented 2 months ago

Both Gnome and KDE Plasma on wayland are completely unusable, only way to escape is to power off. This is not good. Wayland is the default option.

They start fine on X11 but have issues with the pointer not tracking the pen correctly.

isomorphian commented 2 months ago

i3 and awesomewm seem to work fine on X11 although the pen is lacking pressure-sensitivity.

Hyprland is broken, but I say that's probably their fault anyways.

Interestingly, Sway seems to work perfectly! :)

diggit commented 2 months ago

@isomorphian I am also on archlinux with same issues. In KDE/Gnome on wayland, workaround is to disable "ghost" output. Then the flickering stopped. SDDM probably also has some way of output configuration to apply the same same workaround.

Due to some reason, these DEs and SDDM (and probably more) see this Unknown-1 output and try to use it.

Contents of /sys/class/drm/, notice the coreboot8/simple-framebuffer.0

card0 -> ../../devices/platform/BOOT0000:00/coreboot8/simple-framebuffer.0/drm/card0/
card0-Unknown-1 -> ../../devices/platform/BOOT0000:00/coreboot8/simple-framebuffer.0/drm/card0/card0-Unknown-1/
card1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/
card1-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1/
card1-DP-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2/
card1-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/
card1-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-1/
card1-HDMI-A-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-2/
card1-HDMI-A-3 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-3/
renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128/
isomorphian commented 2 months ago

@isomorphian

I am also on archlinux with same issues.

In KDE/Gnome on wayland, workaround is to disable "ghost" output. Then the flickering stopped. SDDM probably also has some way of output configuration to apply the same same workaround.

Due to some reason, these DEs and SDDM (and probably more) see this Unknown-1 output and try to use it.

Contents of /sys/class/drm/, notice the coreboot8/simple-framebuffer.0


card0 -> ../../devices/platform/BOOT0000:00/coreboot8/simple-framebuffer.0/drm/card0/

card0-Unknown-1 -> ../../devices/platform/BOOT0000:00/coreboot8/simple-framebuffer.0/drm/card0/card0-Unknown-1/

card1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/

card1-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1/

card1-DP-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2/

card1-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/

card1-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-1/

card1-HDMI-A-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-2/

card1-HDMI-A-3 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-3/

renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128/

Interesting. I also noticed that Unknown-1 device, and I had assumed it had to do with the touchscreen. I'll experiment with this when I get home.

TheJackiMonster commented 2 months ago

I might have found a cause for this... potentially. I had some issue running into a framebuffer problem during boot (which appeared in log from dmesg). So I added the i915 module to /etc/mkinitcpio.conf for early KMS start. Now my issue during boot is gone but I encounter heavy flickering in my Wayland session. Didn't happen before that.

So my guess is that it's coming from this module...

_Edit: It seems like using the linux-lts kernel solves the flickering for me when using the early KMS. Otherwise I suspect it to be related to the PSR feature with selective regions. But disabling the option didn't do much for me._

stronnag commented 2 months ago

The Arch Testing / Zen kernels (6.9.x) do not work well on the Starlite V. The AUR LQX kernel (6.9.9) works very, very well (Wayland, Gnome). No flickering etc. Touch and GJS OSK are stable and predictable. Bit of pain to build the kernel from source, but it was worth it.

isomorphian commented 2 months ago

@stronnag Thank you! This solved all my problems.

I wonder what's different in the Liquorix kernel vs the official Arch kernels. Whatever it is, is working great!

TheJackiMonster commented 2 months ago

I wonder what's different in the Liquorix kernel vs the official Arch kernels. Whatever it is, is working great!

Tested the linux-rt kernel now and it seems to work fine. So that might be a potential option which is pre-built in the official repositories.

stronnag commented 2 months ago

I wonder what's different in the Liquorix kernel vs the official Arch kernels. Whatever it is, is working great!

Tested the linux-rt kernel now and it seems to work fine. So that might be a potential option which is pre-built in the official repositories.

Any Arch kernel prior to 6.9 will work. I'd prefer LTS or 6.8.9 over -rt any day,

isomorphian commented 2 months ago

I wonder what's different in the Liquorix kernel vs the official Arch kernels. Whatever it is, is working great!

Tested the linux-rt kernel now and it seems to work fine. So that might be a potential option which is pre-built in the official repositories.

Any Arch kernel prior to 6.9 will work. I'd prefer LTS or 6.8.9 over -rt any day,

Last time I tested LTS it had the same issues, but I'll give it another shot.

andrewwebber commented 2 months ago

Just adding my two pence:

Use Arch BTW with Sway/Warbar. Installed using archinstall and selecting minimal + sway. No complaints as Wayland works no less usable than on my desktop hardwares (e.g. full screen Slack crashes on both).

However I found it impossible to get VLC Player working on the Starlite. As a workaround mpv was recommended and worked perfectly.

DavidG-Ghb commented 2 weeks ago

Starlite V on Manjaro. Kernel 6.6 LTS works. 6.8 was working, but Manjaro have dropped support, so had to revert to 6.6. Current kernels 6.9, 6.10 and the experimental 6.11 all have the black flickering issues with Wayland. Slightly concerning that this issue remains in newer kernels, which suggests there could be issues with long term support for the Starlite V.

A workaround would be welcome.

Sean-StarLabs commented 2 weeks ago

On 24.08?

stronnag commented 2 weeks ago

This still occurs with Arch 6.9. 6.10 kernels on 24.08.

It does not occur with the Arch "lqx" 6.10 kernels (which, AFAIK, are build with Debian build flags). So it is probably an Arch (and derivatives) build issue rather than an upstream kernel issue.

DavidG-Ghb commented 2 weeks ago

Yes, tested on 24.08

isomorphian commented 2 weeks ago

I've been using lqx from the AUR with no problems, but the official arch kernels all have the same problems as when I originally posted this issue, with many graphical apps and environments causing screen flickering and kernel panics.