A couple of things: 1) I know I've been silent on the Xquartz Trac bugs -- I intend to make a pass through later today 2) Ken Thomases (of CodeWeavers / Crossover fame -- go buy their product) and I have been going back and forth for quite some time talking about the rootless bugs / architecture issues; He's had some good suggestions for tracking down the bugs that I haven't had time to implement, so I'm going to try to distill some info from that and send it out in a email -- again, later today. Hopefully they'll inspire one of you. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 3, 2007, at 16:13, Ben Byer wrote:
A couple of things: 1) I know I've been silent on the Xquartz Trac bugs -- I intend to make a pass through later today 2) Ken Thomases (of CodeWeavers / Crossover fame -- go buy their product) and I have been going back and forth for quite some time talking about the rootless bugs / architecture issues; He's had some good suggestions for tracking down the bugs that I haven't had time to implement, so I'm going to try to distill some info from that and send it out in a email -- again, later today. Hopefully they'll inspire one of you.
Do they involve gutting rootless and using kdrive perchance? I'm only half joking... --Jeremy
On Dec 3, 2007, at 5:28 PM, Jeremy Huddleston wrote:
On Dec 3, 2007, at 16:13, Ben Byer wrote:
A couple of things: 1) I know I've been silent on the Xquartz Trac bugs -- I intend to make a pass through later today 2) Ken Thomases (of CodeWeavers / Crossover fame -- go buy their product) and I have been going back and forth for quite some time talking about the rootless bugs / architecture issues; He's had some good suggestions for tracking down the bugs that I haven't had time to implement, so I'm going to try to distill some info from that and send it out in a email -- again, later today. Hopefully they'll inspire one of you.
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.) While talking this stuff over with Kevin and Jordan last night, the question arose of "why are we even using fb code at all, when we have all of these shiny libXplugin functions to move bits around?" It turns out there's a threshold, above which it uses the "accelerated" calls, and below which it uses the fb/ code. So, I put a hack in that disables the fb code if you create a file called "/tmp/ disable_fb.txt": http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=4dcd9106a89ceb6... If you're experiencing crashes in the fb/rootless code, I'd like to hear if enabling that fixes them. I'd also like to hear if it impacts performance. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.)
If that's the case, then we should not flatten out the directory structure but maintain a clear division in the interface to make switching to xcomposite as painless as possible. I just noticed that you committed your changes, do you mind if I back them out and try cleaning up the Makefile's the way I suggested?
On Dec 4, 2007, at 4:34 PM, Jeremy Huddleston wrote:
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.)
If that's the case, then we should not flatten out the directory structure but maintain a clear division in the interface to make switching to xcomposite as painless as possible. I just noticed that you committed your changes, do you mind if I back them out and try cleaning up the Makefile's the way I suggested?
Err... yeah. Go for it. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
On Dec 3, 2007, at 5:28 PM, Jeremy Huddleston wrote:
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.)
I took a quick look at Composite. It looks like it was designed to work inside a window manager. I'm not sure that makes sense in our environment. We could make quartz-wm also in charge of the Mac windows via Composite, but that might leave other window managers out in the cold. One alternative might be to use the Composite code paths in the server, without using the Composite extension directly. -- Greg Parker gparker@apple.com Runtime Wrangler
On Dec 4, 2007, at 4:36 PM, Greg Parker wrote:
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
On Dec 3, 2007, at 5:28 PM, Jeremy Huddleston wrote:
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.)
I took a quick look at Composite. It looks like it was designed to work inside a window manager. I'm not sure that makes sense in our environment. We could make quartz-wm also in charge of the Mac windows via Composite, but that might leave other window managers out in the cold. One alternative might be to use the Composite code paths in the server, without using the Composite extension directly.
Yeah, there's definitely some subtlety here. Keith Packard and I discussed this, here's some notes from a conversation that stretched over several months, while I tried and failed to make this happen: - - - - - If we call compRedirectSubwindows(serverClient, root, CompositeRedirectManual), then that will create pixmaps for all of the windows and keep those pixmaps up-to-date. We could then create damage structures for each backing pixmap, and then our block handler sends the updated bits to the target windows. If possible, we should point the composite pixmaps at the OS X backing buffer; that would make the code simpler and faster. (elaborating further) What composite gives you is per-window pixmaps. If you set the root window to automatically redirect all children, you'll have pixmaps for every mapped child. Then, hook CreateWindow to listen for damage on all children. Then, hack compWindowUpdateAutomatic to paint the right bits in a Quartz (Xplugin?)-specific manner, and once that's working we can abstract that out and get some hooks put into the DIX code. compWindowUpdateAutomatic currently uses Render to copy the child window onto the parent; change that to copy the child onto the OSX surface. Check if pParent->parent==NULL, and do your stuff. We might be able to handle frame creation lazily from the update hook, but we might be better off hooking the following functions: CreateWindow, DestroyWindow, RealizeWindow, UnrealizeWindow, ConfigureWindow, CloseScreen, PositionWindow, RestackWindow This would be a simplification over the current Rootless code, which hooks all of the above, as well as ValidateTree, ChangeWindowAttributes, MarkOverlappedWindows, ChangeBorderWidth, ReparentWindow, ResizeWindow, MoveWindow, SourceValidate, GetImage, CopyWindow, CreateGC, CreateScreenResources, and SetShape. - - - - - I tried for a week or two and utterly failed to gain any traction on this problem -- I got as far as that first compRedirectSubwindows call, but if I didn't have any of the rootless code enabled then I never got an initial Update message for anything, and if I left the rootless code enabled I got crashes and odd behavior. There are certainly many more things we could do in the realm of compositing -- there may be things we can leverage more Quartz goodness for -- but for a first approximation, we'd just be using it to get pixmaps and updates. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 4, 2007 4:36 PM, Greg Parker <gparker@apple.com> wrote:
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
On Dec 3, 2007, at 5:28 PM, Jeremy Huddleston wrote:
Do they involve gutting rootless and using kdrive perchance? I'm only half joking...
No, but I *swore* I mentioned the analogous 100% serious suggestion from the X.org folks that we gut rootless and use xcomposite. (I don't know that kdrive solves the problem that we're trying to solve here.)
I took a quick look at Composite. It looks like it was designed to work inside a window manager. I'm not sure that makes sense in our environment. We could make quartz-wm also in charge of the Mac windows via Composite, but that might leave other window managers out in the cold. One alternative might be to use the Composite code paths in the server, without using the Composite extension directly.
I'm certainly not an expert, but it does seem to me that Composite is a very promising approach. It basically turns the X server into a rendering library for window contents instead of a full desktop window system. This is exactly what we want! Just have it render to the backing stores of the windows of a Cocoa application -- native window management for free! I'm oversimplifying, I'm sure, but it seems like an attractive option. As for alternative window managers, well, other window managers are already out in the cold. They can't interleave windows with native windows and generally don't behave naturally on OS X. But this is not an either-or thing -- other window managers can use the traditional code paths while OpenQuartzWM (the shiny new open-source version of quartz-wm ;^) can use the Composite path. Another thought worth considering -- should we perhaps be writing a composite manager *instead* of (or in addition to) a window manager? Existing window managers are OK at handling X windows, they just don't know about compositing with the other Aqua windows on the OS X desktop. Maybe writing a native compositer could solve that. Cheers, -n8 --
-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->
On Dec 5, 2007, at 11:36 AM, Nathaniel Gray wrote:
On Dec 4, 2007 4:36 PM, Greg Parker <gparker@apple.com> wrote:
I took a quick look at Composite. It looks like it was designed to work inside a window manager. I'm not sure that makes sense in our environment. We could make quartz-wm also in charge of the Mac windows via Composite, but that might leave other window managers out in the cold. One alternative might be to use the Composite code paths in the server, without using the Composite extension directly.
I'm certainly not an expert, but it does seem to me that Composite is a very promising approach. It basically turns the X server into a rendering library for window contents instead of a full desktop window system. This is exactly what we want! Just have it render to the backing stores of the windows of a Cocoa application -- native window management for free! I'm oversimplifying, I'm sure, but it seems like an attractive option.
As for alternative window managers, well, other window managers are already out in the cold. They can't interleave windows with native windows and generally don't behave naturally on OS X. But this is not an either-or thing -- other window managers can use the traditional code paths while OpenQuartzWM (the shiny new open-source version of quartz-wm ;^) can use the Composite path.
Other WMs may behave unnaturally, but they *do* work. I bet you'd hear a lot of screaming if we threatened to take them away. We really don't want to keep both Rootless and something that replaces it; that's just asking for trouble down the road when one side doesn't get enough testing.
Another thought worth considering -- should we perhaps be writing a composite manager *instead* of (or in addition to) a window manager? Existing window managers are OK at handling X windows, they just don't know about compositing with the other Aqua windows on the OS X desktop. Maybe writing a native compositer could solve that.
That's the part I'm not sure about. I don't know whether using a composite-unaware window manager together with a composite manager works in practice. I also don't know what happens if you try to use a window manager that *does* use composite together with a composite manager (which is what happens if we use composite in the server for windows and a user uses some-random-wm on top). They might conflict while trying to take over control of top-level windows. -- Greg Parker gparker@apple.com Runtime Wrangler
On Dec 5, 2007 2:29 PM, Greg Parker <gparker@apple.com> wrote:
On Dec 5, 2007, at 11:36 AM, Nathaniel Gray wrote:
As for alternative window managers, well, other window managers are already out in the cold. They can't interleave windows with native windows and generally don't behave naturally on OS X. But this is not an either-or thing -- other window managers can use the traditional code paths while OpenQuartzWM (the shiny new open-source version of quartz-wm ;^) can use the Composite path.
Other WMs may behave unnaturally, but they *do* work. I bet you'd hear a lot of screaming if we threatened to take them away.
I don't know, I bet you'd hear a small handful of users screaming (though I'm sure they'd scream loudly!). I bet it'd be considerably less than the (justified) screaming we've heard about spaces-related bugs, windows not raising, wrongly-styled window decorations, and all the other window management related bugs that pop up because we have to fake a parallel version of the Aqua window manager.
We really don't want to keep both Rootless and something that replaces it; that's just asking for trouble down the road when one side doesn't get enough testing.
Ok, just drop rootless. If you want to run a different WM you probably want it in fullscreen anyway since it won't work properly with Aqua windows, and you can use xnest for that. Bah. The more I think about it, the more I'm convinced that trying to allow non-native window managers is just a waste of brain-cycles. Mac OS X is not X11. The goal should be to seamlessly support X11 *applications* not X11 desktop environments.
Another thought worth considering -- should we perhaps be writing a composite manager *instead* of (or in addition to) a window manager? Existing window managers are OK at handling X windows, they just don't know about compositing with the other Aqua windows on the OS X desktop. Maybe writing a native compositer could solve that.
That's the part I'm not sure about. I don't know whether using a composite-unaware window manager together with a composite manager works in practice. I also don't know what happens if you try to use a window manager that *does* use composite together with a composite manager (which is what happens if we use composite in the server for windows and a user uses some-random-wm on top). They might conflict while trying to take over control of top-level windows.
Doctor, it hurts when I do that... ;^) Cheers, -n8 --
-- Nathaniel Gray -- Caltech Computer Science ------> -- Mojave Project -- http://mojave.cs.caltech.edu -->
On Dec 5, 2007, at 3:11 PM, Nathaniel Gray wrote:
We really don't want to keep both Rootless and something that replaces it; that's just asking for trouble down the road when one side doesn't get enough testing.
Ok, just drop rootless. If you want to run a different WM you probably want it in fullscreen anyway since it won't work properly with Aqua windows, and you can use xnest for that.
Bah. The more I think about it, the more I'm convinced that trying to allow non-native window managers is just a waste of brain-cycles. Mac OS X is not X11. The goal should be to seamlessly support X11 *applications* not X11 desktop environments.
I'm forced to agree here. It seems like the best compromise for people that, say, want to run a Gnome desktop is for them to do it in one full-screen "Space" -- whether that means we get magic mojo working where you can do a Spaces-transition into a suddenly-working fullscreen mode in Xquartz, or if we tell people to just use Xephyr, I don't know. The Xephyr solution seems a lot easier, at least. The only "gotcha" I know of there is that cut'n'paste doesn't seem to work between apps in Xephyr and the outside world. (I haven't tested this, but I seem to recall someone stating this was the case.) Fixing that falls under the heading of "fixing broken cut and paste in general", though. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
It turns out there's a threshold, above which it uses the "accelerated" calls, and below which it uses the fb/ code. So, I put a hack in that disables the fb code if you create a file called "/tmp/disable_fb.txt": http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=4dcd9106a89ceb6...
If you're experiencing crashes in the fb/rootless code, I'd like to hear if enabling that fixes them. I'd also like to hear if it impacts performance.
Anyone try this yet? Reports of rootless crashes on the "old and busted" 10.5.0 Xquartz continue to stream in, and I know we didn't fix all of them (yet) in Xserver-1.3. If I don't hear back soon, I'm just gonna turn that hack on permanently until someone tells me why I shouldn't. :) -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
I think the only way you're going to get any genuine feedback is to release another point release with that enabled, then you'll know when people send you crash reports whether or not they actually enabled it. - Jordan On Dec 5, 2007, at 6:25 PM, Ben Byer wrote:
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
It turns out there's a threshold, above which it uses the "accelerated" calls, and below which it uses the fb/ code. So, I put a hack in that disables the fb code if you create a file called "/tmp/disable_fb.txt": http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=4dcd9106a89ceb6...
If you're experiencing crashes in the fb/rootless code, I'd like to hear if enabling that fixes them. I'd also like to hear if it impacts performance.
Anyone try this yet? Reports of rootless crashes on the "old and busted" 10.5.0 Xquartz continue to stream in, and I know we didn't fix all of them (yet) in Xserver-1.3. If I don't hear back soon, I'm just gonna turn that hack on permanently until someone tells me why I shouldn't.
:) -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Yeah, good idea. I'll release one in a few hours once I'm finished reorganizing some stuff. --Jeremy On Dec 5, 2007, at 19:22, Jordan K. Hubbard wrote:
I think the only way you're going to get any genuine feedback is to release another point release with that enabled, then you'll know when people send you crash reports whether or not they actually enabled it.
- Jordan
On Dec 5, 2007, at 6:25 PM, Ben Byer wrote:
On Dec 4, 2007, at 4:02 PM, Ben Byer wrote:
It turns out there's a threshold, above which it uses the "accelerated" calls, and below which it uses the fb/ code. So, I put a hack in that disables the fb code if you create a file called "/tmp/disable_fb.txt": http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=4dcd9106a89ceb6...
If you're experiencing crashes in the fb/rootless code, I'd like to hear if enabling that fixes them. I'd also like to hear if it impacts performance.
Anyone try this yet? Reports of rootless crashes on the "old and busted" 10.5.0 Xquartz continue to stream in, and I know we didn't fix all of them (yet) in Xserver-1.3. If I don't hear back soon, I'm just gonna turn that hack on permanently until someone tells me why I shouldn't.
:) -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
participants (5)
-
Ben Byer
-
Greg Parker
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Nathaniel Gray