Just to see if this works, could you see if using a native user32.dll file fixes it?
Just to see if this works, could you see if using a native
user32.dllfile fixes it?
I'm not totally sure what you are asking. user32.dll is a core Windows native library.
I am making direct calls to user32.dll via C#. If you mean calling user32.dll in C/C++ directly, that should be what this is doing via a wrapper / inject more or less (which does not work in Proton, but works fine on Windows).
Something similar to this:
https://dev.to/socar/quick-guide-to-mouse-clicking-in-c-oke
Other core features are supported in this manner such as shell32.dll. Though I am not totally sure to what degree this is handled by Wine vs Proton. Though there are some weird inconsistencies if you want to chase those down: https://github.com/ValveSoftware/Proton/issues/8392
I added more info to the description to clarify.
Just to see if this works, could you see if using a native user32.dll file
fixes it?I'm not totally sure what you are asking.
user32.dllis a core Windows
native library.
What they mean is, are you using user32.dll from wine, or from Windows?
In wine terminology, that is builtin vs native.
We can assume you're using wine's builtin user32.dll (written by wine devs for
use in wine) since the Windows-native one supposedly does not work.
https://gitlab.winehq.org/wine/wine/-/wikis/Wine-User's-Guide#libraries-settings
Other core features are supported in this manner such as shell32.dll.
Yes, because wine devs have implemented enough (but not all of it) to run some
subset of Windows programs.
Though I am not totally sure to what degree this is handled by Wine vs Proton.
To put it simply, Proton is built on top of wine.
The core feature of "running Windows programs" is wine.
Though there are some weird inconsistencies if you want to chase those down:
https://github.com/ValveSoftware/Proton/issues/8392
There is no inconsistency between Proton and wine in that issue.
Does what you're doing work in wine?
GetCursorPos/SetCursorPos seems to be implemented or at least not stubs:
https://source.winehq.org/WineAPI/user32.html
What they mean is, are you using user32.dll from wine, or from Windows?
In wine terminology, that is builtin vs native.
We can assume you're using wine's builtin user32.dll (written by wine devs for
use in wine) since the Windows-native one supposedly does not work.
https://gitlab.winehq.org/wine/wine/-/wikis/Wine-User's-Guide#libraries-settings
It sounds like from what you are saying by default I would be using the built-in Wine dlls (because I am using Proton on SteamDeck, through Steam to run a windows native game with a cursor script that uses [DllImport("user32.dll")]). Without actually seeing these dlls, they must be wrappers that call the native linux equivalents (which is essentially how I perceive proton). I think we are almost on the same page now.
I did again verify just now on the Stable branch for the Steam Deck in desktop mode, I ran a fresh Windows build and put it on the Steam Deck and ran it with Proton 9.0-4 and the mouse does not move when I move the input that is wired to GetCursorPos/SetCursorPos (there are other problems with mouse visibility that require the beta branch, but you can touch the screen to turn the mouse on to see if it is moving). When this action is performed on a Windows Machine, the cursor moves. I know that this input works on the Steam Deck because it is used for other features that do respond to the input.
Yes, because wine devs have implemented enough (but not all of it) to run some
subset of Windows programs.
I understand. The thought I was trying to convey was that the manner in which I am calling dlls (Built in wine wrapper dlls as I now understand) is able to properly activate another know working dll, so this one is probably being called correctly as well, but seems to not activate the API or does not route to the native functions in some way when called.
To put it simply, Proton is built on top of wine.
The core feature of "running Windows programs" is wine.
I understand. I am using Proton through Steam. I do not have any control over proton or its features (as far as I know) besides changing the version of Proton for compatibility on the Steam Deck.
Does what you're doing work in wine?
GetCursorPos/SetCursorPos seems to be implemented or at least not stubs:
https://source.winehq.org/WineAPI/user32.html
I really just don't understand this question. How would I be using wine or the native dll directly? Is there some option in the Steam client on the Steam Deck to do this?
[DllImport("user32.dll", CharSet = CharSet.Auto, CallingConvention = CallingConvention.StdCall)] Is there some way to change this in C# and or tell proton to use the native linux dll instead of the wine built-in dll? I guess you are asking me to do something to troubleshoot, but I don't think this is an option. I think all I can use is whatever DllImport decides to import when running a game in proton compatibility through Steam.
There is no inconsistency between Proton and wine in that issue.
Any misunderstanding here is likely due to my inability to type words on the keyboard to effectively communicate. As you explained it to me previously in that thread. That last sentence was referencing a separate issue. It was not referring to wine vs proton. When I mentioned inconsistency (maybe that is the wrong word) I was referring to
Wine behavior seems compliant with the spec; the confusing point for users is why one works but one doesn't, even though both are correct.
In reference to the fact that when this action is performed on Windows It works for both, and on Proton it does not work for both. I was sorta hoping someone with a better understanding of the problem (inconsistency) in that thread could go chase that down and open a ticket with WineHQ rather than asking the Steam Partners / Customers who are reporting problems to go do that.
All other info aside here, I am trying to report a bug to Steam/Valve. Maybe I need to write a ticket and get someone from quality control on this that can better communicate with you. I already have 3 tickets with Steam related to the Steam Deck (1 of which has been fixed). It is sorta difficult to report more than 1 in the ticket system. But there are unfortunately lots of bugs with the Steam Deck. I thought that this was the correct place to save the ticket guys some time and come to get help, but maybe I am just causing confusion.
I am not sure if you work for Valve/Steam (maybe one of you is a random person? idk). 3rd Party contractors? No clue.
When I hear stuff along the lines of you should report this stuff to someone else I am not happy. Steam is providing a product in the form of Proton which I am the user of, if that product has a problem it should not be my responsibility to chase down a problem with 3rd party tools / software it uses and it shouldn't just be ignored. I would really appreciate at the very least some effort for that other issue to be reported to WineHQ by Valve as the resolution to the github issue. The trash thing is sort a low priority issue so its not a big deal, but I felt ignored when reporting a legitimate issue and I definitely feel this issue is not being taken seriously. The first thing I would have done is to go find a Steam Deck in the office or whatever and write a simple script or something to see if those features work correctly to verify what I am saying as opposed to dismissing it as supposedly. I would not have reported this unless I was having an issue. There are an absurd amount of problems with the Steam Deck (you can't even turn on a brand new one without it freezing). Serious quality control problems.
Has anyone at Steam/Valve or in there employ by contract or otherwise verified the problem I am reporting here? If the answer to that is no. I am not sure why I am being asked a bunch of questions about Wine (software that I do not use directly).
Look at all these peoples bugs being ignored. I can only assume they are ignored because issues I have had fixed via the ticket system went unnoticed for 8 months and I had to have conversions with unknown persons like this for hours on end to get them to believe there was a problem.
https://steamcommunity.com/app/1675200/discussions/1/
I appreciate all the work you guys are doing, and I know you are probably dealing with a lot of reports. I am just very frustrated with the number of issues with the Steam Deck and my inability to communicate with Steam to get them fixed.
@Revmatek Please don't post such long and irrelevant comments to issue trackers.
You abuse the goodwill of everyone who reads it.
You are very confused about Proton as a Free and Open Source Software (FOSS)
project. This is not customer service. Nobody is here to serve you.
The BSD 3-Clause License, like many other free software licenses,
disclaims any warranty.
In fact the only reason I can waste my time on you is because I'm not paid to
do this; I sometimes triage issues as a way of giving back to FOSS projects that
have benefited me. I chose your 2 issues because I know a bit about wine,
but so far you have resisted all attempts at giving you information.
The specific section of the wine user guide previously linked explains the
difference between wine builtin and native (Windows-native, not Linux-native
as you've misunderstood) DLLs, and how to tell wine to load either.
There are countless other resources on using wine like the Arch wiki
(SteamOS is based on Arch Linux, and the Arch wiki is generally useful
even for other distros).
If you want someone to reproduce your bug, provide a minimum reproducible
example (e.g. the source code for a simple program that uses SetCursorPos).
Since you have already written some code, you should share it instead of asking
others to duplicate your work. This is not an invitation to ask more C# / WinAPI
programming questions.
If it turns out to be a wine bug (again) and you choose not to report it to wine
(as is your right), that's fine. Nobody will report it for you.
Good luck with the next person. They won't start with as much patience as me,
since they'll have to make it through your last reply first.
@jn64 Thanks for the info and clarification on your role. Many developers are trying to get problems fixed with the Steam Deck are being directed here by Valve employees or due to a lack of help from Steam Support.
This repo is under ValveSoftware and I believe many developers may come here under the impression they will receive help from Valve Developers. Since that does not seem to be the case there is not much I can do.
I sent a link to example code and provided enough information to prompt further discussion. I was under the false impression you worked for Valve due to your private profile and recognized your immediate insight to the other issue. The steps to reproduce here require a Steam Deck and calling the API inside of Proton. No one who has replied here has attempted to do so. I cannot walk you through the steps of programing. I do not have have a FOSS example to provide and suspect that calling the API will reveal the problem (because the API is not working and hopefully that would lead to some insight)
I do disagree on that if it is a Wine problem it should and will be reported by a Valve employee (this may be a low priority). They may also choose not to do that.
But the reason they might want to do that is this is a product as well as something they bundle with the Steam Deck. If someone reports a problem with it, it is still a bug against Proton/Steam Deck, not Wine. The bug against Proton is resolved by a bug against Wine. I do not use Wine and I am not reporting a issue with Wine because there is no bug with Wine on my end and I cannot provide that information to create a report to Wine because it is not my software calling Wine directly it is Proton. If someone reports a bug to me I will relay that information in a waterfall manner and report the resolution/status back to the customer if/when relevant.
If anyone from Valve ends up here, I am happy to further discuss this issue as it relates to Proton on the Steam Deck.
After many hours I was able to tweak some code to get this to work somewhat on my end on the stable branch, but that branch still suffers from mouse visibility issues. I tried some stuff with WINEDLLOVERRIDES based on what I was hearing here specifically for the Steam Deck as recommend by some stuff I found googling and looking at other issues on this repo related to dlls. That stuff required some launch options and did not seem to change the behavior. It seems like none of this is related to wine.
It also, to my delight seems like I was able to get this to work completely by updating the beta branch once again. So cool, thanks mystery stranger. Big thanks to whoever is actually fixing the bugs.
WINEDLLOVERRIDESx1 2025-03user32.dllx5 2025-03shell32.dllx2 2025-03
I am unsure if this is supposed to be supported (seems like it should be).
In some cases it may be required to move the mouse or simulate a click. Importing
user32.dllallows you to simulate mouse clicks and movement programmatically on Windows via SetCursorPos, GetCursorPos, mouse_event. It does not seem to work when running in Proton.My use case involves the Steam Deck. The behavior (or lack there of) does not appear to be related to gamescope (it doesn't work in desktop mode either). I am aware of various other ways to do joystick/trackpad mouse input.
Is this a bug? Can this be supported?
API
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-mouse_event
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setcursorpos
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getcursorpos
Useful information for reproducing this:
Steamdeck
C# / Mono
user32.dll
Mouse event flags:
0x02,0x04(ideally they should all work, this is just Left Click Up/Down)Proton Versions
9.0-4
7.0-6