Bug 138875 - Remote xclients don't display when xorg xinerama "ON"
Remote xclients don't display when xorg xinerama "ON"
Status: CLOSED DUPLICATE of bug 137685
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-11 14:06 EST by Roger Link
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-07 03:44:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Roger Link 2004-11-11 14:06:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020

Description of problem:
Using a dual head config with a Radeon 9000. Using "Individual
Desktops", remote xclients display correctly on my local system
(xserver). If I use "Spanning Desktops", the xsession is NOT
displayed, but appears to be running on the remote. I'm switching the
"Desktop layout" by using the "Dual head" tab of the
system-config-display tool. (after applying patch from bugid #136916).
The only difference between the too configs is the Xinerama & clone lines.

[joe@system X11]$ diff xorg.conf xorg.conf.1
<       Option      "Xinerama" "on"
<       Option      "Clone" "off"
>       Option      "Xinerama" "off"
>       Option      "Clone" "on"
[joe@system X11]$

I'm testing using the following ssh command to start the xclient:

[joe@system grub]$ ssh -X -l joebob system1 /usr/X11R6/bin/xeyes
joe@corsair's password:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start a xclient
2. Observe xdisplay
3. Switch to Spanning or Individual desktop layout, and restart Xserver

Actual Results:  If using "Spanning Desktops", xclient is not
displayed on my Xserver screen, but no errors are reported either.

Expected Results:  Should be able to use "Spanning Desktops", and have
xclients display correctly.

Additional info:
Comment 1 Roger Link 2004-11-18 09:17:31 EST
Upgraded to latest kernel-2.6.9-1.678_FC3, xorg-x11-6.8.1-12.FC3.1,
and system-config-display-1.0.24-1. 

Did *not* fix problem. :-(

I still cannot display remote xclients (xeyes for example) on my local
display if using "Spanning Desktops" from under tab "Dual head" (via
system-config-display). If I use "Individual Desktops", remote
xclients work fine. I'm using gnome. No windows appear, nothing to
show that the xclient is running.

Did test with Xfce. Works fine with individual desktops. When using
"Spanning", the remote X app will pop up a window, with a border &
title bar, but the windows contents are empty, and do not change. 

I'm using two Dell 1800FP LCD displays. The primary display is DVI
digital, and the secondary is driven analog.

Fedora Core 2 does not have this problem on this system.
Comment 2 Jason Kirtland 2004-12-09 15:14:08 EST
I'm seeing this as well on remote display from a RHEL3 system to FC3.

I'm using the xorg mga driver, analog displays, and have tried
assorted window managers.
Comment 3 Jason Kirtland 2004-12-09 15:26:00 EST
Oops, I missed the openssh trusted client change in the release notes.
(e.g. bug #134425).  Using the trusted client option clears up the
problem for me.

"... To forward X11 so that applications are run as trusted clients,
invoke ssh with the -Y flag instead of the -X flag, or set
ForwardX11Trusted in the ~/.ssh/config file."
Comment 4 Roger Link 2004-12-16 10:54:27 EST
The ssh -Y flag does indeed fix this problem with spanning dual-head
desktops. But why does ssh -X work with individual desktops, but not
spanning? There is a bug problem here somewhere. :-)

At least everything works Ok for me if you use the -Y switch with
spanning desktops.
Comment 6 Mike A. Harris 2005-02-07 22:57:58 EST
Reassigning to 'openssh' component, as the default ssh configuration
should either disable ssh X11 forwarding entirely for security,
or enable it entirely for end user convenience and expectation.

Our current openssh default configuration just allows users to
think X11 forwarding will work, but almost zero applications work
with X-SECURITY, so they all break with our default openssh
configuration in obscure ways, that make it appear that the X
server or X client libraries are flawed, when it is the applications
themselves at fault.

Once all X11 applications ever written, are enhanced to support
X-SECURITY sanely, then we can consider making ssh -X the default,
however until then, -X by default just provides a broken remote
X app environment that wont ever work properly for anyone.
Comment 7 Tomas Mraz 2005-03-07 03:44:56 EST

*** This bug has been marked as a duplicate of 137685 ***
Comment 8 Linda Wang 2006-11-30 15:34:53 EST
*** Bug 215752 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.