-
Notifications
You must be signed in to change notification settings - Fork 928
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
[BUG] attempted to leave type platform::platform::x11::util::input::PointerState
uninitialized
#1773
Comments
The latest version of winit is 0.23.0, not 0.19.5. Have you confirmed that this issue is still present in the latest winit version? |
Confirmed that winit 0.23 works fine. Upgrading out of winit 0.19 is just a breaking change for ggez, so it's kind of tricky. It doesn't look like there's a branch for winit 0.19, so I presume submitting a patch to fix it wouldn't result in a winit 0.19.6 with this fixed. |
See, having ggez on an ancient winit version has already caused this one bug with maintenance overhead. For winit there's no good reason to keep supporting it. There's nothing inherently wrong with new winit versions and forcing downstream to update only has benefits for winit. It's not like 0.19 is a LTS release or anything like that. The only supported version of winit is the latest one and everyone is encouraged to update that. If previous versions suddenly break completely, that's just more of an incentive to update as far as winit is concerned. So realistically I feel like allowing patches to 0.19 would just make the situation worse. Any effort put in to support that old version, review code, write that code and maintain it, would be much better spent updating ggez to the latest winit version. |
I'm against patching 0.19.x, since Wayland is entirely broken on it, and bringing it up to date on it is insane amount of work, which I won't do. So please, don't use 0.19.x. |
ggez is already on the latest winit version on the devel branch. Since there are other libraries running into this issue, I appreciate that you opened this to link to @icefoxen ^^ |
Yeah, it's perfectly reasonable to not support/patch 0.19. Just wanted to have a single point to gather info/links for people having this problem and what the solution is. Using Rust 1.47 works fine, and updating Winit works fine, so. ❤️ |
Update canvas_nanovg example The `canvas_nanovg` example would not run on my Linux machine due to the bug in `winit` 0.19 (rust-windowing/winit#1773) In this PR, I updated `winit` and `surfman` and made the minimum necessary changes so that the example would compile and run.
This change updates to the latest version of glium (0.30), which brings glutin to version 0.27 and winit to 0.25. This fixes known issue [#1773](rust-windowing/winit#1773) in winit 0.19 on Linux X11. The key stubstanitive change to the examples is the change from glutin's `EventsLoop` to `EventLoop`. Instead of a user-defined while loop where `EventsLoop::poll_events` is called, `EventLoop` has switched to a run function which is event-driven by glutin's core. This slightly changes the program structure. The other changes are minor, as glutin moved a few data structures into modules instead of having everything visible at the top-level.
The latest published surfman (0.4.3) expects winit 0.24. Upstream winit issue: rust-windowing#1773
The latest published surfman (0.4.3) expects winit 0.24. Upstream winit issue: rust-windowing/winit#1773
This change updates to the latest version of glium (0.30), which brings glutin to version 0.27 and winit to 0.25. This fixes known issue [#1773](rust-windowing/winit#1773) in winit 0.19 on Linux X11. The key stubstanitive change to the examples is the change from glutin's `EventsLoop` to `EventLoop`. Instead of a user-defined while loop where `EventsLoop::poll_events` is called, `EventLoop` has switched to a run function which is event-driven by glutin's core. This slightly changes the program structure. The other changes are minor, as glutin moved a few data structures into modules instead of having everything visible at the top-level.
This is a bug with winit 0.19, so I dunno if it's reasonable to expect a fix, but this appears to be hitting a couple different projects so it deserves to be consolidated here.
Characteristic backtrace:
Downstream bugs:
platform::platform::x11::util::input::PointerState
uninitialized ggez/ggez#843platform::platform::x11::util::input::PointerState
uninitialized amethyst/amethyst#2524This occurs on Rust 1.48+ due to tightening some constraints over what can be non-initialized: rust-lang/rust#66059
The text was updated successfully, but these errors were encountered: