[dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead
hiho
with that patch:
commit c17e06d5c0e456d3052a1b6de688956f87c59d3e Author: Vitaliy Margolen wine-patches@kievinfo.com Date: Sun Dec 10 14:15:08 2006 -0700
dinput: No need to copy default constant format. Use already defined static instead.
:100644 100644 c5a35a1... 369c26d... M dlls/dinput/joystick_linuxinput.c
The game Richard Burns Rally does no longer get any events. The game worked after some patches some month ago from me. As i had no intention on that pages to make things right but to make the game work i might have not picked the optimal solution. But this patches fixed all the apps, that worked with their own DataFormat.
So the problem is like that:
The old code copied the default constant format and applied caclulate_ids on it. So the dwTypes where set with proper MAKEINSTANCE(...) calls. So an app, that requested later its own data format with SetDataFormat using the data from EnumObjects. After the change now the default const has ANY_INSTANCE all over the place but the app request a certain instance - so on SetDataFormat there are no matches.
So the big question is: is our SetDataFormat wrong or is this patch wrong? Please advice.
Christoph Frick wrote:
The old code copied the default constant format and applied caclulate_ids on it. So the dwTypes where set with proper MAKEINSTANCE(...) calls. So an app, that requested later its own data format with SetDataFormat using the data from EnumObjects. After the change now the default const has ANY_INSTANCE all over the place but the app request a certain instance - so on SetDataFormat there are no matches.
So the big question is: is our SetDataFormat wrong or is this patch wrong? Please advice.
I know about this problem. The test I added actually has that sort of custom data format. The thing is, I'm not sure yet how to fix this properly. I don't want to just copy default data format, modify it and use it as internal format. This is only one place that needs to be fixed. But there are several other areas that need this data format with some additional requirements.
The biggest problem is we don't properly "initialize" device. We should create our own data format structure that has only found objects. So we don't need to do it over and over again in EnumObjects or GetObjectInfo.
Also, because we create user format during device creation, we can not check if user actually set data format.
Vitaliy Margolen.
On Wed, Dec 20, 2006 at 10:27:52AM -0700, Vitaliy Margolen wrote:
The biggest problem is we don't properly "initialize" device. We should create our own data format structure that has only found objects. So we don't need to do it over and over again in EnumObjects or GetObjectInfo.
In the joystick_linuxinput i have added such "search what we have" already some month ago so support more than one device. so if i catch your drift here we would again set up on a per-device-base a DataFormat - which then could also be used for EnumObjects and GetObjectInfo, right?
i can help on that end at least on the input edge of code - under your supervision.
Christoph Frick wrote:
On Wed, Dec 20, 2006 at 10:27:52AM -0700, Vitaliy Margolen wrote:
The biggest problem is we don't properly "initialize" device. We should create our own data format structure that has only found objects. So we don't need to do it over and over again in EnumObjects or GetObjectInfo.
In the joystick_linuxinput i have added such "search what we have" already some month ago so support more than one device. so if i catch your drift here we would again set up on a per-device-base a DataFormat
- which then could also be used for EnumObjects and GetObjectInfo,
right?
Exactly. Then we use it instead if default data format to assign to wine_df.
i can help on that end at least on the input edge of code - under your supervision.
Sweet.
Vitaliy.
-
Christoph Frick -
Vitaliy Margolen