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

Thu Jan 27 10:20:58 PST 2011

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?  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.

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
> 