| Summary: | TDE locks screen (or kdesktop hangs up) right after start on Xorg configuration with 2 screen sections | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Alexander Golubev (Fat-Zer) <fatzer2> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | bugwatch, darrella, fatzer2, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2968 | ||
| Attachments: |
xorg.conf
trinity session log |
||
Created attachment 1722 [details]
trinity session log
I have had that happen to me. I'm not sure because I have not performed any testing, but in my case I think the problem was an unclean build environment that was contaminated with proprietary nvidia drivers. When I started Trinity I saw exactly the same thing you decribe and Trinity quickly terminated after starting. I also saw XSMP errors in my xsession-error log. I looked into this further. I discovered the problem I had that exhibited the same behavior was not the build environment but the run-time environment where I installed the Trinity packages. That particular run-time environment had the nvidia packages installed. Background: I had copied the test partition from another system to use as a quick-start to populate the test partition and never removed the nvidia packages. The test machines does not have a nvidia video card. I don't know whether this information helps, but perhaps look for an incorrect video configuration? (In reply to comment #3) > I looked into this further. I discovered the problem I had that exhibited the > same behavior was not the build environment but the run-time environment where > I installed the Trinity packages. That particular run-time environment had the > nvidia packages installed. Background: I had copied the test partition from > another system to use as a quick-start to populate the test partition and never > removed the nvidia packages. The test machines does not have a nvidia video > card. > > I don't know whether this information helps, but perhaps look for an incorrect > video configuration? I don't think that could be something about incorrect system configuration, because, as I sad, kde3/4 worked well. So it supposed to be a tde bug. Because you mentioned XSMP error I suspect it somewhere around ksmserver. But I've got no idea how to debug it... The shutdown is called by kdesktop. By both it's instances. I'm upgrading the component from system to tdebase. I can't reproduce this issue. Is this still happening? @Michele Calgaro, yep, it's still there for me. I can reproduce it on Ubuntu-18.04 and recently nightly builds. Are you sure you configured your X as described above? Two separate X Screens (e.g you can't drag windows between them, but can independently switch virtual desktops), and each has its own instance of kdesktop/kicker/kwin. Note, the xorg.conf attached relevant only for proprietary nvidia drivers and will likely require some tweaking. The analogous config vor opensource drivers (intel/nouveou/modesetting) called "zaphode mode". I managed to reproduce it inside virtualbox as well (with more drastic consequences) and may create a vagrant/virtualbox image if you wish to look into it. Actually there is a simpler way to reproduce it using Xephyr: 1. Install Xephyr (should be available from repositories on most disros) 2. Run it: $ Xephyr -screen 1024x600 -screen 1024x600 -br -xinerama :10 3. Run TDE: $ DISPLAY=:10.0 starttde 4. The logout doesn't happen all the time, sometimes one of kdesktop instances just hangs up, so you may wish to kill/restart kdesktop several times I would recommend to start the nested session and Xephyr from another user not to clobber with the currently running one. In that case don't forget to do `xhost +local:` from your current session. Thanks Alex, that will help in testing and debugging :-) Looks like the issue was introduce by changes to kdesktop/lock/main.cc on git hash 5f4287e56. Looks like the code was written with wrong assumptions in mind: that there should be exactly one kdesktop and kdesktop_lock instance. Also it's bad to ungratefully SIGKILL every sibling... I don't know how to properly fix all that now because kdesktop/kdesktop_lock interaction is some insane signal-based mess... Maybe we may change signals to control sockets or DCOP interface? Why the hell Tim decided to use signals here? It's freaking unsafe! It's a damn luck that we don't have a crash each second time the desktop being locked/unlock. |
Created attachment 1721 [details] xorg.conf I've got dual monitor configuration with two Screen sections (see xorg.conf). When I start trinity (doesn't matter with startx or with DM) it seems to load fine but after that appears the logout dialog end the session closes. Some time if kicker doesn't closes in several seconds, it's possible to stop the logout process. In this case everything works quite well. Both kde4 and kde3 work correctly in such configuration. So I consider this to be a regression. I don't know if tde-3.5 branches are affected. I got no idea what could cause the logout and what to start with... Does somebody got? NOTE: for people who don't understand what such configuration may need for. You have two separate screens on those you can independently switch virtual desktops. Although you can't drag windows between them. In such mode each screen has it's own DESKTOP variable (e.g. ":0.0" and ":0.1"). And there are two instances of each: kdesktop, twin and kicker for each screen.