wine-devel March 2014

wine-devel@winehq.org

78 participants
252 discussions

[RFC 10/11] Linux FF: Linux joystick initialization
by Elias Vanderstuyft 04 Mar '14

04 Mar '14

a) In dinput/joystick_linuxinput.c:546 : Why not change (to fill in additional device capabilities) : if (newDevice->joydev->has_ff) newDevice->generic.devcaps.dwFlags |= DIDC_FORCEFEEDBACK; to : if (newDevice->joydev->has_ff) { newDevice->generic.devcaps.dwFlags |= DIDC_FORCEFEEDBACK; newDevice->generic.devcaps.dwFlags |= DIDC_STARTDELAY; if ( test_bit(newDevice->joydev->ffbits, FF_CONSTANT) || test_bit(newDevice->joydev->ffbits, FF_PERIODIC) || test_bit(newDevice->joydev->ffbits, FF_RAMP) ) newDevice->generic.devcaps.dwFlags |= DIDC_FFATTACK | DIDC_FFFADE; if ( test_bit(newDevice->joydev->ffbits, FF_SPRING) || test_bit(newDevice->joydev->ffbits, FF_DAMPER) || test_bit(newDevice->joydev->ffbits, FF_INERTIA) || test_bit(newDevice->joydev->ffbits, FF_FRICTION) ) newDevice->generic.devcaps.dwFlags |= DIDC_POSNEGCOEFFICIENTS | DIDC_POSNEGSATURATION | DIDC_SATURATION; } Elias

1 0

[RFC 9/11] Linux FF: Linux effect parameters (global)
by Elias Vanderstuyft 04 Mar '14

04 Mar '14

a) All DInput effect parameters to need to be translated to linux effect parameters, are either DWORD, or LONG. That means that their maximum absolute values are both equal to 2147483648 (both are 4-byte signed two-complement). All these parameters are limited to a maximum absolute value of DI_FFNOMINALMAX (=10000), except for the time parameters such as period, duration, startdelay, ... and for the elements of "rglDirection" (LONG array). All linux effect parameters do never exceed a size of 16 bits: __s16 and __u16. That means that their maximum absolute values are respectively 32768 and 65535. This means that: - If the parameters with DI_FFNOMINALMAX limits exceed this limit, we should *consistently* either: - Emit "DIERR_INVALIDPARAM" - Clamp to the correct range => The latter is preferred, and already applied in the ConstantForce case, but overall not consistently: e.g. it is not done in the Periodic case, ... So, change (e.g. for ramp levels) on dinput/effect_linuxinput.c:500 : This->effect.u.ramp.start_level = (tsp->lStart / 10) * 32; This->effect.u.ramp.end_level = (tsp->lEnd / 10) * 32; to : This->effect.u.ramp.start_level = (max(min(tsp->lStart, 10000), -10000) / 10) * 32; This->effect.u.ramp.end_level = (max(min(tsp->lEnd, 10000), -10000) / 10) * 32; And the same applies to many other lines of code, but I don't write them yet if I don't know whether this proposal will be accepted. - If the parameters are time-related, plain conversion from dinput to linux could cause parameters to wrap around (even when first dividing by 1000 (to go from millis->micros)), because all time values in linux are maximum 0x7FFF (/include/uapi/linux/input.h:966). We can not emit "DIERR_INVALIDPARAM" when these parameters exceed linux' parameters' range, because it is not forbidden by MSDN. => So we should clamp them before conversion. So, change dinput/effect_linuxinput.c:424 : if (dwFlags & DIEP_DURATION) { if (peff->dwDuration == -1) This->effect.replay.length = 0; // Infinity else if (peff->dwDuration > 1000) This->effect.replay.length = peff->dwDuration / 1000; else This->effect.replay.length = 1; // Smallest non-zero value } to : if (dwFlags & DIEP_DURATION) { if (peff->dwDuration == -1) This->effect.replay.length = 0; // Infinity else if (peff->dwDuration > 1000) This->effect.replay.length = min(peff->dwDuration / 1000, 0x7FFF); else This->effect.replay.length = 1; // Smallest non-zero value } And the same applies to many other lines of code, but I don't write them yet if I don't know whether this proposal will be accepted. - If the parameters are direction-related, we should also be careful for parameters to not wrap around, but I did not find such a problem in effect_linuxinput.c b) Provide a more accurate mapping of force levels from dinput to linux, (the "from linux to dinput" case is less important): Ensure 10000 (dinput) maps exactly to 32767 (linux), this will prevent glitches when envelopes are applied on top of an already maxed out forces. => Variations from 32000 to 32767 can occur in the attack or fade region. These may be small, but when the frequency of effects started is high, this may be significantly perceivable. Change for all force conversions from dinput to linux (e.g. for constant.level) on dinput/effect_linuxinput.c:494 : This->effect.u.constant.level = (max(min(tsp->lMagnitude, 10000), -10000) / 10) * 32; to : This->effect.u.constant.level = (max(min(tsp->lMagnitude, 10000), -10000) * 0x7FFF) / 10000; And the same applies to many other lines of code, but I don't write them yet if I don't know whether this proposal will be accepted. c) Optimize code to eliminate (almost) all floating point operations when translating effect parameters from dinput to linux. (the "from linux to dinput" case is less important) If not possible, eliminate it for the common cases. We will use the uint16_t type, so we need to include stdint.h, change on dinput/effect_linuxinput.c:26 : #include <stdarg.h> #include <string.h> to : #include <stdarg.h> #include <stdint.h> #include <string.h> Change on dinput/effect_linuxinput.c:415 : This->effect.direction = (unsigned int)((M_PI / 2 + atan2(peff->rglDirection[1], peff->rglDirection[0])) * 0x8000 / M_PI); to : if (!peff->rglDirection[1]) This->effect.direction = (peff->rglDirection[0] >= 0 ? 0x4000 : 0xC000); else if (!peff->rglDirection[0]) This->effect.direction = (peff->rglDirection[1] >= 0 ? 0x8000 : 0); else This->effect.direction = (uint16_t)((M_PI / 2 + atan2(peff->rglDirection[1], peff->rglDirection[0])) * 0x8000 / M_PI); And change on dinput/effect_linuxinput.c:416 : } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); } to : } else if (peff->dwFlags & DIEFF_SPHERICAL) { /* Avoid floating point arithmetic in most cases, while realizing same precision * (when abs(peff->rglDirection[0]) < 0x00080000 = 524288 which is much larger than 35999), * otherwise, use floating point arithmetic */ if (-0x00080000 < peff->rglDirection[0] && peff->rglDirection[0] < 0x00080000) This->effect.direction = 0x4000 + (uint16_t)((peff->rglDirection[0] * 0x1000) / 2250); else This->effect.direction = 0x4000 + (uint16_t)(((double)peff->rglDirection[0] / 2250) * 0x1000); } else /* if (peff->dwFlags & DIEFF_POLAR) */ { /* Avoid floating point arithmetic in most cases, while realizing same precision * (when abs(peff->rglDirection[0]) < 0x00080000 = 524288 which is much larger than 35999), * otherwise, use floating point arithmetic */ if (-0x00080000 < peff->rglDirection[0] && peff->rglDirection[0] < 0x00080000) This->effect.direction = (uint16_t)((peff->rglDirection[0] * 0x1000) / 2250); else This->effect.direction = (uint16_t)(((double)peff->rglDirection[0] / 2250) * 0x1000); } d) If previously a successful SetParameters(...) has been called, and then SetParameters(...) is called again, but now with only DIEP_AXES flag set in the 'dwFlags' parameter (and not DIEP_DIRECTION, because it was already done before): => Problem, "effect.direction" is not updated (and instead it should, because it's dependent of the axes config). I did not provide a patch here, because it would require to store extra data. This needs discussion. e) If previously a successful SetParameters(...) has been called with the DIEP_TYPESPECIFICPARAMS flag set, and then SetParameters(...) is called again, but now with only DIEP_AXES and/or DIEP_DIRECTION flag set: => Problem if type == DIEFT_CONDITION: "effect.u.condition[i].*" are not updated (and instead they should, because they are dependent of the axes config and the direction). I did not provide a patch here, because it would require to store extra data. This needs discussion. f) We might use 'DIEFFECT.dwGain'/10000 to multiply with all forces of the corresponding effect. In that way, we don't have to set global gain on Linux each time another DIEFFECT.dwGain value occurs. Also this can suffer from the same problem as above: if only the 'dwGain' value is updated in SetParameters(...) after the effect was previously already fully defined, the force values would also need to be updated (because they are dependent of the gain). I did not provide a patch here, because it would require to store extra data. This needs discussion. Elias

1 0

[RFC 8/11] Linux FF: Linux effect direction
by Elias Vanderstuyft 04 Mar '14

04 Mar '14

a) Some common mistakes about linux directions: - using 0x7FFF as ~359 degrees for linux direction, instead of 0xFFFF (look at /include/uapi/linux/input.h:1117) - the everlasting confusion about how to map dinput to linux directions, this proves to be a difficult topic, only by finding out that the SDL2 haptic implementation does a different conversion than Wine does, and since only one possibility is the right one, at least one of the implementations is wrong. It turns out they're both wrong. With this explanation, I try to finally come up with the right implementation, by deriving it in a systematical way. This explanation has been verified by the linux input mailing lists: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08459.html Directions ========== For conversions between different APIs, the physical behaviour should be the same. DInput ______ Extracted from http://msdn.microsoft.com/en-us/library/windows/desktop/ee417536%28v=vs.85%… : Physical situation: North (polar 0, spher[0] 270) (0, -1) -y Far West East (polar 90, spher[0] 0) (-1, 0) O (+1, 0) -x Left +x Right South (0, +1) +y Near .------. | User | '------' Remember these are the 'directions': as defined as the direction the user should exert force in to counteract the force. So the direction in which the force is applied by the joystick, is opposite. If we're interested in the direction in which the force is applied by the joystick, the physical situation becomes point-flipped: (polar 0, spher[0] 270) (0, +1) +y (polar 270, spher[0] 180) (polar 90, spher[0] 0) (+1, 0) O (-1, 0) +x -x (polar 180, spher[0] 90) (0, -1) -y Linux _____ Extracted from Linux /include/uapi/linux/input.h:1113, and from the discussion with Anssi Hannula in the mailing lists : Physical situation: Up (dir 180) (0, -1) -y Left (dir 90) Right (dir 270) (-1, 0) O (+1, 0) -x +x Down (dir 0) (0, +1) +y .------. | User | '------' It is unclear what is meant by 'directions' in this case: Possibility #1: counteraction direction of user Possibility #2: direction of force applied by joystick Anssi Hannula confirmed that Possibility #2 is the right one. Mapping _______ In the "Carts" column, you can find the Cartesian coordinates which indicate the counteraction direction of user. (This choice is arbitrary ('direction of force applied by joystick' could also have been chosen), just to have a physical reference.) These "Carts" tuples should be equal across APIs to ensure equal behavior. #Assume Possibility #1: # # DInput <-> Linux # _________________ | ___________ # Carts|Polar|Spher | Carts|Direc # -----+-----+----- | -----+----- # 0, -1| 0 | 270 | 0, -1| 180 # +1, 0| 90 | 0 | +1, 0| 270 # 0, +1| 180 | 90 | 0, +1| 0 # -1, 0| 270 | 180 | -1, 0| 90 Assume Possibility #2: => Linux Cartesian coordinates are opposite in respect to the "Carts" reference. DInput <-> Linux _________________ | ___________ Carts|Polar|Spher | Carts|Direc -----+-----+----- | -----+----- 0, -1| 0 | 270 | 0, -1| 0 +1, 0| 90 | 0 | +1, 0| 90 0, +1| 180 | 90 | 0, +1| 180 -1, 0| 270 | 180 | -1, 0| 270 This conversion table will be used in this document. On effect_linuxinput.c:385, there is written: /* some of this may look funky, but it's 'cause the linux driver and directx have * different opinions about which way direction "0" is. directx has 0 along the x * axis (left), linux has it along the y axis (down). */ The part "directx has 0 along the x axis (left)" contradicts with "angle bases: 0 -> -y (down) (linux) -> 0 -> +x (right) (windows)" on line 148, because 'left' != 'right'. Also, this comment seems to be about the dinput spherical coordinates, instead of polar. Applying the conversion table on dinput/effect_linuxinput.c:385, change : /* some of this may look funky, but it's 'cause the linux driver and directx have * different opinions about which way direction "0" is. directx has 0 along the x * axis (left), linux has it along the y axis (down). */ if (dwFlags & DIEP_DIRECTION) { if (peff->cAxes == 1) { if (peff->dwFlags & DIEFF_CARTESIAN) { if (dwFlags & DIEP_AXES) { if (peff->rgdwAxes[0] == DIJOFS_X && peff->rglDirection[0] >= 0) This->effect.direction = 0x4000; else if (peff->rgdwAxes[0] == DIJOFS_X && peff->rglDirection[0] < 0) This->effect.direction = 0xC000; else if (peff->rgdwAxes[0] == DIJOFS_Y && peff->rglDirection[0] >= 0) This->effect.direction = 0; else if (peff->rgdwAxes[0] == DIJOFS_Y && peff->rglDirection[0] < 0) This->effect.direction = 0x8000; to : /* some of this may look funky, but it's 'cause the linux driver and directx have * different opinions about which way direction "0" is. directx has 0 along the y * axis (north/far, counteract), linux has it along the y axis (down). */ if (dwFlags & DIEP_DIRECTION) { if (peff->cAxes == 1) { if (peff->dwFlags & DIEFF_CARTESIAN) { if (peff->rgdwAxes[0] == DIJOFS_X && peff->rglDirection[0] >= 0) This->effect.direction = 0x4000; else if (peff->rgdwAxes[0] == DIJOFS_X && peff->rglDirection[0] < 0) This->effect.direction = 0xC000; else if (peff->rgdwAxes[0] == DIJOFS_Y && peff->rglDirection[0] >= 0) This->effect.direction = 0x8000; else if (peff->rgdwAxes[0] == DIJOFS_Y && peff->rglDirection[0] < 0) This->effect.direction = 0; Change dinput/effect_linuxinput.c:148 : /* Major conversion factors are: * times: millisecond (linux) -> microsecond (windows) (x * 1000) * forces: scale 0x7FFF (linux) -> scale 10000 (windows) approx ((x / 33) * 10) * angles: scale 0x7FFF (linux) -> scale 35999 (windows) approx ((x / 33) * 36) * angle bases: 0 -> -y (down) (linux) -> 0 -> +x (right) (windows) */ to : /* Major conversion factors are: * times: millisecond (linux) -> microsecond (windows) (x * 1000) * forces: scale 0x7FFF (linux) -> scale 10000 (windows) approx ((x / 33) * 10) * angles: scale 0xFFFF (linux) -> scale 35999 (windows) approx ((x / 66) * 36) * angle bases: 0 -> +y (down) (linux) -> 0 -> -y (far: counteract direction) (windows polar) */ and change dinput/effect_linuxinput.c:184 : peff->rglDirection[0] = (This->effect.direction / 33) * 36 + 9000; if (peff->rglDirection[0] > 35999) peff->rglDirection[0] -= 35999; to : peff->rglDirection[0] = (This->effect.direction / 66) * 36; and change dinput/effect_linuxinput.c:415 : This->effect.direction = (int)((3 * M_PI / 2 - atan2(y, x)) * -0x7FFF / M_PI); to : This->effect.direction = (unsigned int)((M_PI / 2 + atan2(y, x)) * 0x8000 / M_PI); and change dinput/effect_linuxinput.c:505 : /* One condition block. This needs to be rotated to direction, * and expanded to separate x and y conditions. */ int i; double factor[2]; factor[0] = asin((This->effect.direction * 3.0 * M_PI) / 0x7FFF); factor[1] = acos((This->effect.direction * 3.0 * M_PI) / 0x7FFF); to : /* One condition block. This needs to be rotated to direction, * using dinput Cartesian coordinates, and expanded to separate x and y conditions. */ int i; double factor[2]; factor[0] = +sin((This->effect.direction * M_PI) / 0x8000); factor[1] = -cos((This->effect.direction * M_PI) / 0x8000); b) Applying direction seems to have no influence on X and Y force. (It's always polar 0 degrees) Tested in FEdit => Multiple things in the implementation are wrong: - typo in the bracket placement for the double-to-int conversion - forgetting (typo) that dinput works with 9000 instead of 90 (inconsistent with linux->dinput conversion of GetParameters) - common mistakes about linux directions, see above - it is more readable and accurate to use "* (0x8000 / 18000)" than "* (0xFFFF / 35999)", and wrapping of this (effect.direction) u16 is intentional. Solution: Change dinput/effect_linuxinput.c:419 : This->effect.direction = (int)(((double)peff->rglDirection[0] - 90) / 35999) * 0x7FFF; to : This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); c) Multiple things are weird/wrong here: - common mistakes about linux directions, see above - "M_PI * 3", why '3' ??? - Why "1000" as max magnitude of direction? type(rglDirection[i]) == 'LONG' => You can pick at least 10000 (DI_FFNOMINALMAX). So, change dinput/effect_linuxinput.c:174 : if (peff->dwFlags & DIEFF_CARTESIAN) { peff->rglDirection[0] = sin(M_PI * 3 * This->effect.direction / 0x7FFF) * 1000; peff->rglDirection[1] = cos(M_PI * 3 * This->effect.direction / 0x7FFF) * 1000; to : if (peff->dwFlags & DIEFF_CARTESIAN) { peff->rglDirection[0] = +sin(This->effect.direction * M_PI / 0x8000) * DI_FFNOMINALMAX; peff->rglDirection[1] = -cos(This->effect.direction * M_PI / 0x8000) * DI_FFNOMINALMAX; d) The statement "Polar and spherical are the same for 2 axes" is wrong: http://msdn.microsoft.com/en-us/library/windows/desktop/ee417536%28v=vs.85%… : "Polar coordinates are expressed as a single angle, in hundredths of a degree clockwise from whatever zero-point, or true north, has been established for the effect. Normally this is the negative y-axis; that is, away from the user." => (0, -1) direction is Polar starting direction (angle = 0) http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_s… : "If spherical, the first angle is measured in hundredths of a degree from the (1, 0) direction, rotated in the direction of (0, 1)." => (1, 0) direction is Spherical starting direction (angle = 0) (also take a look at the conversion table) So, change dinput/effect_linuxinput.c:177 : } else { /* Polar and spherical coordinates are the same for two or less * axes. * Note that we also use this case if NO flags are marked. * According to MSDN, we should return the direction in the * format that it was specified in, if no flags are marked. */ peff->rglDirection[0] = (This->effect.direction / 66) * 36; } to : } else if (peff->dwFlags & DIEFF_SPHERICAL) { peff->rglDirection[0] = 27000 + (This->effect.direction / 66) * 36; if (peff->rglDirection[0] >= 36000) peff->rglDirection[0] -= 36000; } else /* if (peff->dwFlags & DIEFF_POLAR) */ { /* Note that we return polar coordinates if NO flags are marked. * According to MSDN, we should return the direction in the * format that it was specified in, if no flags are marked. * TODO: Return the direction in the format that it was specified in, * if no flags are marked. */ peff->rglDirection[0] = (This->effect.direction / 66) * 36; } And change dinput/effect_linuxinput.c:416 : } else { /* Polar and spherical are the same for 2 axes */ /* Precision is important here, so we do double math with exact constants */ This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); } to : } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); } e) If "first_axis_is_x" in effect_linuxinput.c happens to be "false" and "cAxes == 2", doesn't the assignment of "effect.direction" in SetParameters(...) need additional transformations if "(peff->dwFlags & DIEFF_POLAR) != 0"? Because then x and y axis are swapped. With swapped x and y axes, then the following conversions hold: #Assume Possibility #1: # # DInput <-> Linux # _________________ | ___________ # Carts|Polar|Spher | Carts|Direc # -----+-----+----- | -----+----- # -1, 0| 0 | 270 | -1, 0| 90 # 0, +1| 90 | 0 | 0, +1| 0 # +1, 0| 180 | 90 | +1, 0| 270 # 0, -1| 270 | 180 | 0, -1| 180 Assume Possibility #2: => Linux Cartesian coordinates are opposite in respect to the "Carts" reference. DInput <-> Linux _________________ | ___________ Carts|Polar|Spher | Carts|Direc -----+-----+----- | -----+----- -1, 0| 0 | 270 | -1, 0| 270 0, +1| 90 | 0 | 0, +1| 180 +1, 0| 180 | 90 | +1, 0| 90 0, -1| 270 | 180 | 0, -1| 0 (Possibility #2 is the correct one) So change dinput/effect_linuxinput.c:416 : } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); } to : } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); if (!This->first_axis_is_x) This->effect.direction = 0xC000 - This->effect.direction; } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); if (!This->first_axis_is_x) This->effect.direction = 0xC000 - This->effect.direction; } Then we can simplify the following code of dinput/effect_linuxinput.c:405 : } else { /* two axes */ if (peff->dwFlags & DIEFF_CARTESIAN) { LONG x, y; if (This->first_axis_is_x) { x = peff->rglDirection[0]; y = peff->rglDirection[1]; } else { x = peff->rglDirection[1]; y = peff->rglDirection[0]; } This->effect.direction = (unsigned int)((M_PI / 2 + atan2(y, x)) * 0x8000 / M_PI); } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); if (!This->first_axis_is_x) This->effect.direction = 0xC000 - This->effect.direction; } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); if (!This->first_axis_is_x) This->effect.direction = 0xC000 - This->effect.direction; } } to : } else { /* two axes */ if (peff->dwFlags & DIEFF_CARTESIAN) { This->effect.direction = (unsigned int)((M_PI / 2 + atan2(peff->rglDirection[1], peff->rglDirection[0])) * 0x8000 / M_PI); } else if (peff->dwFlags & DIEFF_SPHERICAL) { This->effect.direction = (unsigned int)(((9000 + (double)peff->rglDirection[0]) / 18000) * 0x8000); } else /* if (peff->dwFlags & DIEFF_POLAR) */ { This->effect.direction = (unsigned int)(((double)peff->rglDirection[0] / 18000) * 0x8000); } if (!This->first_axis_is_x) This->effect.direction = 0xC000 - This->effect.direction; } f) Condition effects (with struct-size of 2*sizeof(DICONDITION)) should keep "first_axis_is_x" into account: Change dinput/effect_linuxinput.c:520 : /* Two condition blocks. Direct parameter copy. */ int i; for (i = 0; i < 2; ++i) { This->effect.u.condition[i].center = (tsp[i].lOffset / 10) * 32; This->effect.u.condition[i].right_coeff = (tsp[i].lPositiveCoefficient / 10) * 32; This->effect.u.condition[i].left_coeff = (tsp[i].lNegativeCoefficient / 10) * 32; This->effect.u.condition[i].right_saturation = (tsp[i].dwPositiveSaturation / 10) * 65; This->effect.u.condition[i].left_saturation = (tsp[i].dwNegativeSaturation / 10) * 65; This->effect.u.condition[i].deadband = (tsp[i].lDeadBand / 10) * 65; } to : /* Two condition blocks. Direct parameter copy, after a small change of axes if needed. */ int i, j; for (i = 0; i < 2; ++i) { j = (first_axis_is_x ? i : 1-i); This->effect.u.condition[j].center = (tsp[i].lOffset / 10) * 32; This->effect.u.condition[j].right_coeff = (tsp[i].lPositiveCoefficient / 10) * 32; This->effect.u.condition[j].left_coeff = (tsp[i].lNegativeCoefficient / 10) * 32; This->effect.u.condition[j].right_saturation = (tsp[i].dwPositiveSaturation / 10) * 65; This->effect.u.condition[j].left_saturation = (tsp[i].dwNegativeSaturation / 10) * 65; This->effect.u.condition[j].deadband = (tsp[i].lDeadBand / 10) * 65; } The condition effects with struct-size of 1*sizeof(DICONDITION) don't need changes regarding "first_axis_is_x", because "factor[i]" depends on "effect.direction", which already incorporates "first_axis_is_x". g) Condition effects (with struct-size of 1*sizeof(DICONDITION)) are not transformed exactly right, look at "interactive.fig" for more understanding of the suggested code: - "deadband" can't be negative - for "left/right_coeff" and "left/right_saturation", if a direction along an axis is negative, "left" and "right" should be swapped Change dinput/effect_linuxinput.c:511 : for (i = 0; i < 2; ++i) { This->effect.u.condition[i].center = (int)(factor[i] * (tsp->lOffset / 10) * 32); This->effect.u.condition[i].right_coeff = (int)(factor[i] * (tsp->lPositiveCoefficient / 10) * 32); This->effect.u.condition[i].left_coeff = (int)(factor[i] * (tsp->lNegativeCoefficient / 10) * 32); This->effect.u.condition[i].right_saturation = (int)(factor[i] * (tsp->dwPositiveSaturation / 10) * 65); This->effect.u.condition[i].left_saturation = (int)(factor[i] * (tsp->dwNegativeSaturation / 10) * 65); This->effect.u.condition[i].deadband = (int)(factor[i] * (tsp->lDeadBand / 10) * 65); } to : for (i = 0; i < 2; ++i) { This->effect.u.condition[i].center = (int)(factor[i] * (tsp->lOffset / 10) * 32); This->effect.u.condition[i].right_coeff = (int)(abs(factor[i]) * ((factor[i] >= 0 ? tsp->lPositiveCoefficient : tsp->lNegativeCoefficient) / 10) * 32); This->effect.u.condition[i].left_coeff = (int)(abs(factor[i]) * ((factor[i] >= 0 ? tsp->lNegativeCoefficient : tsp->lPositiveCoefficient) / 10) * 32); This->effect.u.condition[i].right_saturation = (int)(abs(factor[i]) * ((factor[i] >= 0 ? tsp->dwPositiveSaturation : tsp->dwNegativeSaturation) / 10) * 65); This->effect.u.condition[i].left_saturation = (int)(abs(factor[i]) * ((factor[i] >= 0 ? tsp->dwNegativeSaturation : tsp->dwPositiveSaturation) / 10) * 65); This->effect.u.condition[i].deadband = (int)(abs(factor[i]) * (tsp->lDeadBand / 10) * 65); } Elias

1 0

[RFC 7/11] Linux FF: Linux effect: axes
by Elias Vanderstuyft 04 Mar '14

04 Mar '14

a) In dinput/effect_linuxinput.c, the GetParameters(...) and SetParameters(...) functions implicitly assume that (DIEFFECT.dwFlags & DIEFF_OBJECTOFFSETS) != 0, but the other flag 'DIEFF_OBJECTIDS' is also possible according to MSDN: The semantics of dwTriggerButton and rgdwAxes are determined by the flags DIEFF_OBJECTIDS and DIEFF_OBJECTOFFSETS. (http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_s…) But I don't know exactly how to convert values determined by DIEFF_OBJECTIDS to values determined by DIEFF_OBJECTOFFSETS. => Suggestions? (the reason why this hasn't yet resulted in problems, is because the usage of 'DIEFF_OBJECTIDS' seems to be rare) Elias

1 0

Re: advapi32/tests: Change the current directory to a place that will be writable.
by Alexandre Julliard 04 Mar '14

04 Mar '14

Francois Gouget <fgouget(a)free.fr> writes: > --- > dlls/advapi32/tests/eventlog.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/advapi32/tests/eventlog.c b/dlls/advapi32/tests/eventlog.c > index f71529c..525d606 100644 > --- a/dlls/advapi32/tests/eventlog.c > +++ b/dlls/advapi32/tests/eventlog.c > @@ -1123,6 +1123,8 @@ static void cleanup_eventlog(void) > > START_TEST(eventlog) > { > + char curdir[MAX_PATH], tmpdir[MAX_PATH]; > + > SetLastError(0xdeadbeef); > CloseEventLog(NULL); > if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > @@ -1131,6 +1133,10 @@ START_TEST(eventlog) > return; > } > > + GetCurrentDirectoryA(MAX_PATH, curdir); > + GetTempPathA(MAX_PATH, tmpdir); > + SetCurrentDirectoryA(tmpdir); > + A better fix would be to build proper temp file names with GetTempPath+GetTempFileName instead of using hardcoded paths in file creation calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Need help getting Win32_PNPEntity WMI class added
by Luke A. Guest 04 Mar '14

04 Mar '14

Hi, I thought I understood this thing, but I don't. I'm trying to get this working so that I can work towards getting Rocksmith going. I've added: diff --git a/dlls/wbemprox/builtin.c b/dlls/wbemprox/builtin.c index 4b02ea2..0051837 100644 --- a/dlls/wbemprox/builtin.c +++ b/dlls/wbemprox/builtin.c @@ -75,6 +75,8 @@ static const WCHAR class_paramsW[] = {'_','_','P','A','R','A','M','E','T','E','R','S',0}; static const WCHAR class_physicalmediaW[] = {'W','i','n','3','2','_','P','h','y','s','i','c','a','l','M','e','d','i','a',0}; +static const WCHAR class_pnpentityW[] = + {'W','i','n','3','2','_','P','N','P','E','n','t','i','t','y',0}; static const WCHAR class_qualifiersW[] = {'_','_','Q','U','A','L','I','F','I','E','R','S',0}; static const WCHAR class_process_getowner_outW[] = @@ -394,6 +396,10 @@ static const struct column col_physicalmedia[] = { { prop_serialnumberW, CIM_STRING } }; +static const struct column col_pnpentity[] = +{ + { prop_deviceidW, CIM_STRING|COL_FLAG_KEY } +}; static const struct column col_process[] = { { prop_captionW, CIM_STRING|COL_FLAG_DYNAMIC }, @@ -513,6 +519,8 @@ static const WCHAR diskdrive_manufacturerW[] = {'(','S','t','a','n','d','a','r','d',' ','d','i','s','k',' ','d','r','i','v','e','s',')',0}; static const WCHAR diskdrive_serialW[] = {'W','I','N','E','H','D','I','S','K',0}; +static const WCHAR pnpentity_rscableW[] = + {'U','S','B','\ \','V','I','D','_','1','2','B','A','&','P','I','D','_','0','0','F','F','&','R','E','V','_','0','1','0','0',0}; static const WCHAR networkadapter_pnpdeviceidW[]= {'P','C','I','\ \','V','E','N','_','8','0','8','6','&','D','E','V','_','1','0','0','E','&', 'S','U','B','S','Y','S','_','0','0','1','E','8','0','8','6','&','R','E','V','_','0','2','\\', @@ -796,6 +804,10 @@ static const struct record_physicalmedia data_physicalmedia[] = { { diskdrive_serialW } }; +static const struct record_physicalmedia data_pnpentity[] = +{ + { pnpentity_rscableW } +}; static const struct record_qualifier data_qualifier[] = { { class_process_getowner_outW, param_userW, CIM_SINT32, FLAVOR_ID, prop_idW, 0 }, @@ -2241,6 +2253,7 @@ static struct table builtin_classes[] = { class_osW, SIZEOF(col_os), col_os, 0, 0, NULL, fill_os }, { class_paramsW, SIZEOF(col_param), col_param, SIZEOF(data_param), 0, (BYTE *)data_param }, { class_physicalmediaW, SIZEOF(col_physicalmedia), col_physicalmedia, SIZEOF(data_physicalmedia), 0, (BYTE *)data_physicalmedia }, + { class_pnpentityW, SIZEOF(col_pnpentity), col_pnpentity, SIZEOF(data_pnpentity), 0, (BYTE *)data_pnpentity }, { class_processW, SIZEOF(col_process), col_process, 0, 0, NULL, fill_process }, { class_processorW, SIZEOF(col_processor), col_processor, 0, 0, NULL, fill_processor }, { class_qualifiersW, SIZEOF(col_qualifier), col_qualifier, SIZEOF(data_qualifier), 0, (BYTE *)data_qualifier }, With the *_pnpentity* elements being mine. I've hardcoded the USB device hardware ID in for now. I also added a TRACE to get_propval, but that's not being called. Here's the relevant part of the log: 0009:trace:wbemprox:wbem_services_CreateInstanceEnum 0x3cd6b58, L"Win32_PNPEntity", 000000000, (nil), 0x32f858 0009:trace:wbemprox:parse_query parse_query: L"SELECT * FROM Win32_PNPEntity" 0009:trace:wbemprox:parse_query wql_parse returned 0 0009:trace:wbemprox:EnumWbemClassObject_create 0x32f858 0009:trace:wbemprox:EnumWbemClassObject_create returning iface 0x3cd6ea8 0009:trace:wbemprox:enum_class_object_Next 0x3cd6ea8, 10000, 20, 0x32f888, 0x32f864 0009:fixme:wbemprox:enum_class_object_Next timeout not supported 0009:trace:wbemprox:enum_class_object_Release destroying 0x3cd6ea8 0009:trace:wbemprox:wbem_locator_Release destroying 0x3cd6cc8 0009:trace:wbemprox:wbem_services_Release destroying 0x3cd6b58 0009:trace:wbemprox:DllGetClassObject {4590f811-1d3a-11d0-891f-00aa004b2e24} {00000001-0000-0000-c000-000000000046} 0x32f80c 0009:trace:wbemprox:wbemprox_cf_CreateInstance (nil) {dc12a687-737f-11cf-884d-00aa004b2e24} 0x32f85c 0009:trace:wbemprox:WbemLocator_create (0x32f78c) 0009:trace:wbemprox:WbemLocator_create returning iface 0x3cd6b78 0009:trace:wbemprox:wbem_locator_QueryInterface 0x3cd6b78 {dc12a687-737f-11cf-884d-00aa004b2e24} 0x32f85c 0009:trace:wbemprox:wbem_locator_ConnectServer 0x3cd6b78, L"\\\\.\\root\ \cimv2", (null), (null), (null), 0x00000000, (null), (nil), 0x32f860) 0009:trace:wbemprox:WbemServices_create (0x32f860) 0009:trace:wbemprox:WbemServices_create returning iface 0x3cd6f10 Have I missed something here? Thanks, Luke.

2 4

Re: mshtml: Don't use fragment navigation for SuperNavigate calls.
by Marvin 04 Mar '14

04 Mar '14

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5364 Your paranoid android. === w8 (32 bit webbrowser) === webbrowser.c:425: Test failed: unexpected nsCmdID 74 webbrowser.c:702: Test failed: V_I4(V_VARIANTREF(flags)) = 100, expected 0x40 or 0 webbrowser.c:442: Test failed: unexpected nCmdID 119 webbrowser.c:454: Test failed: unexpected nCmdID 178 webbrowser.c:454: Test failed: unexpected nCmdID 135 webbrowser.c:425: Test failed: unexpected nsCmdID 74

1 0

Discussion and Improvement of Wine's Linux Force Feedback implementation
by Elias Vanderstuyft 04 Mar '14

04 Mar '14

Hi, In the past few weeks I've been reviewing Wine's Linux Force Feedback implementation. I annotated questions and proposals for improvement and bundled them in a file "Improvements.txt". Now, I think it's time to post my results, before someone begins to work on the dinput files I started from (untouched since wine-1.7.11-206-g82b3813). The reason why I don't send this to wine-patches, is because it is more a review and discussion, than a set of actual diff-generated patch files. Because of the rather massive amount of text I've written, I decided to split them up in separate mails in subjects, each containing 3 questions/proposals on average: Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] I'll send them with the prefix "[RFC x/11] Linux FF: <subject>". Am I allowed to send this? Thanks, Elias

2 1

Drowning in a sea of red
by Jeremy White 04 Mar '14

04 Mar '14

Alright, one month from FOSDEM, and I load test.winehq.org, and I'm still drowning in a sea of red. This is shameful. At the very least, all of the test bot vms should be green. How do we fix this? Should I just pick one failure at a time, and publicly shake it, and shame people as best I can? Cheers, Jeremy

1 0

Re: [PATCH 5/5] winex11: Add support for WGL_WINE_make_current extension. (resend)
by Alexandre Julliard 04 Mar '14

04 Mar '14

Ken Thomases <ken(a)codeweavers.com> writes: > --- > dlls/winex11.drv/opengl.c | 37 +++++++++++++++++++++++++++++++++++++ > 1 files changed, 37 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok X Error of failed request: GLXBadDrawable Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) Serial number of failed request: 3303 Current serial number in output stream: 3303 make: *** [device.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2014