Re: X11-2.1.1-pre1.pkg
Re: X11-2.1.1-pre1.pkg
- Subject: Re: X11-2.1.1-pre1.pkg
- From: Rachel Greenham <email@hidden>
- Date: Wed, 12 Dec 2007 01:23:48 +0000
Jeremy Huddleston wrote:
I get the default X mouse cursor overlying the proper mouse cursors
as defined on the remote host. The whole time.
I saw this as well just now. Clicking on another X window then back
to Xephyr clears it up. I notice this when I switch Spaces and click
on the Xephyr window in the other space.
Means having another X window open though. :-(
With -fullscreen, again on a two-monitor setup, the window opens
filling both screens with one stretched-out desktop. In case I didn't
state this clearly enough when I last reported that this was happening:
Xquartz -fullscreen is ignored and not working.
Xephyr; am talking about Xephyr. :-)
But reading back the email after writing what's below, it looks like my
*immediate* problem might be fixed by Xquartz -fullscreen being made to
work - or at least some way to turn *off* rootless mode. More below...
THIS IS NOT GOOD.
Well, it's better than it was a few weeks ago, we're making progress.
You can't expect a point release to fix all your problems.
Sure; that was a usability comment. :-) I wasn't sure people realised
what I was describing wasn't optimal. :-) Overcompensating for
understatement maybe. ;-)
It's ugly and unusable. It's understandable for Xquartz, by the
nature of what it is, and what it does; but Xephyr runs in a window;
it should be possible to set that window up with sensible default
fullscreen behaviour in the Mac environment if the -fullscreen
commandline option is given.
You're asking for too much automation, too soon. Be patient. It is
possible. The -geometry command line argument doesn't seem to work
with Xephyr, but there is probably something to choose the
resolution. If not, then just use Xnest instead:
Xnest -query 10.0.10.1 -geometry 1024x768 :1
Xephyr -screen, yes I know. :-) As it happens Xnest has all the same
problems and almost certainly for all the same reasons. :-) Either one
(Xnest -geometry or Xephyr -screen) are the closest I can get to XDMCP
nirvana right now. I'm just trying for even better. :-)
Actually that's not quite true; with Xephyr -screen the remote desktop
comes up the wrong dimensions (1600x1200 by the looks of it). There's
probably something I'm not doing right. :-) A local xterm running in
Xephyr screen shows the right screen size in xdpyinfo, but the remote
server doesn't seem to get it, whereas it does with Xnest. This is odd
as it believes the dimensions it's given with Xephyr -fullscreen - even
when they're crazy-wide. :-) But also from a single-screen Mac.
Something about using -screen isn't sending the right screen dimensions
to the remote machine, it seems.
Anyway, I think I mentioned that before, I'm being exercised by other
daemons tonight. :-)
If any other Mac application has a fullscreen option, eg: itunes,
quicktime, other movie players, they're smart enough not to stretch
the picture across both screens. Can't Xephyr be the same?
Xephyr isn't a "Mac Application" it's an X11 application. It querys
the X server to figure out what the "fullscreen" resolution is.
Obviously there is something Xinerama related that is causing issues
in this case.
Hmm.
Just looking at the X-h output on a Linux box, and it has an option
Xquartz seems (maybe unsurprisingly) to lack:
-screen name ... specify the Screen section name
Which gave me a clue. :-)
Obviously there's no real xorg.conf anywhere for that to be defined; but
presumably (wild-guess?) there's some conversion layer that provides the
settings and environment X wants from out of the running Quartz state.
xdpyinfo is giving me:
screen #0:
print screen: no
dimensions: 3360x1050 pixels (1138x356 millimeters)
resolution: 75x75 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x3f
... etc.
And there is no screen #1.
If that layer that [is|must surely be] providing X configuration out of
Quartz's runtime state in lieu of an /etc/X11/xorg.conf could produce a
ServerLayout and Screen sections that actually reflect a multi-screened
Mac's setup at that moment rather than creating a single screen that's a
union of all the Mac screens... maybe all xinerama stuff would suddenly
start working? :-D
Logically, when I just run 'xdpyinfo' from an xterm (or even from
Terminal.app, hey that works! I shouldn't be surprised, should I?) I
ought to be seeing two Screen sections listed in my xdpyinfo output,
each one 1680x1050, each, presumably, with its own root window id; and
even better, with names taken straight out of the OS X display manager,
so in my case screen #0 would be called "iMac" and screen #1 would be
called "Cinema Display"; and the ServerLayout would be set so X11 knows
that "Cinema Display" is to the left of "iMac" with no vertical offset,
and so forth.
The *Quartz* layer knows all this stuff, it just ain't telling poor X11!
Maybe because it broke old xfree86's tiny mind. :-) And more recently,
maybe it's because you guys haven't been using multiple-screen Mac
setups so it never became obvious.
It seems the "right" solution, if it's doable. Then the -screen (and
possibly -layout) options to the X server that one finds in other
implementations could be enabled and I could just do Xquartz -screen
'Cinema Display' if I wanted an X server that was limited to one screen.
(The default would create a server that had both screens, of course,
using Xinerama to move X11's windows from one Mac screen to the other.)
Although, if the Xinerama stuff by itself was working (ie: so xdpyinfo
shows me two screens) then I probably don't even need to supply -screen
'Cinema Display'; as I think under Xinerama a window opening fullscreen
(Xephyr -fullscreen) would only fill the screen it's on. Although I
probably would still rather just run an xinit Xephyr -fullscreen --
-screen 'Cinema Display' or whatever's actually correct, to lose the
Xephyr window decorations and place it on the right screen at the
outset; and that could then be separate from another Xquartz -screen
'iMac' on :0 for any other ad-hoc X stuff I wanted to run.
ie, desired outcome:
(somehow) set up the default quartz-wm to use -screen "iMac"
Xquartz :1 -screen "Cinema Display"
DISPLAY=":1" Xephyr :2 -query 192.168.1.3 -fullscreen
and generally, ssh -X, xterm, whatever, would auto-open on display :0 on
screen "iMac" just as they do now in a screen that spans all displays.
Obviously that's not the default; the default would be that Xquartz
starts with two logical screens matching the Quartz displays, and
xinerama working; but the above should be all the setup I'd need to do
to get what *I* want working.
There'd probably be fun and games getting X11 to keep up with OS X's
ability to have these screens moved in relation to each other and taken
away and added dynamically; I'm not sure, but I think Xorg has some
mechanisms for doing that sort of thing now? I've seen ubuntu add and
remove screens and resize screens and keep the windows it had on them
anyway... It may not look as seamless as the Mac doing it by itself (but
maybe that's just because the Mac fades to blue to do it 'behind the
curtain' as it were) but it does appear to work.
For *now*, it seems like the quick workaround to get something like what
I want would be to use the -size parameter to Xquartz and do something
like this:
echo 'Xephyr :1 -query 192.168.1.3 -once -fullscreen' > ~/.xinitrc
xinit -- -size 1680 1050
(It doesn't seem to like me giving a Xephyr commandline on the client
side of the --. Not sure why. Maybe it doesn't like the :1?)
Anyway, it doesn't work. That is, it starts, it works, XDMCP and
everything works, but it continues to span both displays. Basically the
-size parameter to X or Xquartz is completely ignored.
Now, the Xquartz -h does actually *tell* me that the -size parameter
(among others) is ignored if Xquartz is running rootless but... I cannot
find a way of telling Xquartz *not* to run rootless! -fullscreen is
ignored (as you said), and there's no clear -rootful (or whatever it
ought to be called) option. It appears that -rootless is default and
implicit, on Xquartz, whereas everywhere else it's an option you turn
*on* so there's no option to turn it *off*. If I even tell it to draw a
black or white root window (-br, -wr) it's ignored. I still get a
rootless X screen spanning both displays.
So a quick fix would be the inclusion of some option to Xquartz that
*deselects* rootless mode; which should enable the -size parameter, and
then I get what I want. ;-)
But the better fix would be as I said above, to make X11's
ServerLayout/Screen data reflect Quartz's, so Xinerama actually can
work. :-)
It's quite funky at the moment dragging a slightly-transparent
gnome-terminal around the linux desktop and the way the backdrop
behind it lags like it's being lensed, but I suspect it's not
deliberate (and only noticeable as I'm using it over wifi right now.
Normal use would be through gigabit.
Buggy will eventually be not buggy.
Sure. :-) In this case though I don't think it was buggy, it was just
laggy because it was over wifi. I was just saying it looked funky :-)
Thanks for your comments. Please CC yourself on the fullscreen and
Xinerama bugs on the website to stay up to date and provide us with
feedback.
Trying to. It wasn't immediately obvious how to do so. Think I've done it.
Can't find the Xinerama bug; unless it's not got an obvious summary. If
you tell me I'm not being stupid and I haven't missed it, I'll submit a
new one with some of the text from this mail in it (about the
ServerLayout/Screen stuff should be inherited properly from Quartz for
Xinerama to work, and what happens at the moment because it isn't.)
--
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