<AWT Dev> RFR: 8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws AE: Unable to set display mode! [v3]

Phil Race prr at openjdk.java.net
Mon Jun 7 20:22:44 UTC 2021


> There are two issues here, both macOS specific.
> First the original reported one that occurs when running on a shared remote VNC type desktop on macOS.
> Only a single supported display mode is returned and it is also the current mode.
> A program that simply enumerates the reported modes and tries to set them, if it reaches the native layer,
> will fail because macOS reports the same display mode it returned as valid as now being illegal.
> It does not appear to be as simple as a user's permission level since it occurs with an admin user as well
> so it probably is the case that macOS simply does not allow this shared desktop to be changed although
> there's no docs I can find
> Ordinarily we would not have tried this since we test if the requested display mode is the same as the native
> one and skip it, but the provided test used REFRESH_RATE_UNKNOWN which is allowed as meaning match
> any mode that satisfies W,H,BPP. But this caused it to fail the equals test so the code is enhanced to check for that
> 
> Second, when creating a test it was discovered that *at least* on the built-in retina display of a 16" macbook pro,
> the system default contig is never in the list of available modes and can be discovered only by querying the *current* mode
> before any modes are changed. This beheaviour is 100% consistent no matter if the system was just rebooted, has
> an external monitor attached as well, or not, activates the discrete card, or not.
> 
> Since we've had code since at least 2013 that added the default mode I suspect this has been seen before but nowhere
> can I find an explanation.
> 
> It has odd consequences like after you change the display mode, you will no longer see the default display mode reported,
> so the list of available modes is reduced by one.
> But for a typical use case which doesn't re-query or more typically caches the original display mode in order to restore it, it presents a bigger problem that trying to restore will always fail. 
> 
> So the other thing this fix does is detect when we fail to restore the initial mode and try again in a different way.
> Only if that fails do we then throw an exception.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8267430: GraphicsDevice.setDisplayMode(REFRESH_RATE_UNKNOWN) throws IAE: Unable to set display mode

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4373/files
  - new: https://git.openjdk.java.net/jdk/pull/4373/files/d93be8fa..3a496412

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4373&range=01-02

  Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4373/head:pull/4373

PR: https://git.openjdk.java.net/jdk/pull/4373


More information about the awt-dev mailing list