[Xquartz-dev] RandR

Jeremy Huddleston jeremyhu at apple.com
Wed Jun 16 10:05:32 PDT 2010


Throwing xquartz-dev back into the loop...

On Jun 15, 2010, at 03:10, Jan Hauffa wrote:

> thanks for sending me the code, it was an interesting read. Their core enumeration and mode setting code is very similar to mine. The main difference is that they chose to write it in Obj-C. Then there is a lot of code related to creating a "shield window", which covers the menu bar and the dock. A lot of magic is needed to keep the windows created by the X server above the shield window. This should be functionally equivalent to the fullscreen mode in current XQuartz.

Yeah... I'd rather reuse code where available to make this cleaner... I think it'd be best to use the codepath we already have available (fullscreen).  There may be some cases where fullscreen depends on !rootless, and we may need to clean up those parts.  Currently we have 2 global bools that are related to the rootless/fullscreen state:

quartzEnableRootless is a BOOL that contains the mode that the user wants for primary use (rootless mode versus fullscreen mode).

quartzHasRoot is a BOOL that contains the fullscreen state (on or off)... (perhaps this needs to be renamed for clarity)

I seem to recall that quartzHasRoot might have some relevance in rootless mode... In any event, I remember pulling out my hair last time I had to deal with those settings, so this might be a good opportunity to nuke/rename quartzHasRoot and make that a bit more abstract for RandR's use.

> The interesting part is the interaction between mode switching and the fullscreen mode: They add the current screen size, adjusted to exclude the height of the menu bar, as a specially tagged entry to the list of supported resolutions.  If an application requests a mode switch to a "real" resolution, fullscreen mode is enabled. If the application switches back to the "fake" resolution, fullscreen mode is disabled. This is pretty clever, as it does what the user expects (most of the time) without requiring further intervention.

Yeah, this is what I was talking about in my earlier email:
"""
Perhaps we can do something "interesting" to tackle both of these issues.  We can include the resolution with the menu bar subtracted in the list of resolutions.  If XRandR chooses any resolution except that one, we can switch to quartz fullscreen mode (not the X11 cmd-alt-a fullscreen) in expectation of a game taking over like Codeweavers does.  Switching back to the normal resolution would then result in returning to normal mode.
"""

> While reading the code, I realized there are actually two issues related to RandR:
> 
> 1. An application might expect the screen size reported by Xinerama to
>   be available as a RandR resolution.

Yeah, this will "work" if we follow the route above where the default resolution is the one with the menubar subtracted.  Xinerama will be reporting that, and it'll be the first resolution reported by RandR.

> 2. If an application creates a window that covers the whole screen, its
>   Z order should be above the menu bar and dock.

If we are in fullscreen mode, this is handled for us (the window depths are specified in xpr/xpr.h)

Another corner case that we should keep in mind is interaction with multiple monitors...

> There are three possible solutions for the first problem:
> - Keep patch 2/4 as is, with unknown side effects on the internal working of the X server.
> - Enable RandR mode switching only if the server is in fullscreen mode. This means patch 2/4 can be dropped, as the size of the root window will be the same as the current resolution.
> - Report the adjusted screen size as a "fake" resolution with special cased handling. Again, we can drop patch 2/4.

I am for the third option here... then we can switch to a temporary fullscreen mode when we choose any of the other resolutions.

> The second problem is more complicated:
> - The proper solution (IMHO) would be to recognize the WM hint _NET_WM_STATE_FULLSCREEN in quartz-wm, and send a request to the server to enable fullscreen mode. However, quartz-wm is not open source, so I can't send a patch for this.

quartz-wm does recognize _NET_WM_STATE_FULLSCREEN, but it doesn't force the server to do something in response.  Instead, it "fullscreens" the application in the X11 screen (remember the menubar is not part of the X11 screen) with the caveat that the Dock is still visible.  This is what made sense for rootless mode.  In the server's fullscreen mode, the application does take up the entire physical screen.

If we go with the third option above, this should be handled for us automatically.  The application will use RandR to choose a different resolution (the server will goto "temporary fullscreen mode"), then it will create a _NET_WM_STATE_FULLSCREEN window, and quartz-wm will make it take up the entire screen. 

> - The alternative would be a heuristic like in the code provided by CodeWeavers. I rather like this approach, but it's a bit of a hack.

Yeah, let's try for code-reuse where possible.

> - Ignore the problem and make the user enable fullscreen mode manually. This is what my patch does right now...

This is a good first step, but I think we can give the first option a try to "just work" for users.

> Please let me know how you think about this; I'll send a new set of patches once I know what's the preferred approach. Also, what is the etiquette in this case? Should I post my findings to Xquartz-dev, so we can have a public discussion?

Yeah, go ahead and continue the discussion on xquartz-dev (and send each patch individually to help thread discussion appropriately).  Also, please try to work off of our latest git sources.  I pushed your first patch (dead code removal) already:

http://cgit.freedesktop.org/~jeremyhu/xserver/log/?h=server-1.9-apple

Thanks,
Jeremy



More information about the Xquartz-dev mailing list