Just upgraded my laptop from Stretch+R14 to Buster+PSB, after several successful test VPS upgrades.
After logging in screen flashes like crazy and .xsession-errors mostly repeats (with different resource ids):
X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x390a155
Also seeing a few of these:
Error: BadAccess (attempt to access private resource denied) 10 Major opcode: 2 Minor opcode: 0 Resource id: 0x180001c
And an occasional:
unix_connect: can't connect to server (unix:/tmp/ksocket-mgb/bravo.y.n-262a-51c100e0) [artsd] There are already artsd objects registered, looking if they are active... [artsd] ... cleaned 5 unused mcop global references.
However login screen is fine and I can login in Failsafe mode and then run firefox and kmail from konsole without problems.
Any suggestions or anything I can do to help diagnose/debug problem?
TIA,
--Mike
The problem seems to be related to having multiple displays.
In Stretch+TDE-r14.0.5 I had two displays on one NVidia adaptor, not combined, with TDE only using the primary display.
After migrating to Buster+TDE-14.0.7(PSB) the display crashed multiple times per second after logging in, giving the appearance of flashing like crazy. However TDM and Failsafe mode worked fine.
After running RandR in global mode from Systray, TDE once again works without crashing but RandR cannot see the second display, neither initially nor after rescanning displays.
In r14.0.5 RandR could see the second display and asked me whether or not I wanted to include it in TDE.
However the second display works fine in X because I can start Factorio from TDE and direct it to run on the second display.
I don't think there's enough specifics here to file a bug yet. Let me know if there's more I can do to help.
--Mike
On Wednesday 10 of July 2019 08:24:43 Mike Bird wrote:
The problem seems to be related to having multiple displays.
In Stretch+TDE-r14.0.5 I had two displays on one NVidia adaptor, not combined, with TDE only using the primary display.
After migrating to Buster+TDE-14.0.7(PSB) the display crashed multiple times per second after logging in, giving the appearance of flashing like crazy. However TDM and Failsafe mode worked fine.
After running RandR in global mode from Systray, TDE once again works without crashing but RandR cannot see the second display, neither initially nor after rescanning displays.
In r14.0.5 RandR could see the second display and asked me whether or not I wanted to include it in TDE.
However the second display works fine in X because I can start Factorio from TDE and direct it to run on the second display.
I don't think there's enough specifics here to file a bug yet. Let me know if there's more I can do to help.
--Mike
Hi Mike,
do I understand correctly that "flashes" in the sense of an XServer crash? Are there any information listed in the XOrg log? If you try "xrandr -q" from Konsole, will it print both monitors?
On Thu July 11 2019 04:35:31 Slávek Banko wrote:
do I understand correctly that "flashes" in the sense of an XServer crash?
I don't think XServer is crashing as the .xsession-errors shows errors but not a restart and Xorg.0.log shows no errors or restart.
My guess is that TDE is encountering serious errors that disrupt TDE operation but that do not cause X to crash.
Are there any information listed in the XOrg log?
Lots of X startup info but no errors in Xorg.0.log. However .xsession-errors mostly consists of high-speed repeats of this approx ten times per second. Sometimes there are a lot more stale lockfile messages and sometimes a different resource id appears but it's mostly like this.
[2019/07/11 05:09:30.488] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.489] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.541] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.542] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.544] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0xc00104 [2019/07/11 05:09:30.591] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.591] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.645] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.646] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.648] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0xc00104
There is none of the above when the second display is disabled and TDE is working fine.
If you try "xrandr -q" from Konsole, will it print both monitors?
Here is xrandr -q with the second monitor DISABLED in nvidia-settings and TDE 14.0.7 PSB working fine on my primary display on DP-2 and the disabled monitor on HDMI-0.
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) HDMI-0 connected (normal left inverted right x axis y axis) 1600x1200 60.00 + 1400x1050 74.87 1280x1024 85.02 75.02 1280x960 85.00 1152x864 85.00 1024x768 85.00 75.03 70.07 60.00 800x600 85.06 75.00 72.19 60.32 56.25 640x480 85.01 75.00 72.81 59.94 DP-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 381mm x 214mm 1920x1080 60.01*+ DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis)
Here is the xrandr -q with the second monitor enabled as screen :1 in nvidia-settings. I had to use Failsafe mode to get this initially but (see below) after I found I could kill one of the kdesktops and stop the flashing I got the same randr -q result as in Failsafe mode.
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 381mm x 214mm 1920x1080 60.01*+ DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis)
Note that there is no sign of the second display even though TDE is throwing up a blue background and occasional screen unlock dialogs on the second display. The second display should be in screen :1 and not used by TDE in :0.
The "screen is locked" dialogs appear randomly on one screen or the other every half minute or so - much earlier than they should appear. The flashing stops while the screen unlock dialog is present so I can type my password and return to the flashing.
Here is the relevant portion of a Factorio log in the dual monitor configuration, using a TDE Failsafe login which works fine albeit it only gives you a root konsole login. Here I have started Factorio from non-root konsole in Failsafe mode in :0 and told it to run on :1.
1.910 Environment: DISPLAY=:0, WAYLAND_DISPLAY=<unset> 1.927 Display options: [FullScreen: 1] [VSync: 1] [UIScale: system (100.0%)] [MultiSampling: OFF] [Screen: 1] [Lang: en] 1.963 Available display adapters: 2 1.963 [0]: resolution 1920x1080px at [0,0] 1.963 [1]: resolution 1600x1200px at [0,0] 1.963 Create display on adapter 1. Size 1280x720 at position [150, 222].
You can even start kicker from a non-root konsole in Failsafe and things mostly work.
I just discovered that in the two display configuration TDE is running kdesktop on both screens. If I guess right and kill the unwanted kdesktop the flashing stops and TDE appears usable.
tdmrc has the default, unchanged from 14.0.5, including
StaticServers=:0 ReserveServers=:1,:2,:3
I haven't tried changing this yet. What on earth is an on-demand (reserve) server?
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2019/07/11 08:56 PM, Mike Bird wrote:
I just discovered that in the two display configuration TDE is running kdesktop on both screens. If I guess right and kill the unwanted kdesktop the flashing stops and TDE appears usable.
Hi Mike, if there are two kdesktop processes running, each will run a kdesktop_lock process and the two processes will use the same lock file on the disk. The "delete stale file" logs that you see are consistent with that. You need to try to understand why two kdesktop processes are started together.
Cheers Michele
On Thu July 11 2019 06:29:23 Michele Calgaro via trinity-users wrote:
if there are two kdesktop processes running, each will run a kdesktop_lock process and the two processes will use the same lock file on the disk. The "delete stale file" logs that you see are consistent with that. You need to try to understand why two kdesktop processes are started together.
Hi Michele,
Agreed there should not be two kdesktops.
However .xsession-errors shows them using different lock files:
[2019/07/11 05:09:30.488] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.489] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1
And yet they both decide these lockfiles are stale a couple dozen times per second.
Not sure why the lockfiles refer to :0.0 and :0.1 when the two displays should be :0 (TDE) and :1 (not TDE).
When I disable the second display TDE works fine with a single :0 lock file as expected.
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi Michele,
Agreed there should not be two kdesktops.
However .xsession-errors shows them using different lock files:
[2019/07/11 05:09:30.488] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.489] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1
And yet they both decide these lockfiles are stale a couple dozen times per second.
Not sure why the lockfiles refer to :0.0 and :0.1 when the two displays should be :0 (TDE) and :1 (not TDE).
When I disable the second display TDE works fine with a single :0 lock file as expected.
--Mike
Hi Mike, let me be more specific. There should be one kdesktop in total and one kdesktop_lock per display I think. The last part of the name is given by the DISPLAY variable, like :0.0 and :0.1. So :0.0 and :0.1 are not competing with each other, but rather with older :0.0 and :0.1.
Another possibility is that kdesktop_lock crashes: in this case kdesktop will respawn the process and once again you would see the delete stale thing.
Cheers Michele
On Thu, 11 Jul 2019 05:56:40 -0700 Mike Bird mgb-trinity@yosemite.net wrote:
On Thu July 11 2019 04:35:31 Slávek Banko wrote:
do I understand correctly that "flashes" in the sense of an XServer crash?
I don't think XServer is crashing as the .xsession-errors shows errors but not a restart and Xorg.0.log shows no errors or restart.
My guess is that TDE is encountering serious errors that disrupt TDE operation but that do not cause X to crash.
Are there any information listed in the XOrg log?
Lots of X startup info but no errors in Xorg.0.log. However .xsession-errors mostly consists of high-speed repeats of this approx ten times per second. Sometimes there are a lot more stale lockfile messages and sometimes a different resource id appears but it's mostly like this.
There is none of the above when the second display is disabled and TDE is working fine.
If you try "xrandr -q" from Konsole, will it print both monitors?
Note that there is no sign of the second display even though TDE is throwing up a blue background and occasional screen unlock dialogs on the second display. The second display should be in screen :1 and not used by TDE in :0.
The "screen is locked" dialogs appear randomly on one screen or the other every half minute or so - much earlier than they should appear. The flashing stops while the screen unlock dialog is present so I can type my password and return to the flashing.
Does your two monitor setup as a separated X screens ? If so your are probably running into this http://bugs.pearsoncomputing.net/show_bug.cgi?id=2775
On Thu July 11 2019 08:33:40 Nick Koretsky wrote:
Does your two monitor setup as a separated X screens ? If so your are probably running into this http://bugs.pearsoncomputing.net/show_bug.cgi?id=2775
Thanks Nick. That's close to what I am seeing but my dual monitor config was working in 14.0.5 and stopped working in 14.0.7. Could well be related.
--Mike
On Thursday 11 July 2019 08:56:40 Mike Bird wrote:
On Thu July 11 2019 04:35:31 Slávek Banko wrote:
do I understand correctly that "flashes" in the sense of an XServer crash?
I don't think XServer is crashing as the .xsession-errors shows errors but not a restart and Xorg.0.log shows no errors or restart.
My guess is that TDE is encountering serious errors that disrupt TDE operation but that do not cause X to crash.
Are there any information listed in the XOrg log?
Lots of X startup info but no errors in Xorg.0.log. However .xsession-errors mostly consists of high-speed repeats of this approx ten times per second. Sometimes there are a lot more stale lockfile messages and sometimes a different resource id appears but it's mostly like this.
[2019/07/11 05:09:30.488] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.489] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.541] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.542] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.544] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0xc00104 [2019/07/11 05:09:30.591] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.591] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.645] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.1 [2019/07/11 05:09:30.646] [tdecore] Deleting stale lockfile /tmp/tde-mgb/kdesktop_lock_lockfile.:0.0 [2019/07/11 05:09:30.648] X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0xc00104
There is none of the above when the second display is disabled and TDE is working fine.
If you try "xrandr -q" from Konsole, will it print both monitors?
Here is xrandr -q with the second monitor DISABLED in nvidia-settings and TDE 14.0.7 PSB working fine on my primary display on DP-2 and the disabled monitor on HDMI-0.
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) HDMI-0 connected (normal left inverted right x axis y axis) 1600x1200 60.00 + 1400x1050 74.87 1280x1024 85.02 75.02 1280x960 85.00 1152x864 85.00 1024x768 85.00 75.03 70.07 60.00 800x600 85.06 75.00 72.19 60.32 56.25 640x480 85.01 75.00 72.81 59.94 DP-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 381mm x 214mm 1920x1080 60.01*+ DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis)
Here is the xrandr -q with the second monitor enabled as screen :1 in nvidia-settings. I had to use Failsafe mode to get this initially but (see below) after I found I could kill one of the kdesktops and stop the flashing I got the same randr -q result as in Failsafe mode.
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 381mm x 214mm 1920x1080 60.01*+ DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis)
Note that there is no sign of the second display even though TDE is throwing up a blue background and occasional screen unlock dialogs on the second display. The second display should be in screen :1 and not used by TDE in :0.
The "screen is locked" dialogs appear randomly on one screen or the other every half minute or so - much earlier than they should appear. The flashing stops while the screen unlock dialog is present so I can type my password and return to the flashing.
Here is the relevant portion of a Factorio log in the dual monitor configuration, using a TDE Failsafe login which works fine albeit it only gives you a root konsole login. Here I have started Factorio from non-root konsole in Failsafe mode in :0 and told it to run on :1.
1.910 Environment: DISPLAY=:0, WAYLAND_DISPLAY=<unset> 1.927 Display options: [FullScreen: 1] [VSync: 1] [UIScale: system (100.0%)] [MultiSampling: OFF] [Screen: 1] [Lang: en] 1.963 Available display adapters: 2 1.963 [0]: resolution 1920x1080px at [0,0] 1.963 [1]: resolution 1600x1200px at [0,0] 1.963 Create display on adapter 1. Size 1280x720 at position [150, 222].
You can even start kicker from a non-root konsole in Failsafe and things mostly work.
I just discovered that in the two display configuration TDE is running kdesktop on both screens. If I guess right and kill the unwanted kdesktop the flashing stops and TDE appears usable.
tdmrc has the default, unchanged from 14.0.5, including
StaticServers=:0 ReserveServers=:1,:2,:3
I haven't tried changing this yet. What on earth is an on-demand (reserve) server?
--Mike
Buster is using wayland, so not all of the xorg features are present. So its possible that TDE might see problems.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Thu July 11 2019 08:34:04 Gene Heskett wrote:
Buster is using wayland, so not all of the xorg features are present. So its possible that TDE might see problems.
Hi Gene,
Buster provides Wayland and Buster Gnome defaults to Wayland but Buster also provides X and Buster window managers can use X.
--Mike
OK, for comparison purposes I'm back to 14.0.5 and Stretch. (Something of a struggle as Tim's server became inaccessible again during the downgrade.)
Dual display with first for Trinity and second was intended to be non-TDE as before but TDE won't cooperate on that. However 14.0.5 works without flashing or crashing. The unlock screen dialog pops up two or three or four times after login but things eventually settle down.
Instead of the two lock files in 14.0.7 PSB there is a single lock file in 14.0.5: /tmp/tde-mgb/kdesktop_lock_lockfile
However TDE 14.0.5 is running a second desktop on the second display. Before upgrading to 14.0.7 and rolling back to 14.0.5 the systray randr would allow me to specify which display was primary and which display(s) TDE could or could not use. But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
xrandr gives different results in each screen which don't list the other screen. And I can't get kicker to appear in the second display although it says that two instances are running and won't start another.
Behind the scenes, some weirdness is going on:
# ps ax | grep kde 70 ? S 0:00 [kdevtmpfs] 8135 ? SL 0:08 kded [tdeinit] --new-startup 8187 ? Sl 0:01 /opt/trinity/bin/kdesktop 8188 ? Sl 0:00 /opt/trinity/bin/kdesktop 8191 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8193 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8201 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8495 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8536 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8562 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8581 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8582 ? Z 0:00 [kdesktop_lock] <defunct> 12492 pts/3 S+ 0:00 grep kde
Has anyone had success with multiple displays in 14.0.7? Preferably with TDE on one display and the second as an X display unused by TDE?
--Mike
Dne pá 12. července 2019 Mike Bird napsal(a):
OK, for comparison purposes I'm back to 14.0.5 and Stretch. (Something of a struggle as Tim's server became inaccessible again during the downgrade.)
Dual display with first for Trinity and second was intended to be non-TDE as before but TDE won't cooperate on that. However 14.0.5 works without flashing or crashing. The unlock screen dialog pops up two or three or four times after login but things eventually settle down.
Instead of the two lock files in 14.0.7 PSB there is a single lock file in 14.0.5: /tmp/tde-mgb/kdesktop_lock_lockfile
However TDE 14.0.5 is running a second desktop on the second display. Before upgrading to 14.0.7 and rolling back to 14.0.5 the systray randr would allow me to specify which display was primary and which display(s) TDE could or could not use. But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
xrandr gives different results in each screen which don't list the other screen. And I can't get kicker to appear in the second display although it says that two instances are running and won't start another.
Behind the scenes, some weirdness is going on:
# ps ax | grep kde 70 ? S 0:00 [kdevtmpfs] 8135 ? SL 0:08 kded [tdeinit] --new-startup 8187 ? Sl 0:01 /opt/trinity/bin/kdesktop 8188 ? Sl 0:00 /opt/trinity/bin/kdesktop 8191 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8193 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8201 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8495 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8536 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8562 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8581 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8582 ? Z 0:00 [kdesktop_lock] <defunct> 12492 pts/3 S+ 0:00 grep kde
Has anyone had success with multiple displays in 14.0.7? Preferably with TDE on one display and the second as an X display unused by TDE?
--Mike
Hi Mike,
I have a TDE 14.0.7 with two screens on Debian Wheezy and Debian Stretch. However, both configurations are that one TDE session is used over both screens => $DISPLAY is simply ":0" and one kdesktop is running. And everything works fine.
As you can see from your list of processes, for R14.0.6 kdesktop is also run incorrectly and kdesktop_lock is even more incorrectly. There should always be one kdesktop + kdesktop_lock pair per TDE session. The question here is whether these multiple kdesktop processes really work, or if there was no crash (and therefore no flicker) just because one of them is stuck and doesn't really work?
Here are the questions for which we need to find the answer:
1. Why is more kdesktop running? Is there one TDE session or more?
2. Why does kdesktop crash?
Note: In any case, thank you for adding information about the situation - at the beginning I did not know what to imagine under the flickering and therefore I thought it was xserver crashes.
Cheers
On Friday 12 July 2019 05:47:25 am Slávek Banko wrote:
I have a TDE 14.0.7 with two screens on Debian Wheezy and Debian Stretch.
After getting nowhere reading the source and editing random config files I blew away my config by "mv ~/.trinity/share/config{,.SAFE}".
In Buster 14.0.5 this gives me a stable two display desktop.
In Buster 14.0.7 this gives me a flashing unusable desktop.
If you temporarily rename your Stretch 14.0.7 config and reboot does your desktop break? If not, could you please share you xorg.conf?
TIA,
--Mike
On Fri, 12 Jul 2019 01:18:28 -0700 Mike Bird mgb-trinity@yosemite.net wrote:
OK, for comparison purposes I'm back to 14.0.5 and Stretch. (Something of a struggle as Tim's server became inaccessible again during the downgrade.)
Dual display with first for Trinity and second was intended to be non-TDE as before but TDE won't cooperate on that. However 14.0.5 works without flashing or crashing. The unlock screen dialog pops up two or three or four times after login but things eventually settle down.
Instead of the two lock files in 14.0.7 PSB there is a single lock file in 14.0.5: /tmp/tde-mgb/kdesktop_lock_lockfile
However TDE 14.0.5 is running a second desktop on the second display. Before upgrading to 14.0.7 and rolling back to 14.0.5 the systray randr would allow me to specify which display was primary and which display(s) TDE could or could not use. But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
xrandr gives different results in each screen which don't list the other screen. And I can't get kicker to appear in the second display although it says that two instances are running and won't start another.
Behind the scenes, some weirdness is going on:
# ps ax | grep kde 70 ? S 0:00 [kdevtmpfs] 8135 ? SL 0:08 kded [tdeinit] --new-startup 8187 ? Sl 0:01 /opt/trinity/bin/kdesktop 8188 ? Sl 0:00 /opt/trinity/bin/kdesktop 8191 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8193 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8188 8201 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8495 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8536 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8562 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8581 ? S 0:00 /opt/trinity/bin/kdesktop_lock --internal 8187 8582 ? Z 0:00 [kdesktop_lock] <defunct> 12492 pts/3 S+ 0:00 grep kde
Has anyone had success with multiple displays in 14.0.7? Preferably with TDE on one display and the second as an X display unused by TDE?
Yeah, this is exactly the behavior i have reported years ago, and the only way to avoid it is remove the kdesktop_lockn executable (this doesnt not cause any problems except inability to lock obviously, and inability to shutdown directly from TDE session).
Now, about how it worked for you before....
But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
Randr not showing other monitor is a correct behavior in case of two X screens, so if it does showed them before you had X configured differently - both monitors were on a single X screen and this bug didnt trigger.
On Friday 12 July 2019 02:06:03 pm Nick Koretsky wrote:
But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
Randr not showing other monitor is a correct behavior in case of two X screens, so if it does showed them before you had X configured differently - both monitors were on a single X screen and this bug didnt trigger.
I hear you. I can't figure out how I previously got into the desired working state.
I can edit cat ~/.trinity/share/config/displayconfig/default to set IsExtended=false on the screen where I don't want TDE but unfortunately TDE simply overrules this when it sees a connected monitor.
It looks like I can work with both screens being used by TDE, but I can't work with the screens flashing ten times per second and not accepting input in 14.0.7!
--Mike
Anno domini 2019 Fri, 12 Jul 14:37:09 -0700 Mike Bird scripsit:
On Friday 12 July 2019 02:06:03 pm Nick Koretsky wrote:
But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
Randr not showing other monitor is a correct behavior in case of two X screens, so if it does showed them before you had X configured differently - both monitors were on a single X screen and this bug didnt trigger.
I hear you. I can't figure out how I previously got into the desired working state.
I can edit cat ~/.trinity/share/config/displayconfig/default to set IsExtended=false on the screen where I don't want TDE but unfortunately TDE simply overrules this when it sees a connected monitor.
It looks like I can work with both screens being used by TDE, but I can't work with the screens flashing ten times per second and not accepting input in 14.0.7!
Sorry, maybe I missed a point, but are you sure Xorg is installed and wayland purged?
Nik
--Mike
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 12 July 2019 03:06:30 pm Dr. Nikolaus Klepp wrote:
Sorry, maybe I missed a point, but are you sure Xorg is installed and wayland purged?
It's definitely running Xorg although there are five random wayland library packages installed that are direct or indirect dependencies of mpv, firefox, etc.
None of the wayland libraries are in use when kdesktop, kmail, kicker, and konsole are running.
--Mike
On Fri, 12 Jul 2019 14:37:09 -0700 Mike Bird mgb-trinity@yosemite.net wrote:
On Friday 12 July 2019 02:06:03 pm Nick Koretsky wrote:
But now systray randr only shows one screen and doesn't enable those options, despite TDE actually using two displays.
Randr not showing other monitor is a correct behavior in case of two X screens, so if it does showed them before you had X configured differently - both monitors were on a single X screen and this bug didnt trigger.
I hear you. I can't figure out how I previously got into the desired working state.
I can edit cat ~/.trinity/share/config/displayconfig/default to set IsExtended=false on the screen where I don't want TDE but unfortunately TDE simply overrules this when it sees a connected monitor.
It looks like I can work with both screens being used by TDE, but I can't work with the screens flashing ten times per second and not accepting input in 14.0.7!
If you are not interested in multiple screens, you just need to edit them out of xorg.conf (afaik TDE settings are not touching this anywhere). Unless you need special xorg settings for you video to work, remove xorg.conf and see if you can get desired behavior.
P.S. Maybe your are confused by the word screen? X screen is a virtual entity, which can be mapped to a multiple physical displays, so not using multiple screens doesnt mean you cant use multiple displays.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2019/07/12 04:18 PM, Mike Bird wrote:
OK, for comparison purposes I'm back to 14.0.5 and Stretch. (Something of a struggle as Tim's server became inaccessible again during the downgrade.)
Hi Mike, what happens if you install R14.0.7 PSB on your Stretch system? Ok or flashing? This would give a clear indication whether the problem is related to the update to R14.0.7 (which I suspect) or to the update to Buster.
Thanks Michele
On Friday 12 July 2019 06:32:55 pm Michele Calgaro via trinity-users wrote:
what happens if you install R14.0.7 PSB on your Stretch system? Ok or flashing? This would give a clear indication whether the problem is related to the update to R14.0.7 (which I suspect) or to the update to Buster.
You're right of course but I'm hoping SB can find time to try an empty config on his Stretch 14.0.7 as I don't have a dual monitor test box so I have to downgrade my live laptop which is rather painful.
Is there any switch or other way to get more logging info out of TDE without recompiling?
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
You're right of course but I'm hoping SB can find time to try an empty config on his Stretch 14.0.7 as I don't have a dual monitor test box so I have to downgrade my live laptop which is rather painful.
Yeah, I see what you mean...
Is there any switch or other way to get more logging info out of TDE without recompiling?
Nope AFAIK. You need to have a version compiled with Debug enabled, then you can use tdedebugdialog to enable TDE debug message classes. But normal TDE packages are not build with debug enable.
Cheers Michele
Mike Bird composed on 2019-07-12 19:41 (UTC-0700):
You're right of course but I'm hoping SB can find time to try an empty config on his Stretch 14.0.7 as I don't have a dual monitor test box so I have to downgrade my live laptop which is rather painful.
I've been waiting for you to provide a config supposed to produce your desire, but if you did, I missed it. Also I don't know what PSB means. If you will provide the config that worked in 14.0.5, I will try to reproduce here on a PC. Most of mine have Buster with dual or triple head graphics by Intel, ATI or NVidia, plus openSUSE, and some have Fedora or Mageia or Kubuntu, multiboot all, pure FOSS all except for some printer drivers. I've only ever used multihead to expand a single desktop. All my Busters have TDE and IceWM only.
On Friday 12 July 2019 08:14:00 pm Felix Miata wrote:
I've been waiting for you to provide a config supposed to produce your desire, but if you did, I missed it.
Unfortunately the previous Stretch 14.0.5 working config got mangled when I upgraded to Buster 14.0.7. After downgrading back to Stretch 14.0.5 TDE didn't work the same. In an emergency I could go back to a week old backup but that would be really disruptive on my live laptop.
If I understand Nick's explanation correctly he is saying that going from one desktop to two you can create a certain configuration but that thereafter the two desktops each only see one screen and so the options which were initially available are no longer available.
Also I don't know what PSB means.
I believe PSB stands for preliminary stable build - Slavek's repository rather than Tim's.
If you will provide the config that worked in 14.0.5, I will try to reproduce here on a PC. Most of mine have Buster with dual or triple head graphics by Intel, ATI or NVidia, plus openSUSE, and some have Fedora or Mageia or Kubuntu, multiboot all, pure FOSS all except for some printer drivers. I've only ever used multihead to expand a single desktop. All my Busters have TDE and IceWM only.
I have reproduced the problem with an empty config in Buster 14.0.7 and two non-xinerama xorg.conf screens. After logging in and personalization the displays flash, only a tiny percentage of mouse and keyboard input is effective, and .xsession-errors shows continuous errors. You may also have to unlock the screen several times at the outset.
If convenient it would be helpful if you could determine whether two separate non-xinerama X screens and an empty ~/.trinity/share/config works for you in Buster 14.0.7.
--Mike
Mike Bird composed on 2019-07-12 20:57 (UTC-0700):
Felix Miata wrote:
I've been waiting for you to provide a config supposed to produce your desire, but if you did, I missed it.
Unfortunately the previous Stretch 14.0.5 working config got mangled when I upgraded to Buster 14.0.7. After downgrading back to Stretch 14.0.5 TDE didn't work the same.
I don't need perfection, but I do need a starting point. Working examples on the internet for separate X sessions simultaneously I've never found to work.
If convenient it would be helpful if you could determine whether two separate non-xinerama X screens and an empty ~/.trinity/share/config works for you in Buster 14.0.7.
This is not from an empty ~/.trinity/share/config, but KControl has never been used for configuring displays. This is from X deciding what to do entirely on its own, same result as using IceWM.
# xrandr | egrep 'onnect|creen|*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384 DP-2 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 519mm x 324mm DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 1920x1200 59.95*+ root@p5bse:~# inxi -GxxS System: Host: p5bse Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Trinity R14.0.7 tk: Qt 3.5.0 wm: Twin dm: startx Distro: Debian GNU/Linux 10 (buster) Graphics: Device-1: NVIDIA GF119 [NVS 310] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:107d Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa resolution: 2560x1440~60Hz, 1920x1200~60Hz OpenGL: renderer: NVD9 v: 4.3 Mesa 18.3.6 direct render: Yes
Mike Bird composed on 2019-07-12 20:57 (UTC-0700):
If convenient it would be helpful if you could determine whether two separate non-xinerama X screens and an empty ~/.trinity/share/config works for you in Buster 14.0.7.
Three displays stacked using Intel GPU, configured via xrandr script in /etc/X11/Xsession.d/: # xrandr | egrep 'onnect|creen|*' | grep -v disconn | sort -r Screen 0: minimum 320 x 200, current 2560 x 3690, maximum 8192 x 8192 HDMI-3 connected 1920x1200+0+1050 (normal left inverted right x axis y axis) 519mm x 324mm DP-2 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm DP-1 connected primary 2560x1440+0+2250 (normal left inverted right x axis y axis) 598mm x 336mm 2560x1440 59.95*+ 74.92 1920x1200 59.95*+ 1680x1050 59.97*+ # inxi -GxxS System: Host: ab250 Kernel: 4.19.0-5-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Trinity R14.0.7 tk: Qt 3.5.0 wm: Twin dm: startx Distro: Debian GNU/Linux 10 (buster) Graphics: Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 Display: tty server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa resolution: 2560x1440~60Hz, 1920x1200~60Hz, 1680x1050~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.3.6 compat-v: 3.0
(1) Problem seems to be random in that I've had a few logins - maybe 5-10% - where flashing did not occur.
(2) kdesktop_lock seems to run as a pair of processes per screen. Flashing seems to occur when the parent of these dies while the child remains.
(3) I don't yet know why the parents are dying but once they do and another kdesktop_lock parent/child pair is created we thereafter have multiple child processes competing for the same screen.
(4) Possible cause: http://bugs.pearsoncomputing.net/show_bug.cgi?id=3025
--Mike
Some final notes on two X screen two TDE desktop screen flashing before I attempt to move on with life on a two monitor single xinerama X screen and single TDE desktop.
Prior to the rapid fire stale lock file messages I can find none of the error texts from kdesktop/lock/main.cc in the .xsession-errors. This suggests to me that the desktop_lock processes are dying due to either (a) outside signals not properly blocked by broken signal masking, or (b) by return 12 (ENOMEM!?) or return 1 in response to a failed kill(0).
Further diagnosis of this problem would be facilitated by emitting error messages before dropping out of main() with a return, and by expanding the stale lock file message with the pid of the reporter and the three elements of the lock file content.
I tip my hat to Tim and the TDE developers who inherited a 3.5 codebase that frankly makes me lose sleep every time I attempt to comprehend it.
--Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2019/07/10 10:37 AM, Mike Bird wrote:
Just upgraded my laptop from Stretch+R14 to Buster+PSB, after several successful test VPS upgrades.
After logging in screen flashes like crazy and .xsession-errors mostly repeats (with different resource ids):
X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x390a155
Also seeing a few of these:
Error: BadAccess (attempt to access private resource denied) 10 Major opcode: 2 Minor opcode: 0 Resource id: 0x180001c
And an occasional:
unix_connect: can't connect to server (unix:/tmp/ksocket-mgb/bravo.y.n-262a-51c100e0) [artsd] There are already artsd objects registered, looking if they are active... [artsd] ... cleaned 5 unused mcop global references.
However login screen is fine and I can login in Failsafe mode and then run firefox and kmail from konsole without problems.
Any suggestions or anything I can do to help diagnose/debug problem?
TIA,
--Mike
Hi Mike, not sure if this helps, but TDE R14.1.0-dev on buster has been running like a charm for long time here. But I run debian testing all the time, so update is progressive and not in one go.
Have you tried using a different window theme? different icon set? just in case. Have you tried disabling artsd, again just in case? HAve you tried disabling any autostart program you launch when logging in? Have you tried logging as a new user?
Hope this can help.
Cheers Michele
-
Dr. Nikolaus Klepp -
Felix Miata -
Gene Heskett -
Michele Calgaro via trinity-users -
Mike Bird -
Nick Koretsky -
Slávek Banko