Bug 138875

Summary: Remote xclients don't display when xorg xinerama "ON"
Product: [Fedora] Fedora Reporter: Roger Link <linkr>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: jek, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-07 08:44:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Roger Link 2004-11-11 19:06:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Firefox/0.10.1

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
9,10c9,10
<       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):
xorg-x11-6.8.1-12

How reproducible:
Always

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 14:17:31 UTC
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 20:14:08 UTC
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 20:26:00 UTC
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 15:54:27 UTC
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-08 03:57:58 UTC
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 08:44:56 UTC

*** This bug has been marked as a duplicate of 137685 ***

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