| Summary: | wayland: Add support for relative mouse mode | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Jonas Ådahl <jadahl> |
| Component: | video | Assignee: | Gabriel Jacobo <gabomdq> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | anakin.cs, bugzilla, gabomdq, kazimieras.vaina, philipp.wiesemann |
| Version: | HG 2.1 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: |
wayland: Add support for relative mouse mode
wayland: Build own version of core protocol wayland: Add support for relative mouse mode |
||
Is there any progress on this? Isn't it what's needed for FPS games to work properly on wayland? Created attachment 2507 [details]
wayland: Build own version of core protocol
This patch changes SDL to not load protocol symbols on demand, but instead include them at build time. This is needed to support protocol extensions.
Created attachment 2508 [details] wayland: Add support for relative mouse mode Here is a new version of the patch that adds support for relative mouse mode (including non-accelerated pointer deltas and pointer locking). This new version doesn't rely on building with --disable-wayland-shared; it should work either way. The two new patches can also be found at https://bitbucket.org/jadahl/sdl/commits/branch/pointer-lock-v4 Comment on attachment 2381 [details]
wayland: Add support for relative mouse mode
Marking the old patch as obsolete.
Including "SDL_log.h" might not be needed. :) Are these the only patches needed? Does gnome and Xorg already have everything they need? (In reply to anakin.cs from comment #6) > Are these the only patches needed? Does gnome and Xorg already have > everything they need? Yes, they should work out-of-the-box with GNOME 3.20. Xorg has no part in this. Weston still doesn't support it, but there are patches. Starting from today, the feature these patches implement should work on today's weston master branch as well. Thanks so much for your contribution, I'm really looking forward to merging these patches...however, a few questions first (keep in mind I haven't touched the Wayland backend in a while so I may be asking pointless questions). 1) I saw on your Wayland commits that the protocol is still unstable, is there any expectation of when it will be marked as stable? 2) Is there a way to remove the protocols/scanner dependency and use standard headers like the rest of the backend does? If not, why? (I see on a later comment you state that the dynamic build is now supported). 3) How do you test this? (What's a simple test case I can use, do I just build the lastest Weston from git or can I use a Ubuntu release from somewhere?) (In reply to Gabriel Jacobo from comment #9) > Thanks so much for your contribution, I'm really looking forward to merging > these patches...however, a few questions first (keep in mind I haven't > touched the Wayland backend in a while so I may be asking pointless > questions). > > 1) I saw on your Wayland commits that the protocol is still unstable, is > there any expectation of when it will be marked as stable? Eventually. Note that while it is unstable, backward incompatible changes will be handled gracefully, as in the feature will only be enabled if a compatible unstable version is discovered. When we want to declare it stable, be it after another iteration or not, I will submit new patches making the necessary changes. If wanted, one can support any number of unstable versions and the stable, or just move onto the stable. When the protocol is declared stable, it is promised that it will never change in any backward incompatible way. > 2) Is there a way to remove the protocols/scanner dependency and use > standard headers like the rest of the backend does? If not, why? (I see on a > later comment you state that the dynamic build is now supported). No. You will want to support various protocol extensions eventually (like the pointer constraints/relative pointer and eventually xdg-shell (the replacement for the proof-of-concept wl_shell) and other extensions), and for that you'll need to use wayland-scanner to translate the protocol XML files to the corresponding C bindings. Note that since dlsym is used for lazy loading, we also need to use wayland-scanner to generate the core protocol C bindings, since otherwise protocol extension C bindings won't be able to link. > 3) How do you test this? (What's a simple test case I can use, do I just > build the lastest Weston from git or can I use a Ubuntu release from > somewhere?) With the lack of better test cases, I used ioquake3 to test the SDL code. You can build weston from master, or use GNOME 3.20 or newer as long as you run the Wayland session. |
Created attachment 2381 [details] wayland: Add support for relative mouse mode This adds two new build time dependency: wayland-protocols and wayland-scanner. wayland-scanner is used to generate one C source file and one C header file which provides the necessary C API for making the protocol requests and receiving the protocol events related to pointer locking and relative pointer events. Note that at the time, the protocol is unstable and may change in the future. Any future breaking changes will, however, fail gracefully and result in no regressions compared to before this patch. So far it is only enabled when building non-shared version of the Wayland video driver. The reason for the non-shared restriction is because wayland-scanner generates C code that relies on being able to link with libwayland-client. I have sent a patch[0] upstream that adds a new mode to wayland-scanner that enables the SDL way of loading symbols. I also have the relevant code that makes use of that code in SDL, but will wait with posting that until either there is interest or upstream has merged a compatible way.