Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Remote xclients don't display when xorg xinerama "ON"|
|Product:||[Fedora] Fedora||Reporter:||Roger Link <linkr>|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED DUPLICATE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-03-07 03:44:56 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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 ***