You are not logged in.
Dear all,
Most things work well in my life right now, except for mouse emulation in Wayland with the Steam Controller. It has been like this since Wayland was forced into our lives (in the long run this is a good thing).
I know there are a few others that have this problem, for example here:
https://github.com/ValveSoftware/steam- … ssues/4738
Summary: The mouse pointer is there and it's moving around (can be seen from GUI highlights and click events etc), but the pointer is stuck. When using a normal mouse the pointer starts moving again, interestingly from it's original position (not from where the emulation last put it). This happens on the Gnome Shell, and in most modern games (e.g. Darkest Dungeon), but not in others (e.g. FTL) where the game designers added an extra layer of emulation (virtual pointer and real pointer might end up in different positions).
Something related is described here, but I cannot really see if this is the same thing (a clean-up of that text would be nice):
https://wiki.archlinux.org/index.php/Wa … VM_windows
So far I have not found a fix, and I do not really know where to turn. Can this be claimed to be a Wayland bug, or a combination of different things in the distro?
A clue to what might be wrong is that the Steam Controller does not generate a uinput device, but rather a hidraw device, is that not handled by Wayland in the same way as in X11? Is it possible to pipe between hidraw and uinput?
Last edited by conchyliferous (2017-07-07 14:49:25)
Offline
I looked a little bit more on this now and found one more clue to the problem.
1. When using Wayland and if the Steam client is started: The mouse pointer does not move and there is an invisible pointer (as described above). The pointer works in all parts of Gnome, not only in Steam.
2. When using Wayland and if the Steam client is not started: The mouse pointer does not move and there is no invisible pointer. In other words, no response. However, there is controller related output from 'cat /dev/hidraw4' exactly as in case 1.
3. When using X11: The mouse emulation works even without the Steam client started (I could not test this now, but I'm quite certain this was the case when I last did) Edit: Steam needs to be on
So, I think the problem is both Wayland and Steam related, but I don't know exactly how. Might it be that Steam emulates the mouse movement from hidraw into something that Wayland understands, but somehow only the position of the pointer but not the position of the cursor icon?
Last edited by conchyliferous (2017-07-10 21:24:34)
Offline
I have some more news on this. My current hypothesis is that SDL2 does not play well with Wayland, in particular when it comes to mouse events and setting the global position.
AFAIK, Steam uses SDL2 internally, probably also for parsing their controllers and emulating the mouse.
I tested this hypothesis with the following code:
#include <iostream>
#include <chrono>
#include <thread>
#include <SDL2/SDL.h>
int32_t main(int32_t a_argc, char *a_argv[])
{
SDL_Init(SDL_INIT_VIDEO);
SDL_Window * screen = SDL_CreateWindow("Mouse cursor test",
SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
bool quit = false;
SDL_Event event;
while (!quit) {
SDL_PollEvent(&event);
SDL_WarpMouseGlobal(0, 0); // Should put the cursor in top left corner (0, 0).
switch (event.type) {
case SDL_QUIT:
{
quit = true;
break;
}
}
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
}
SDL_Quit();
return 0;
}It turns out that this in fact works perfectly in X11, but not at all in Wayland. The SDL_WarpMouseGlobal function does nothing for Wayland, and this might very well be how Steam try to do it as well. Another interesting thing that came from this test is that the SDL_PollEvent does not really work in Wayland either since it seems to miss events (the close event in this example), and I have experienced exactly the same from Steam. In Steam's defence they do not officially to support Wayland since SteamOS use X11, but still I think they will need to do it soon. Perhaps it solves itself in the next update of SDL.
However, there is one thing here that does not add up, and that is that Steam actually manage to produce an invisible mouse that triggers hover highlights etc and reacts properly to clicks (but without moving the actual cursor). My above test did not reproduce this, so perhaps there is something else or something additional going on here.
Offline
I had some time to dig deeper into this. In the SDL 2.0.5 source (src/video/wayland/SDL_waylandmouse.c) it says:
static void
Wayland_WarpMouse(SDL_Window *window, int x, int y)
{
SDL_Unsupported();
}
static int
Wayland_WarpMouseGlobal(int x, int y)
{
return SDL_Unsupported();
}Then again, Steam does in fact make an invisible cursor move, so probably they tried to do something of their own here. However, if the SDL devs could find a fix on their end I think everyone would be happy.
Offline
Thanks for digging into this. I am experiencing the same behaviour.
Offline
I made some more tests on this problem that I would like to share. After thinking more about
Then again, Steam does in fact make an invisible cursor move, so probably they tried to do something of their own here.
I must conclude that this problem cannot really be related to SDL, and that Steam is probably trying to move the cursor on a lower level (since it responds, even though insufficiently).
Therefore I conducted a test with five different Arch Linux empowered computers at home, all newly updated and with Wayland active. Now it got interesting, one of the five computers did show the appropriate mouse behaviour!
The main difference is probably that that particular computer uses an Nvidia GPU, while three of the others run with standard Intel built-in GPUs, and one with an AMD card. I tried to run the Nvidia computer both with the proprietary driver and with the Nouveau driver and it worked in both cases. The four other computers showed the incorrect behaviour with the invisible mouse pointer moving around which is shown by GUI highlighting etc (with the actual pointer stuck on the screen). Could it be a problem related to Mesa?
I also had the opportunity to test another thing, since one of the five computers has a hybrid Intel/Nvidia card. I started Steam with 'primusrun steam' and checked in 'System information' in Steam that the Nvidia card was running, but the mouse behaviour did not improve compared to when the Intel GPU was active. From this, I guess that Wayland itself needs to be connected to the right GPU and driver on the low level, and I don't really understand how this works when running in hybrid mode.
To summarize, does the Nvidia driver include mouse pointer movement and rendering? Might we even guess that there are a dedicated API that is called from Steam, that is implemented even in Nouveau. From the symptoms, perhaps the rendering of the pointer is the key factor here.
@djmwj1: What GPU are you running on?
This bug is still a mystery, and it's been around for quite some time now. The problem is also that it's hard to know to whom the bug report should be filed (Steam, SDL, Wayland, Mesa,...). It would be very nice if people out there using Steam Controllers and Wayland could run tests report back. Linux has sadly always been a bit behind on the gaming scene, but I think Valve has shown great steps to even that out. If we in the Linux community could look ahead and help with details like this I think we might soon have the perfect gaming platform. In the end, these types of bugs are often fixed with a few lines of code in the right spot.
Offline