[BUG] Screen keyboard can’t launch on weston / wayland backend

[umeiko]

What happened?

When I launched KlipperScreen Under Weston, the screen keyboard can’t show up. Both in Wifi password ui and console ui. The screen will stuck and can’t do anything.

What did you expect to happen instead?

Screen keyboard should launch but not.

How to reproduce this bug?

In some system, wayland is the only back-end to use. X11 are not fully supported. you can reproduce this case by : apt install weston xwayland then make a start_ks.sh

#!/bin/bash

export XDG_RUNTIME_DIR=/tmp
weston-launch < /dev/tty1 > /dev/tty1 2>&1 &
sleep 2
/home/user/.KlipperScreen-env/bin/python /home/user/KlipperScreen/screen.py

sudo start_ks.sh

Additional information:

Tested on Ubuntu 20.04

Log output

Log output nothing, but screen just stucked.

[umeiko]

2024-03-10 00:56:08,710 [printer.py:reinit()] - Klipper version: v0.12.0-286-g11bbde5a
2024-03-10 00:56:08,712 [printer.py:reinit()] - # Extruders: 0
2024-03-10 00:56:08,712 [printer.py:reinit()] - # Temperature devices: 0
2024-03-10 00:56:08,713 [printer.py:reinit()] - # Fans: 0
2024-03-10 00:56:08,713 [printer.py:reinit()] - # Output pins: 0
2024-03-10 00:56:08,714 [printer.py:reinit()] - # Leds: 0
2024-03-10 00:56:08,753 [KlippyRest.py:_do_request()] - Sending request to http://127.0.0.1:7125/printer/gcode/help
2024-03-10 00:56:08,758 [KlippyWebsocket.py:object_subscription()] - Sending printer.objects.subscribe
2024-03-10 00:56:08,983 [KlippyRest.py:_do_request()] - Sending request to http://127.0.0.1:7125/printer/objects/query?bed_mesh&configfile&display_status&extruder&fan&gcode_move&heater_bed&idle_timeout&pause_resume&print_stats&toolhead&virtual_sdcard&webhooks&motion_report&firmware_retraction&exclude_object&manual_probe
2024-03-10 00:56:09,000 [files.py:initialize()] - Gcodes path: /home/umeko/printer_data/gcodes
2024-03-10 00:56:09,007 [KlippyWebsocket.py:get_file_list()] - Sending server.files.list
2024-03-10 00:56:09,016 [screen.py:init_printer()] - Printer initialized
2024-03-10 00:56:09,020 [printer.py:change_state()] - Changing state from 'disconnected' to 'error'
2024-03-10 00:56:09,021 [printer.py:change_state()] - Adding callback for state: error
2024-03-10 00:56:09,079 [screen.py:show_panel()] - Reinitializing panel
2024-03-10 00:56:09,238 [screen.py:attach_panel()] - Current panel hierarchy: splash_screen
2024-03-10 00:56:45,926 [screen.py:_go_to_submenu()] - #### Go to submenu
2024-03-10 00:56:45,927 [screen.py:_go_to_submenu()] - #### Menu __splashscreen
2024-03-10 00:56:45,944 [screen.py:_load_panel()] - Loading panel: menu
2024-03-10 00:56:46,404 [menu.py:evaluate_enable()] - moonraker connected True
2024-03-10 00:56:48,250 [screen.py:attach_panel()] - Current panel hierarchy: splash_screen >
2024-03-10 00:56:48,266 [menu.py:arrangeMenuItems()] - X > power
2024-03-10 00:56:48,275 [menu.py:evaluate_enable()] - moonraker connected True
2024-03-10 00:56:49,127 [screen.py:_load_panel()] - Loading panel: network
2024-03-10 00:56:49,185 [network.py:__init__()] - Found wireless interfaces: ['wlan0']
2024-03-10 00:56:49,186 [network.py:__init__()] - Using NetworkManager
2024-03-10 00:56:49,962 [screen.py:attach_panel()] - Current panel hierarchy: splash_screen >  > network
2024-03-10 00:56:50,852 [functions.py:logging_exception_handler()] - Uncaught exception <class 'KeyError'>: '小米共享WiFi_DB0E'
  File "/home/umeko/KlipperScreen/panels/network.py", line 110, in load_networks
    self.add_network(net, False)

  File "/home/umeko/KlipperScreen/panels/network.py", line 130, in add_network
    netinfo = self.wifi.get_network_info(ssid)

  File "/home/umeko/KlipperScreen/ks_includes/wifi_nm.py", line 224, in get_network_info
    path = self.path_by_ssid[ssid]
NoneType: None
2024-03-10 00:56:50,856 [functions.py:logging_exception_handler()] - Uncaught exception <class 'KeyError'>: '小米共享WiFi_DB0E'
  File "/home/umeko/KlipperScreen/panels/network.py", line 110, in load_networks
    self.add_network(net, False)

  File "/home/umeko/KlipperScreen/panels/network.py", line 130, in add_network
    netinfo = self.wifi.get_network_info(ssid)

  File "/home/umeko/KlipperScreen/ks_includes/wifi_nm.py", line 224, in get_network_info
    path = self.path_by_ssid[ssid]
NoneType: None
2024-03-10 00:56:54,292 [keyboard.py:__init__()] - Keyboard es

[umeiko]

KlipperScreen just stucked after 2024-03-10 00:56:54,292 [keyboard.py:__init__()] - Keyboard es

[umeiko]

Also, there's some problem with Chinese characters in SSID, but not related to this issue.

[alfrix]

i've just tested it on my pi, and performance under weston is terrrible, the keyboard opens then the screen freezes, according to the logs it still responding, but the framebuffer gets stuck, to me this is not an issue with klipperscreen or wayland, since other compositors work correctly, for example i develop under kde with wayland, and i've tested cage (uses wlroots) and it also works as expected

regarding the other issue, there is a new network backend that will be merged shortly, that is more robust but not tested against foreign chars, but should work since i used bssid for the keys, but the merge is planned to be in june since i've already put a notice for deprecation.

[umeiko]

Maybe I should use another wayland software, not using weston. Do you have any suggestions?

[alfrix]

In some system, wayland is the only back-end to use. X11 are not fully supported.

that is wrong, it's the opposite, the only distro that has announced dropping X11 is Fedora 40, and that is not even released yet.

Maybe I should use another wayland software, not using weston. Do you have any suggestions?

You are using Ubuntu 20.04 that's an operating system from 4 years ago, use X11.

I've been trying Wayland on a rolling release, going back and forth, only in the last months it started to have enough stability and ecosystem to be usable, do not force the transition, To use Ubuntu with Wayland i would recommend that you wait for 24.04

[umeiko]

That's because I'm working on postmarketOS's kernel, porting them on some android phones. some X11 functions don't working well beceuse of the drm and gpu drivers are unstable. But wayland have better performance on these kernels. You're right that ubuntu 20.04 may not a good choice. Thank you !

[alfrix]

That's because I'm working on postmarketOS's kernel, porting them on some android phones. some X11 functions don't working well beceuse of the drm and gpu drivers are unstable. But wayland have better performance on these kernels. You're right that ubuntu 20.04 may not a good choice. Thank you !

wayland require drm drivers, x11 can use them but cal also use the old style userspace ones, with a modern enough distro i would recommend trying out cage #1289 as it seems to be the most lightweight solution