Re: xnest on 10.5
Re: xnest on 10.5
- Subject: Re: xnest on 10.5
- From: Rachel Greenham <email@hidden>
- Date: Mon, 21 Jan 2008 12:04:02 +0000
On 21 Jan 2008, at 01:47, Jeremy Huddleston wrote:
On Jan 20, 2008, at 16:52, Rachel Greenham wrote:
Yes, Xephyr still doesn't really work right for xdmcp to ubuntu.
Works for me here... not sure what you're trying... and does Xnest
work, but Xephyr doesn't?
Yes. Is what I have been saying, so please don't take Xnest away! :-)
Oh yes, with Xnest I can give a -geometry to make a sensibly-sized
window; I can't in Xephyr, I can only supply -fullscreen which just
covers both monitors on a dual-monitor setup, and also loses the
bottom of the remote desktop by the height of the menubar.
And if I supply -screen <horiz>x<vertical>, while the local window
opened is the right size, the remote desktop's size is completely
wrong - 1600x1200 and apparently nothing can change that - it's not
related to any setup on the remote end. (Currently the remote
system's local display is configured to 1280x1024.)
Uh, this has nothing to do with the remote display...
I know, I'm just mentioning it as one of the things that isn't the
source of this 1600x1200 display size. :-)
are you sure everything is working right with your SM/WM?
Sorry, acronym lookup failure there.
Anything revealing in the log?
Which one? The system.log output for this in its entirety is:
Jan 21 10:52:53 yenaldooshi defaults[4525]: \nThe domain/default pair
of (org.x.X11, no_auth) does not exist
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: 2008-01-21 10:52:53.112
defaults[4525:10b]
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: The domain/default pair
of (org.x.X11, no_auth) does not exist
Jan 21 10:52:53 yenaldooshi defaults[4526]: \nThe domain/default pair
of (org.x.X11, no_auth) does not exist
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: 2008-01-21 10:52:53.125
defaults[4526:10b]
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: The domain/default pair
of (org.x.X11, no_auth) does not exist
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: 2008-01-21 10:52:53.138
defaults[4527:10b]
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: The domain/default pair
of (org.x.X11, nolisten_tcp) does not exist
Jan 21 10:52:53 yenaldooshi defaults[4527]: \nThe domain/default pair
of (org.x.X11, nolisten_tcp) does not exist
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: xauth: creating new
authority file /Users/rachel/.serverauth.4516
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: xinit: Detected Xquartz
startup, setting file=X, argv[0]=/Applications/Utilities/X11.app/
Contents/MacOS/X11
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: TransformProcessType:
Success
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: XQuartz starting:
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: X.org Release 7.2
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: X.Org X Server 1.3.0-apple9
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: Build Date: 20080117
Jan 21 10:52:53 yenaldooshi org.x.X11[4516]: Xquartz: run by launchd
for fd 0
All I get to the terminal I run it from (whether stdout or stderr I
don't know, I'd guess the latter) is our old and probably irrelevant
friend:
Extended Input Devices not yet supported. Impelement it at line 625 in
kinput.c
No output in any logs on the remote system that I can see.
What if you do: -screen 1024/1024x768/768?
No difference. In fact I have to quit X11 before I get any further
system.log output, so that's only happening as a result of the Xquartz
startup, I think.
To illustrate, as it seems like you don't believe it's happening, what
I get for the command:
Xephyr :1 -query 192.168.0.1 -screen 1024/1024x768/768 -once
...looks like this:
http://www.strangenoises.org/~rachel/xephyr.png
In contrast:
Xnest :1 -query 192.168.0.1 -geometry 1024x768 -once
... gives me this:
http://www.strangenoises.org/~rachel/xnest.png
(No, the dpi on the remote end is correct; the background image is
just scaled to the size of the display; compare the size of the
username box, they are still the same.)
I think the problem's upstream anyway. I just tested the exact same
Xephyr commandline from another ubuntu box on the network and I got
the same thing, except the -screen parameter seemed not to have any
effect on the size of the local window opened either; so what I got
was a 1600x1200 desktop in a 1600x1200 window on a local desktop that
was too small for it. So in that respect, it seems, the current Apple
X11 Xephyr is working better because at least it opens the local
window the right size!
For completion's sake; the same commandline:
Xephyr :1 -query 192.168.0.1 -screen 1024/1024x768/768 -once
On a linux box with a 1440x900 screen size gives me:
http://www.strangenoises.org/~rachel/xephyrbuntu.png
(The dot above the b is a vmware artifact I believe.)
So, Xephyr -screen appears to be broken in upstream, and when fixed
there will presumably be fixed here too. (Either that or there's some
highly non-obvious parameters I should be giving to tell it to match
the desktop size to the local window size...) *Please* don't remove
Xnest from the distribution yet! :-)
There's also a problem with doubled up mouse pointers (ie: the
local os x mouse pointer doesn't disappear inside the window -
sometimes.)
This is an issue with most remote desktop products: Xephyr, VNC
screen sharing, remote desktop, remote desktop connection, etc,
etc... Xnest included.
Actually I think I figured out the pattern there - on Xephyr it only
happens if the Xephyr window doesn't have the input focus, or if I
just click within it - if I click on the titlebar first it's fine. So
yes, this is a non-problem as far as I'm concerned. :-)
--
Rachel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden