https://bugs.kde.org/show_bug.cgi?id=372963

            Bug ID: 372963
           Summary: plasmashell does not handle primary screen
           Product: plasmashell
           Version: 5.8.4
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: grave
          Priority: NOR
         Component: Desktop Containment
          Assignee: se...@kde.org
          Reporter: jan_br...@gmx.net
  Target Milestone: 1.0

Plasmashell does not cope with changes of the primary screen.

1. First of all, it ignores primary screen changes at runtime when two screens
are connected.
    Scenario: I have an external screen (DP-0) connected to my Laptop (LVDS-0)
    LVDS-0 is primary. When I do
        xrandr --output DP-0 --primary
    the shell flickers (goes black and redisplays on the same screen) but still
    all widgets stay on LVDS-0. When reverting with
        xrandr --output LVDS-0 --primary
    it doesn't even flicker.

    As mentioned in other bugs, a restart of plasmashell displays at the right
    display, i.e., DP-0. Now the behaviour is identical, the shell flickers
    when switching to LVDS-0.

    This behaviour is rock-stable. I can repeat it as often as I want.

2. When I configure the DP-0 to be the primary screen and restart plasmashell
    I do have the desired configuration. But when I now disconnecting DP-0,
    plasmashell may crash (cmp #340904). The backtrace is appended below.
    .xsession-error shows:
        kscreen.kded: Change detected
        kscreen.kded: KScreen::Output( 647   "LVDS-0" connected enabled
QPoint(0,0) QSize(1600, 900) "648" )
        KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
        KCrash: Application 'plasmashell' crashing...
    Of course, after the restart everything is back up on the laptop panel.
    Mostly, but sometimes plasma has a hickup and stops working. This is
    especially tragic when you rely on suspend if the lid is closed,
    as all this behaviour is only working when the gui is not crashed.

    In the aftermath, when now replugging the DP-0, we see the behaviour from
    1.: plasmashell on LVDS-0 flickers, but although the primary is correctly
    communicated, the widgets do not move. The logs from .xsession-errors:
        Old primary output: QScreen(0x2196ba0, name="LVDS-0") New primary
output: QScreen(0x32d6130, name="DP-0")
    show that plasmashell does recognize the new situation.


    The funny thing is, when plasmashell is restarted after the crash, 
    all widgets stays on the wrong screen.

Now the backtrace:
Thread 1 "plasmashell" received signal SIGSEGV, Segmentation fault.
0x00007f6f30310574 in PlasmaQuick::ContainmentView::containment() const () from
/usr/lib64/libKF5PlasmaQuick.so.5
(gdb) bt
#0  0x00007f6f30310574 in PlasmaQuick::ContainmentView::containment() const ()
from /usr/lib64/libKF5PlasmaQuick.so.5
#1  0x0000000000440321 in ShellCorona::screenForContainment(Plasma::Containment
const*) const ()
#2  0x0000000000440276 in ShellCorona::screenForContainment(Plasma::Containment
const*) const ()
#3  0x00007f6e8ae637ee in NotificationsApplet::onScreenChanges() ()
   from /usr/lib64/qt5/plugins/plasma/applets/plasma_applet_notifications.so
#4  0x00007f6f2e1d9d1c in QtPrivate::QSlotObjectBase::call (a=0x7ffdf02a3980,
r=0x1d11310, this=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:130
#5  QMetaObject::activate (sender=0x7f6f2f325e20 <(anonymous
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>,
    signalOffset=<optimized out>, local_signal_index=<optimized out>,
argv=<optimized out>) at kernel/qobject.cpp:3723
#6  0x00007f6f28378118 in NETEventFilter::nativeEventFilter(QByteArray const&,
void*, long*) ()
   from
/usr/lib64/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so
#7  0x00007f6f2e1ac22f in QAbstractEventDispatcher::filterNativeEvent
(this=<optimized out>, eventType=...,
    message=message@entry=0x7f6f24003300, result=result@entry=0x7ffdf02a3b48)
at kernel/qabstracteventdispatcher.cpp:466
#8  0x00007f6f296c8a04 in QXcbConnection::handleXcbEvent
(this=this@entry=0x7d0780, event=event@entry=0x7f6f24003300)
    at qxcbconnection.cpp:1103
#9  0x00007f6f296cc3ee in QXcbConnection::processXcbEvents (this=0x7d0780) at
qxcbconnection.cpp:1735
#10 0x00007f6f2e1da821 in QObject::event (this=0x7d0780, e=<optimized out>) at
kernel/qobject.cpp:1263
#11 0x00007f6f2edaf32c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib64/libQt5Widgets.so.5
#12 0x00007f6f2edb4739 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#13 0x00007f6f2e1aef18 in QCoreApplication::notifyInternal2 (receiver=0x7d0780,
event=event@entry=0x7f6f24003350)
    at kernel/qcoreapplication.cpp:988
#14 0x00007f6f2e1b15ad in QCoreApplication::sendEvent (event=0x7f6f24003350,
receiver=<optimized out>)
    at kernel/qcoreapplication.h:231
#15 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0,
event_type=event_type@entry=0, data=0x7b9860)
    at kernel/qcoreapplication.cpp:1649
#16 0x00007f6f2e1b1a28 in QCoreApplication::sendPostedEvents
(receiver=receiver@entry=0x0, event_type=event_type@entry=0)
    at kernel/qcoreapplication.cpp:1503
#17 0x00007f6f2e200ae3 in postEventSourceDispatch (s=0x806c30) at
kernel/qeventdispatcher_glib.cpp:276
#18 0x00007f6f2c3d5917 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#19 0x00007f6f2c4502d8 in g_main_context_iterate.isra.42.lto_priv () from
/usr/lib64/libglib-2.0.so.0
#20 0x00007f6f2c3d7a3c in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#21 0x00007f6f2e200eef in QEventDispatcherGlib::processEvents (this=0x804500,
flags=...) at kernel/qeventdispatcher_glib.cpp:423
#22 0x00007f6f2e1ad04a in QEventLoop::exec (this=this@entry=0x7ffdf02a4140,
flags=..., flags@entry=...) at kernel/qeventloop.cpp:210
#23 0x00007f6f2e1b548d in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1261
#24 0x000000000041c0ea in main ()

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to