-
Notifications
You must be signed in to change notification settings - Fork 903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get_current_monitor()
panics on Wayland.
#793
Comments
Welp. If this I'm not sure what would be the best thing to do here, given the API winit enforces. Would it make sens to take advantage of the pending breaking changes to change the prototype of |
I'd be fine with either returning If we go with |
That would not be possible for wayland. The only order that can be implemented there would be « the order in which the window entered the monitors », which is hardly useful. |
Thanks, good to know. Is there any way to find out a window's primary monitor on Wayland? I ask because on systems where different monitors have different DPIs, it can be useful to know which monitor the system considers to be the main monitor for DPI scaling, which I'd like to support if possible (on Windows that's done through the |
There is no concept of "primary monitor" in wayland. Regarding DPI, what happens is that the client app actually tells the server that it is drawing its contents using a given dpi factor, and the server takes care of upscaling or downscaling if that does not match the dpi factor of the monitor.
So what winit does currently is it takes the max() of the dpi factors of the monitors the window is currently displayed on, and lets the server down scale if necessary.
Le 13 février 2019 23:04:37 GMT+01:00, Osspial <notifications@github.com> a écrit :
…Thanks, good to know. Is there any way to find out a window's primary
monitor on Wayland? I ask because on systems where different monitors
have different DPIs, it can be useful to know which monitor the system
considers to be the main monitor for DPI scaling, which I'd like to
support if possible (on Windows that's done through the
[`MonitorFromWindow`](https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-monitorfromwindow)
function). If we can expose that alongside a list of all monitors the
window overlaps with that would be awesome.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#793 (comment)
|
I need to solve this for ggez. Is there a default I can replace the |
My guess is that we'd wrap that breaking change into EL2.0, or a release shortly afterwords. |
Does anyone work on this bug? I want to try to fix it. |
I don't think anyone is carrently working on it, so please do!
|
any news? |
nothing? |
Well, still fails on my system using winit 0.19.5 |
I'm working on that issue right now during some other rework, just could take a bit of time for me to finish. |
The main issue here is that returning winit uses I'm not sure how parameters to for such calls could be changed. I'm a bit afraid of adding things like If anyone has a suggestion on how API to enter fullscreen could look like wrt indication of system picking a monitor for you let me know. I kind of think that |
Just thinking more about that fullscreen startup problem on Wayland. I feel like we can change the
To
The I'm not sure what to do about What to do you think @chrisduerr , @murarth , @Osspial, @ryanisaacg , @francesca64 ? |
I'd say this calls for a third enum variant. |
I'm not sure about the third one, since it's actually a |
Having a |
I'd also prefer |
Ok ok, I get it :) |
On certain platforms window couldn't be on any monitor resulting in failures of `current_monitor` function on them, since they might return specific monitor. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `impl Iterator<Item = MonitorHandle>` will give ability to expose such behavior, as well as providew information about all current monitors, since window could be on both at the same time. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of `current_monitor` function on them, since they might return specific monitor. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `impl Iterator<Item = MonitorHandle>` will give ability to expose such behavior, as well as providew information about all current monitors, since window could be on both at the same time. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of `current_monitor` function on them, since they might return specific monitor. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `impl Iterator<Item = MonitorHandle>` will give ability to expose such behavior, as well as providew information about all current monitors, since window could be on both at the same time. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of `current_monitor` function on them, since they might return specific monitor. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `impl Iterator<Item = MonitorHandle>` will give ability to expose such behavior, as well as providew information about all current monitors, since window could be on both at the same time. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of `current_monitor` function on them, since they might return specific monitor. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `impl Iterator<Item = MonitorHandle>` will give ability to expose such behavior, as well as providew information about all current monitors, since window could be on both at the same time. Fixes rust-windowing#793.
On certain platfroms window couldn't be on any monitor resulting in failures of `current_monitor` function on such, since they can't return any monitor at all. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `Option<MonitorHandle>` will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platfroms window couldn't be on any monitor resulting in failures of `current_monitor` function on such, since they can't return any monitor at all. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `Option<MonitorHandle>` will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platfroms window couldn't be on any monitor resulting in failures of `current_monitor` function on such, since they can't return any monitor at all. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning `Option<MonitorHandle>` will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of 'current_monitor' function. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning 'Option<MonitorHandle>' will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of 'current_monitor' function. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning 'Option<MonitorHandle>' will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of 'current_monitor' function. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning 'Option<MonitorHandle>' will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes rust-windowing#793.
On certain platforms window couldn't be on any monitor resulting in failures of 'current_monitor' function. Such issue was happening on Wayland, since the window isn't on any monitor, unless the user has drawn something into it. Returning 'Option<MonitorHandle>' will give an ability to handle such situations gracefully by properly indicating that there's no current monitor. Fixes #793.
On Linux/Wayland, it seems that sometimes `window.current_monitor()` can return `None` when nothing has been drawn to the screen yet. When this happens, simply skip most of the logic and draw an empty frame to the screen. The next time `view()` is called, the `current_monitor()` method will then return the correct value. (See rust-windowing/winit#793 for some details.).
On Linux/Wayland, it seems that sometimes `window.current_monitor()` can return `None` when nothing has been drawn to the screen yet. When this happens, simply skip most of the logic and draw an empty frame to the screen. The next time `view()` is called, the `current_monitor()` method will then return the correct value. (See rust-windowing/winit#793 for some details.).
See: ggez/ggez#579
Basically, this function does a
some_vec.last().unwrap()
of aVec
that can be null. The vec appears to be acquired fromsctk::surface::get_outputs()
here: https://github.com/Smithay/client-toolkit/blob/2c28ada5c7dd067ac1245382bc371cc933d4c416/src/surface.rs#L109 . As far as I can tell, theoutputs
vec is created empty and only has things added to it onSurfaceUserData::enter()
, but I don't know enough about the Wayland protocol to understand what's actually going on there.The text was updated successfully, but these errors were encountered: