[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #13 from Maciej Poleski --- (In reply to Maciej Poleski from comment #12) > (In reply to Nate Graham from comment #7) > > If RandR conflicts with Xinerama, then I guess it being missing shouldn't be > > the problem if we require Xinerama now. Otherwise this would be broken for > > everyone and that's not the case. > > > > But it does seem like that dbus call is failing and making reply a nullptr. > > I think it is, for users of certain monitor types (two DP inputs required). > See e.g. > - > https://askubuntu.com/questions/894101/how-to-make-kde-use-a-screen-from- > xrandr-1-5 > - https://michael.stapelberg.ch/posts/2017-12-11-dell-up3218k/ Another one: https://altechnative.net/linux-xorg-up2715k-t221-composite-monitor/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #12 from Maciej Poleski --- (In reply to Nate Graham from comment #7) > If RandR conflicts with Xinerama, then I guess it being missing shouldn't be > the problem if we require Xinerama now. Otherwise this would be broken for > everyone and that's not the case. > > But it does seem like that dbus call is failing and making reply a nullptr. I think it is, for users of certain monitor types (two DP inputs required). See e.g. - https://askubuntu.com/questions/894101/how-to-make-kde-use-a-screen-from-xrandr-1-5 - https://michael.stapelberg.ch/posts/2017-12-11-dell-up3218k/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #11 from Maciej Poleski --- I tried to configure virtual monitor using RandR instead of Xinerama. KDE appears to be reconfiguring the screen using RandR on startup discarding configuration from xorg.conf (see kscreen_backend_launcher and compare to Xorg.0.log). In comparison Openbox doesn't touch the configuration and works out of box using RandR and provided configuration. If KDE could be convinced not to touch preconfigured state, maybe it would work. KScreen doesn't seem to support setting up a virtual monitor. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #10 from Maciej Poleski --- Created attachment 158535 --> https://bugs.kde.org/attachment.cgi?id=158535=edit xorg.conf -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #9 from Maciej Poleski --- Created attachment 158534 --> https://bugs.kde.org/attachment.cgi?id=158534=edit kscreen_backend_launcher -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on launch in X11OutputOrderWatcher::refresh()
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #8 from Maciej Poleski --- Created attachment 158533 --> https://bugs.kde.org/attachment.cgi?id=158533=edit Xorg.0.log -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on start with X11OutputOrderWatcher::refresh() when xrandr isn't available
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #6 from Maciej Poleski --- I don't think I could install xorg-server in such a way that RandR is absent. But RandR conflicts with Xinerama, AFAIU, by definition. $ xrandr RandR extension missing My Xorg.0.log has the following entries: [ 315.220] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the [ 315.220] (WW) NVIDIA: X server. I can disable (not-enable) Xinerama. Then RandR is present. But KDE doesn't seem to honor RandR setup: https://askubuntu.com/questions/894101/how-to-make-kde-use-a-screen-from-xrandr-1-5 I tried it a few months ago. While i3 honored the setting (https://michael.stapelberg.ch/posts/2017-12-11-dell-up3218k/#linux-compatibility--configuration), KDE ignored it. Xinerama seemed to be the only way to go. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on start with X11OutputOrderWatcher::refresh() when xrandr isn't available
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #3 from Maciej Poleski --- I'm having difficulty wrapping my head around this: https://planet.kde.org/vlad-zahorodnii-2022-07-23-xinerama-becomes-hard-requirement-of-kwin/. Was Xinerama support dropped in 5.27? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] plasmashell always crashes on start
https://bugs.kde.org/show_bug.cgi?id=468873 --- Comment #1 from Maciej Poleski --- After peeking at the source code (https://invent.kde.org/plasma/plasma-workspace/-/blob/822c8d9444fb29eb96f40fbe8ee337fb907c00e9/shell/outputorderwatcher.cpp#L183), my hunch is that the issue is related to unavailability of RandR on my system (because I'm forced to use xinerama). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468873] New: plasmashell always crashes on start
https://bugs.kde.org/show_bug.cgi?id=468873
Bug ID: 468873
Summary: plasmashell always crashes on start
Classification: Plasma
Product: plasmashell
Version: 5.27.4
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: d82ks8djf82msd83hf8sc02lqb5...@gmail.com
CC: k...@davidedmundson.co.uk
Target Milestone: 1.0
Application: plasmashell (5.27.4)
(Compiled from sources)
Qt Version: 5.15.8
Frameworks Version: 5.104.0
Operating System: Linux 6.1.19-gentoo-x86_64 x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.27.4 [KCrashBackend]
-- Information about the crash:
This is a regression which escalated over the past software updates (escalation
happened always directly after upgrade).
My system is running on Xorg and proprietary nvidia drivers.
- Initially plasmashell worked just fine.
- After a past software upgrade it bacame unable to start only on a first (:0)
session/display.
- After latest upgrade it doesn't seem to be able to start at all on any
session/display.
This correlates to KDE upgrade without Xorg/nvidia drivers upgrade
xorg-server 21.1.8
nvidia-drivers 525.105.17
The crash can be reproduced every time.
-- Backtrace:
Application: Plazma (plasmashell), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 0x558ed1469f88 in X11OutputOrderWatcher::refresh (this=0x558ed22a12e0)
at
/var/tmp/portage/kde-plasma/plasma-workspace-5.27.4.1-r2/work/plasma-workspace-5.27.4.1/shell/outputorderwatcher.cpp:188
#7 0x7fe39e4a7e0c in QtPrivate::QSlotObjectBase::call (a=0x7fffc5db34d0,
r=0x558ed22a12e0, this=0x558ed228ab00) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#8 doActivate (sender=0x558ed22bb990, signal_index=3,
argv=0x7fffc5db34d0) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:3923
#9 0x7fe39e4a1caf in QMetaObject::activate (sender=,
m=m@entry=0x7fe39e7442e0 ,
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fffc5db34d0)
at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:3983
#10 0x7fe39e4abf0a in QTimer::timeout (this=, _t1=...) at
.moc/moc_qtimer.cpp:205
#11 0x7fe39e49fc7d in QObject::event (this=0x558ed22bb990,
e=0x7fffc5db3630) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qobject.cpp:1369
#12 0x7fe39f0a404e in QApplicationPrivate::notify_helper (this=, receiver=0x558ed22bb990, e=0x7fffc5db3630) at
/var/tmp/portage/dev-qt/qtwidgets-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/widgets/kernel/qapplication.cpp:3640
#13 0x7fe39e475718 in QCoreApplication::notifyInternal2
(receiver=0x558ed22bb990, event=0x7fffc5db3630) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qcoreapplication.cpp:1064
#14 0x7fe39e4c4939 in QTimerInfoList::activateTimers (this=0x558ed1d00480)
at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qtimerinfo_unix.cpp:643
#15 0x7fe39e4c51d4 in timerSourceDispatch (source=) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qeventdispatcher_glib.cpp:183
#16 0x7fe39cf1daf8 in g_main_dispatch (context=0x7fe394005010) at
../glib-2.74.6/glib/gmain.c:3454
#17 g_main_context_dispatch (context=context@entry=0x7fe394005010) at
../glib-2.74.6/glib/gmain.c:4172
#18 0x7fe39cf1dd88 in g_main_context_iterate
(context=context@entry=0x7fe394005010, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
../glib-2.74.6/glib/gmain.c:4248
#19 0x7fe39cf1de1c in g_main_context_iteration (context=0x7fe394005010,
may_block=1) at ../glib-2.74.6/glib/gmain.c:4313
#20 0x7fe39e4c5576 in QEventDispatcherGlib::processEvents
(this=0x558ed1d00830, flags=...) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/corelib/kernel/qeventdispatcher_glib.cpp:423
#21 0x7fe39e4741fb in QEventLoop::exec (this=this@entry=0x7fffc5db3870,
flags=..., flags@entry=...) at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/include/QtCore/../../src/corelib/global/qflags.h:69
#22 0x7fe39e47c370 in QCoreApplication::exec () at
/var/tmp/portage/dev-qt/qtcore-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/include/QtCore/../../src/corelib/global/qflags.h:121
#23 0x7fe39e858acc in QGuiApplication::exec () at
/var/tmp/portage/dev-qt/qtgui-5.15.8-r4/work/qtbase-everywhere-src-5.15.8/src/gui/kernel/qguiapplication.cpp:1870
#24 0x7fe39f0a3fc5 in
[kwin] [Bug 435631] New: Support for Xinerama/RandR equivalent
https://bugs.kde.org/show_bug.cgi?id=435631 Bug ID: 435631 Summary: Support for Xinerama/RandR equivalent Product: kwin Version: 5.20.5 Platform: Compiled Sources OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: d82ks8djf82msd83hf8sc02lqb5...@gmail.com Target Milestone: --- There are monitors out there (such as Dell UP3218K) which are implemented as two monitors in one casing, connected to the computer using two DisplayPort cables. >From software perspective we have to monitors with resolution 3840x4320. Only when combined together these give desired 7680x4320@60Hz. The problem is, from software perspective there are still two monitors, even though I have just one piece standing on my desk. This has unintended consequences on application behavior, such as having a panel on only half of the screen and being able to "maximize" window only up to half of the screen. The solution I'm using right now to workaround this is xinerama. RandR (used as described in https://michael.stapelberg.ch/posts/2017-12-11-dell-up3218k/#linux-compatibility-configuration) fails to produce desired result (appears as nop, still seeing two "actual" monitors in KScreen instead of one "virtual"). But these both are specific for X. What we need is an equivalent of Xinerama/RandR implemented for Wayland. According to earlier attempts on bringing RandR equivalent to Wayland - https://lists.freedesktop.org/archives/wayland-devel/2013-March/007876.html - https://fedoraproject.org/wiki/Wayland_features#XRandR_control_of_Wayland_outputs - https://lists.freedesktop.org/archives/wayland-devel/2014-April/014091.html the right place to implement this functionality would be the wayland compositor itself, kwin in our case. I may be able to dedicate some time to this. I have experience in C++/Qt, but none in Wayland protocol nor kwin internals. I'd need someone to mentor me. What do you think? -- You are receiving this mail because: You are watching all bug changes.
