lxqt-config-mon crashes on wayland except kwin_wayland
Closed this issue · 14 comments
No suprise:
$ lxqt-config-monitor
kscreen.kwayland: Connection to Wayland server timed out.
Connecting to KScreen...
Error: Config is invalid, probably backend couldn't load
At every wakeup from suspend journalctl -r shows its coredump.
Core was generated by `/usr/bin/lxqt-config-monitor -l'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fc11bca0868 in KScreen::Config::outputs() const () from /usr/lib/libKF5Screen.so.7
[Current thread is 1 (Thread 0x7fc119402840 (LWP 10822))]
e(gdb) where
#0 0x00007fc11bca0868 in KScreen::Config::outputs() const () at /usr/lib/libKF5Screen.so.7
#1 0x000055e1dc48eecf in applySettings(QSharedPointer<KScreen::Config>, QList<MonitorSettings>)
(config=..., monitors=...) at /home/stef/git/lxqt/lxqt-config/lxqt-config-monitor/loadsettings.cpp:114
#2 0x000055e1dc48e89f in operator()(KScreen::ConfigOperation*) const
(__closure=0x55e1dd2a3f40, op=0x7fc1100143b0)
at /home/stef/git/lxqt/lxqt-config/lxqt-config-monitor/loadsettings.cpp:71
#3 0x000055e1dc48f924 in QtPrivate::FunctorCall<QtPrivate::IndexesList<0>, QtPrivate::List<KScreen::ConfigOperation*>, void, LoadSettings::applyBestSettings()::<lambda(KScreen::ConfigOperation*)> >::call(struct {...} &, void **) (f=..., arg=0x7ffe03535900) at /usr/include/qt/QtCore/qobjectdefs_impl.h:146
#4 0x000055e1dc48f8e5 in QtPrivate::Functor<LoadSettings::applyBestSettings()::<lambda(KScreen::ConfigOperation*)>, 1>::call<QtPrivate::List<KScreen::ConfigOperation*>, void>(struct {...} &, void *, void **)
(f=..., arg=0x7ffe03535900) at /usr/include/qt/QtCore/qobjectdefs_impl.h:256
#5 0x000055e1dc48f8b4 in QtPrivate::QFunctorSlotObject<LoadSettings::applyBestSettings()::<lambda(KScreen::ConfigOperation*)>, 1, QtPrivate::List<KScreen::ConfigOperation*>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=1, this_=0x55e1dd2a3f30, r=0x7fc1100143b0, a=0x7ffe03535900, ret=0x0)
at /usr/include/qt/QtCore/qobjectdefs_impl.h:443
#6 0x00007fc11a6be931 in () at /usr/lib/libQt5Core.so.5
#7 0x00007fc11bc9b684 in KScreen::ConfigOperation::finished(KScreen::ConfigOperation*) ()
at /usr/lib/libKF5Screen.so.7
#8 0x00007fc11bc9c189 in () at /usr/lib/libKF5Screen.so.7
#9 0x00007fc11a6b1a70 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5
#10 0x00007fc11a68de08 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#11 0x00007fc11a68e913 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
at /usr/lib/libQt5Core.so.5
#12 0x00007fc11a6d4d48 in () at /usr/lib/libQt5Core.so.5
#13 0x00007fc11b11682b in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#14 0x00007fc11b16dcc9 in () at /usr/lib/libglib-2.0.so.0
#15 0x00007fc11b1150e2 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#16 0x00007fc11a6d8b2c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib/libQt5Core.so.5
#17 0x00007fc11a6865ac in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5
#18 0x00007fc11a6910d9 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#19 0x000055e1dc476922 in main(int, char**) (argc=2, argv=0x7ffe03535fe8)
at /home/stef/git/lxqt/lxqt-config/lxqt-config-monitor/main.cpp:48
(gdb)
Possible Solution
- Disable it with a message on wayland for now or
- using kanshi or disman backend on wayland ?
- Or using
kscreen.wayland?
Steps to Reproduce (for bugs)
- Suspend on wayland
- Check
journalctl -r
System Information
- Distribution & Version: arch, git
Just discovered the existence of https://github.com/artizirk/wdisplays. I've no multiple monitor setup but it looks working fine, so we could use that and just disable lxqt-config-monitor for screen settings on wayland.
This is no issue if running with kwin_wayland session.
A similar prevent as in lxqt/lxqt-session#468 could be done here too?
Here, the problem is in KScreen. If it can't get outputs, lxqt-config-monitor will be useless under Wayland.
To prevent crashes under Wayland, we can do as in lxqt/lxqt-session#468: prevent its calling under Wayland.
I think I should close lxqt/lxqt-session#468 and make another PR for both, with this title:"On Wayland, disable functionalities that crash".
EDIT:
Done: lxqt/lxqt-session#469
As I mentioned above: it works fine if with kwin's wayland session, so maybe the check should be against the compositor too. In my startlxqt<wayland> I set a variable $WAYLAND_COMPOSITOR.
so maybe the check should be against the compositor too.
In my opinion, we shouldn't try to compensate for others' bugs. kscreen either works with Wayland or not; it isn't supposed to work only with kwin_wayland.
Just noticed that it doesn't crash now, at least until you don't hit "save". It opens with no display to show.
Looks like solved by libkscreen 6.x now but only using kwin_wayland
see stefonarch/lxqt-kwin-session#1 (comment)
In my opinion, we shouldn't try to compensate for others' bugs.
kscreeneither works with Wayland or not; it isn't supposed to work only with kwin_wayland.
kscreen will never work outside of kwin_wayland as kwin/kscreen doesn't support wlr-output-management-unstable protocol.
Basically lxqt-config-monitor works fine with kwin_wayland, it just lacks the "DPI" scale factor per monitor which is possible under wayland only.
For wlroots based compositor we either tell users to switch to wdisplays or we implement an own backend based on that or on kanshi.
Long story made short, LXQt devs had high hopes when starting to use KWindowSystem. What has happened now is that a great part of KWindowSystem is just for X11, and most of the rest works only with kwin_wayland.
The situation on wlroots compositors is a little more complicated. All the compositors do implement the wlr-output-management-unstable. But the problem is the configuration. Nearly, all of them use their own formats, and come with their own caveats. For example, on wayfire, you can change the output properties using wdisplays when it's running, but there is no way to save these changes. Wayfire, being wayfire, of course, allows you to use an external tool like kanshi to manage dislays. But that's not the case with most others.
Edit: I think sway/labwc also allow the use of external tools like kanshi.
At least to begin with, I think we can make a list of compositors that support using kanshi, and add support to generate kanshi config to lxqt-config-monitor.
I think we will be shipping a default config file for each compositor, right? We could set those up so that kanshi is automatically used to manage the outputs.
O sure, I forgot about the settings... labwc supports kanshi.
I think we will be shipping a default config file for each compositor, right? We could set those up so that kanshi is automatically used to manage the outputs.
We do so in lxqt-labwc-session if there is no file present yet. For wayfire, sway or Hyprland lxqt-session should also be added by us to their config files. Some of them support a config.d directory (sway, labwc) where we could add always files.
Just came up with this for the moment - the text should be changed then.
A complete example kanshi config line is as follows:
profile default {
output eDP-1 enable mode 1920x1080@60Hz position 0,0 scale 1.0 transform normal adaptive_sync off
}
Multiline version
profile default {
output eDP-1 {
enable
mode 1920x1080@60Hz
position 0,0
scale 1.0
transform normal
adaptive_sync off
}
}
Kanshi works on labwc, Hyprland, sway and wayfire. Basically if lxqt-config-monitor can't load kscreen and is on wayland it could read monitor settings similar as wlr-randr does and write changest to ~/.config/kanshi and issue kanshictl reload.
Fixed by da2d13c