On Mon, 7 Jun 2021 15:17:48 GMT, Phil Race <p...@openjdk.org> wrote:
>> 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
src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 341:
> 339: * that mode reported and it restores all devices, but
> 340: * this seems a better compromise than failing to restore
> 341: */
Would like to highlight that this tradeoff will break the spec, since we
successfully restore the mode which is not in the list of modes.
test/jdk/java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java line
67:
> 65: } finally {
> 66: System.out.println("restoring original mode"+odm);
> 67: d.setDisplayMode(odm);
I suggest waiting here as well.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4373
