Thanks for the explanation. The concerns you raise are valid.

To provide a bit of context. We have a Linux-like system without X11, so we've written our own driver to replace winex11.drv. It's written in C++ for various reasons to simplify integrating with the underlying platform. Considering this is part of an internal/proprietary system it will not be upstreamed. So we're not concerned about that. But we would like to keep our local modifications to Wine at a minimum.

The existing input processing system in Wine is heavily built around X11 behaviour. So none of the helper methods winex11.drv uses help our case, and we've resorted to directly sending a message to the Wine Server. While that solution is working well, the only change we need to make to Wine is the patch I have submitted.

Hope this helps clear up why we need it. As to why try to upstream it (aside from our motivation to minimize local changes). Any other project trying to interact with the Wine Server though C++ code could benefit from this. I've seen instances where Wine has made efforts to be C++ compatible even though the majority of the code is C (e.g. a bug I reported some time ago). So it seems like a good decision to try and merge this.

Mahdi

On Mon, Jun 6, 2022 at 1:14 PM Alex Henrie <alexhenrie24@gmail.com> wrote:

On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani <tayarani@google.com> wrote:
>
> We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need.

Does that mean that you're porting Wine to a new platform and writing
something like winex11.drv for that platform? Could your new code be
included in upstream Wine one day? If so, it would probably be better
to write it in C instead of C++ because the Wine project does not
currently accept C++ code.

Or do you mean that you are writing cross-platform software that will
run on both Windows and on Wine? If that is the case, how does the
code work on Windows? Could the same functions that you call on
Windows be improved in Wine to do what you need?

> Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit.

Although the change itself is very small, it smells like a hack, and
the Wine community really does not like hacks. I think everyone would
prefer to identify the underlying problem here and, if possible,
resolve it instead of working around it. That said, I am just a
volunteer Wine developer trying to be helpful; other developers would
be able to speak more authoritatively.

-Alex