[Xquartz-dev] XQuartz 2.6.0_rc1 (for Leopard and Snow Leopard)

Jeremy Huddleston jeremyhu at apple.com
Thu Jan 27 20:59:11 PST 2011


On Jan 27, 2011, at 19:48, doh123 wrote:

> ok... that was great Info... I have it partially working... I have it drawing correctly and changing resolutions of only the primary monitor (my point is for fullscreen gaming.. I don't want the secondary at all in fullscreen).
> 
> problems I'm having right now... I could use some pointers on how to fix these.
> 
> The secondary monitor is staying on and activated, makig it possible for the mouse to still move into it.  How can you disable this?

So the problem here is that you're making a RandR mode for just the first monitor, but after the mode changes for that monitor, X11 notices the mode change and creates a desktop spanning the two monitors.

That is actually very deeply engrained in how XQuartz works and might be a bit tricky (read: hacky) to fix.  

The way RandR works is that we schedule an OSX display mode change, then we respond to an event telling us that the mode has changed.  We assume that the first event received after our request is a result of our request (which can actually be an incorrect assumption if an error occurred or you're trying really hard to race the resolution change with another application).

When we respond to a mode change (kXquartzDisplayChanged in darwinEvents.c), we'll need to detect that we only want to use the first monitor.  We can probably do that based on our RandR mode.

>  I was looking through quartz display services trying to figure out how I can set it to inactive or disabled or something, but I haven't really figured it out.  

You'll need to take a look at xprScreen.c ... specifically xprAddPseudoramiXScreens.  There's a loop in there that goes through all the CG screens and combines them into one big mega-screen.  You'll probably want to add logic in there to only use the first screen when appropriate.  There will probably be some odd issues with this.  I'm not sure if the mouse cursor will be restricted to the primary display or not.  I remember that a while back, the X11 pointer was restricted to the region defined by the X11 screen, but I think I "fixed that" so the pointer could wander outside the region, and we just project the OSX pointer location back to the X11 region for the X11 event.  You may need to do an XWarpPointer "somewhere" if you want to restrict the pointer to the screen.

> I want to set every monitor except the primary to inactive anytime its changing to a non-Rootless display mode.. is there a way to do that?  

Hmm... I was thinking that we just "ignore" those displays, but I think you may be on to something there.  Unfortunately, I don't see anything in CGDisplay that could do that... but I believe that if you capture the display, restrict the pointer, and "do the right thing" with the Pseudorami support, it might be sufficient.

> Configuring displays looks a bit confusing to me.  Is that the right direction to go in?

Yeah, it's messy.  Hopefully the above tips can help you in the right direction.

> The mouse is not working correctly.  It appears to be stuck on input on the secondary monitor, and clicks and movements are mainly over there... which is odd.  I think if i fix the first problem, the second problem here might fix itself.

I'm not sure what you mean by "stuck on input on the second monitor", but hopefully that will just go away with the above work.  Keep me informed.  I'll do what I can to help you along.

--Jeremy


> 
> 
> On Jan 27, 2011, at 1:45 PM, Jeremy Huddleston wrote:
> 
>> 
>> On Jan 27, 2011, at 10:20, doh123 wrote:
>> 
>>> I'm trying to dig into multi-monitor problems a bit along with fullscreen usage...
>>> 
>>> Right now if there are two monitors, RandR only knows the 2 sizes for rootless and a single fullscreen.  Where in Xquartz code could I look for where this is set up?  
>> 
>> Look in quartzRandr.c for "pQuartzScreen->displayCount" ... You'll see tests for that > 1 which is the multi-monitor case. 
>> 
>> As an aside, the crash just reported about crashing when waking from display sleep is probably related to the "== 0" case not being handled properly.
>> 
>>> I'd like it to be able to poll the primary monitor so that it has and can use all the primary monitor's resolutions, as well as the rootless two screen resolution... this is what it seems that Codeweaver's does with Crossover too.
>> 
>> Polling it is the easy part.  Changing to it is probably a more challenging part.
>> 
>>> 
>>> On Jan 25, 2011, at 12:40 AM, Jeremy Huddleston wrote:
>>> 
>>>> 
>>>> On Jan 24, 2011, at 14:56, doh123 wrote:
>>>> 
>>>>> ok.. where in Xquartz can I set some type of global variable so that I can keep the last known randr changed mode...  
>>>> 
>>>> Check out quartzRandR.h where you'll see QuartzScreenRec defined.  This record contains QuartzModeInfo for the "fake" rootless, fullscreen, and current modes.  You could certainly add one there for some other purpose, but I worry about adding too much complexity to this fragile system.
>>>> 
>>>> I'm especially concerned about what we should do about it during a display re-configuration event.
>>>> 
>>>>> I think I have most of the coding down to remember it and change it back right when pressing the key combo... but I need it to store the last mode it has switched to always so I can call that mode back... and I'm not seeing anywhere I can set a QuartzModeInfoPtr that will retain the info... which is probably just due to a lack of my programming skills  :-)
>>>>> 
>>>>> I was thinking of keeping a variable lastKnownRandRMode which is a QuartzModeInfoPtr and set anytime RandR changes modes, unless changing to rootless... so I can call that mode anytime someone is in Rootless and presses the key combo.  I'm just not sure where to put lastKnownRandRMode that it will ... survive.
>>>>> 
>>>>> On Jan 24, 2011, at 1:29 PM, doh123 wrote:
>>>>> 
>>>>>> When I CMD+Alt+A it seems to draw the app as an unmovable box of a window with no decoration at the top left... thats just fine with me though a movable one would be preferable, but not feasible I'd think since it thinks its still drawing fullscreen... this means programs will NOT crash doing this, they'll just be in an unmovable window... either fullscreen size, or smaller.
>>>>>> 
>>>>>> CMD+Alt+A is not toggling though... once it switching to rootless like this, with that unmovable box there, theres no way to get back without either going in game and switching resolutions, or launching xterm and using xrandr.  I think a quick patch to make CMD+Alt+A (and whatever other keystrokes) actually toggle... to switch and and forth would be most ideal...
>>>>>> 
>>>>>> I grabbed a copy of Crossover and tried a couple of easy tests with it... Crossover doesn't play any nicer than Xquartz is right now... same test apps have the same issues really.  Its also completely locking me in fullscreen with no multitasking at all without switching the apps to windowed mode.  So if we put in a toggle on any key combo, it'll be a step above Crossover's X11.
>>>>>> 
>>>>>> I just suggested other keys because.. originally a free key combo had to be selected, but with display capturing, all the normal key combos are disabled anyways since the app that did the capturing is supposed to handle them itself.
>>>>>> 
>>>>>> Since it switches from Fullscreen to a little fullscreen block stuck on the desktop, I'd suggest just setting multiple keystrokes to do the toggle.  CMD+Tab is well known to get out, as well as its kind of switching to a "window" so CMD+Enter would make since... but I'd not get rid of the CMD+Alt+A either.  Maybe those three all do the same toggle.
>>>>>> 
>>>>>> I'll dig in and try to find where CMD+Alt+A is set when I get a chance and see about adding multiple combos and setting a bool to track and toggle.. though I don't think the toggle will be that easy since we'll have to track what resolution to go back to correctly.  Maybe have a variable that stores the resolution that was set when someone hits the key combo... and use that resolution and blank it out when someone hits it again, so it knows the resolution and which mode its in wether a resolution is stored there or not.  normal randr changes would have to update it too I guess... Any place you can tell me to look for this stuff would be appreciated... or if you have a better idea of how it should work.
>>>>>> 
>>>>>> -doh123
>>>>>> 
>>>>>> On Jan 24, 2011, at 12:32 PM, Jeremy Huddleston wrote:
>>>>>> 
>>>>>>> If we are to do something like this, I'd like to maintain consistency with what CodeWeavers does.  How have they addressed this problem with fullscreen games?  Do they have a key sequence to switch applications / hide / minimize while captured?  If so, we should adopt the same sequences.
>>>>>>> 
>>>>>>> --Jeremy
>>>>>>> 
>>>>>>> 
>>>>>>> On Jan 24, 2011, at 10:09, doh123 wrote:
>>>>>>> 
>>>>>>>> actually just just double checked CMD+Alt+A and it does auto switch back to the rootless resolution...
>>>>>>>> 
>>>>>>>> I need to try to put something in that does not do that I believe.  A fullscreen game drawing directly with no actual window can totally screw up if it tries to change to rootless... some games will change the resolution ok to match the new rootless res, many will not have an available mode to match and crash... I was thinking of making a keystroke that would... just release and Hide without changing modes... or something else that could prevent apps from having problems.
>>>>>>>> 
>>>>>>>> I think it would be a good idea, if display capturing goes in like this to change that to a more recognizable keystroke.. or at least put multiple options to do it, like CMD+Tab as well, since CMD+Tab doesn't work at all in a captured display anyways.
>>>>>>>> 
>>>>>>>> On Jan 24, 2011, at 11:48 AM, Jeremy Huddleston wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Jan 23, 2011, at 23:20, doh123 wrote:
>>>>>>>>> 
>>>>>>>>>> Question...
>>>>>>>>>> 
>>>>>>>>>> Where/How would I go about putting a shortcut key command in Xquartz?
>>>>>>>>> 
>>>>>>>>> Check out sendEvent in X11Application.m
>>>>>>>>> 
>>>>>>>>>> basically when the display is captured, theres no way to switch to another program.  
>>>>>>>>> 
>>>>>>>>> cmd-alt-a should still work.  Does it not?
>>>>>>>>> 
>>>>>>>>>> What I'd like to do is somehow bind pressing CMD+Tab CMD+H and/or CMD+M (since they do nothing) to actually do something.  I'd like to find a way to make any of these release display capturing and then Hide Xquartz.  Then have Xquartz, anytime after that just happened when its reactivated, to capture the screen again like before...
>>>>>>>>>> 
>>>>>>>>>> basically anything for multitasking of some sort is good even if its not ideal  :-)
>>>>>>>>>> 
>>>>>>>>>> attached is the current screen capturing patch that seems to work ok so far.
>>>>>>>>>> 
>>>>>>>>>> <dcapture.patch>
>>>>>>>>>> 
>>>>>>>>>> On Jan 23, 2011, at 6:49 PM, Jeremy Huddleston wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Jan 23, 2011, at 16:37, doh123 wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> yeah, the captured display is always like a 2 billion level on the shielding window...  I'm just not sure how to actually code the changes to tell it to change the windowing levels so it will use the max one.  
>>>>>>>>>>> 
>>>>>>>>>>> Change rooted_window_levels in xpr.h
>>>>>>>>>>> 
>>>>>>>>>>>> Can I just call the xpr function and reset the levels?  I'm just a bit clueless on the structure of the program and what part does what functions... so feel a little lost when hacking away at the code.
>>>>>>>>>>>> 
>>>>>>>>>>>> I don't think any other app is really grabbing focus.  Doesn't an app that grabs focus actually change the top menu bar?
>>>>>>>>>>> 
>>>>>>>>>>> If you search the archives, you'll see that these are applications that grab focus and then drop it (or run and have a very small life).
>>>>>>>>>>> 
>>>>>>>>>>>> What happens is, every window (rootless or fullscreen) including the shielding window, lose focus... nothing else really grabs focus, and Xquartz is still the active application... its just all windows lose focus for a second or two, then the last window that was in focus comes back into focus if you haven't click on anything.  Its not actually changing to another app...  I've reproduced this on many many machines now, even with bare minimum software running to get OSX to run, including getting rid of Dashboard or anything else that could be problematic, and it never changes... just once an hour or two, sometimes only takes 10 minutes... its totally random... just "poof" and all X11 windows lose focus... then come back.  Its highly annoying in fullscreen since it hides the shielding window and you lose the whole fullscreen and see the desktop... it happens more often when I'm not running quartz-wm than when I am. (I never run it in fullscreen)
>>>>>>>>>>> 
>>>>>>>>>>> Yep.  That's consistent with what has been reported over the past few years.  Some people were able to fix this by disabling lastfm, itunes helper, ical helper, growl, and some others.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Xquartz-dev mailing list
>>>>>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Xquartz-dev mailing list
>>>>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Xquartz-dev mailing list
>>>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Xquartz-dev mailing list
>>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Xquartz-dev mailing list
>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xquartz-dev mailing list
>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xquartz-dev mailing list
>>>>> Xquartz-dev at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xquartz-dev mailing list
>>>> Xquartz-dev at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>> 
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev



More information about the Xquartz-dev mailing list