I don't have a setup that I could test this with right now. I'll grab a Lightning Digital AV Adapter from the store later today and I can give this a try then.

I can't seem to be able to detect more than a single screen with available_monitors when I have an external display connected. I thought it was just a quirk in the Simulator, but it also seems to happen with a real device and an actual external display. I believe that iOS only ever lists a single video mode for the device's own display, and only lists multiple video modes for external displays. Did you test this with an external display?

(@zegentzy you probably should've waited to merge this until after @aleksijuvani came back with feedback... Finland is very much a different timezone, so you didn't even give them a chance. Plus, @mtak- explicitly requested review from them.)

I tested enough to get a green screen up on an external display using two methods (device only):

1. AppleTV and screen mirroring (iphone 8, iphone Xs, and ipad pro 12.9 3rd gen). Once you've mirrored the ios device to the appletv screen you can then get a list of monitors (after the event loop starts).
2. HDMI using a usbc-hdmi adapter directly plugged into an ipad pro 12.9 3rd gen. It should auto mirror, and after the event loop starts, you should be able to get a list of monitors.

I am not sure if getting a list of monitors is possible before the event loop begins?

Also FWIW, I never saw more than 1 video mode per monitor. I suspect appletv only supports 1 video mode (current mode is read only on tvos), but even when directly using HDMI I only saw 1 video mode for the TV... Perhaps testing against a PC monitor would have different results.

(@zegentzy you probably should've waited to merge this until after @aleksijuvani came back with feedback... Finland is very much a different timezone, so you didn't even give them a chance. Plus, @mtak- explicitly requested review from them.)

My bad, I did not notice this. I saw it was approved, and gave it a quick skim, and it looked okay. Sorry folks.

I see! It's interesting that no external displays are reported until after the event loop has started running. I've moved the function call until after the event loop starts, and I'm now indeed seeing the external display being reported. I've tested this with a Dell P2715Q display via HDMI using the Digital AV Adapter on an iPhone 6s, and it is reporting multiple video modes for this display.

I put together an application with gfx-hal that creates two windows and clears them to different colors. It appears that the "video mode change" (in quotes because it's apparently not an actual mode change, but affects how iOS presents the application on the display) functions properly, as the window's origin and scale change on the display.

However, the cleared rectangle is not updated to the new bounds of the display, but remains the same size (scaling non-withstanding), even though resize events are emitted for the window. This is also an issue with the "borderless" fullscreen mode, so I don't think it's caused by the changes in this pull request. I'm not sure if this is an issue with winit or with gfx-hal.

It's completely undocumented that -[UIScreen screens] requires UIApplicationMain to have been called, but it's not at all shocking. Probably most of UIKit makes that assumption.

My sample app, also using gfx, had the fullscreen call happen after touch, and the window and swapchain were resized appropriately to fit the new screen (1920x1080). I am using a custom UIView class via with_root_view_class with a backing CAMetalLayer. Are you recreating the swapchain after the resize event and redrawing? I'm glad the video modes call is working as expected!

Thank you for testing this!

Interesting! Thank you for the insight. I'm not creating a UIView myself, but I'm instead relying on the one supplied by winit, with a CAMetalLayer created for me by gfx-hal. Perhaps this is where things are going wrong. I'll look into this tomorrow. I also had the fullscreen call happen on a touch event. I'm trying this out with the alternative swapchain implementation (gfx-rs/gfx#2882), and I am indeed resizing the swapchain after receiving a resize event. I ought to try this with the old swapchain implementation as well.

gfx-rs/gfx#2882 is what I've been testing against as well.

It turns out that gfx-hal was creating the CAMetalLayer as a sublayer, and these don't get automatically resized when the view changes size. I've opened gfx-rs/gfx#2937 for this. Everything seems to work correctly when we port the changes in that PR over to gfx-rs/gfx#2882 (i.e. just copy the setFrame call over to the new configure function).