Re: xbox 360 emulation with logitech cordless and dinput joy disable
On Wed, Jun 13, 2012 at 8:52 AM, Stefan Dösinger stefandoesin...@gmx.at wrote:
Hi,
The patch needs a few improvements before it can be accepted into Wine. I
can't comment on the dinput / xinput specifics of the patch, so this is a non-
exhaustive list of general suggestions.
Concerning the big picture, this patch needs a few discussions about
xinput.dll design. There have been some discussions about that in the past,
and I hope that some dinput devs can help out.
Am Dienstag, 12. Juni 2012, 23:48:53 schrieb Giovanni Ongaro:
From: root root@joe.(none)
Please configure git correctly, see http://wiki.winehq.org/GitWine section
3.3.
Also consider using a non-root user, but that's your personal setup, so not
really my business.
+ if (getenv(LINIXFORCENOJOY) != NULL) return FALSE; /*JoeFix disable
joystick*/
The problem with dinput vs xinput conflicts should probably be solved in a
different manner. That aside, such configurations are usually done via
registry keys. Also comments like /* I changed this here */ are useless, the
git history stores this information anyway.
+ ... //JoeFix DEAD ZONE
This is a C++ comment and not allowed in Wine. See
http://wiki.winehq.org/SubmittingPatches
+ fdJoy=open(/dev/input/js0,O_RDONLY | O_NONBLOCK);
Xinput.dll should not open joystick devices directy, and definitely not a
hardcoded one. I don't know if there's consensus about how xinput should be
implemented, but basing it on top of dinput might be a start.
Xinput should not be layered on top of dinput. On Windows it is really
a separate relatively low-level dll. The main problem with layering it
on top of dinput is that we have to invent some Wine-specific
extensions for force feedback which differs from dinput (as far as I
remember).
Definitely xbox support should not use the classic JS interface, but
the event interface (that's also the only one which can be used for
other xbox features like the rumble stuff, xbox leds, ..).
A good start would be to write a few tests to test how Windows announces(or
doesn't announce) Xbox gamepads and other gamepads/joysticks to games. My
understanding is that xinput.dll only works for Xbox gamepads. Do those show
up in dinput on Windows?
Xbox gamepads show up twice. Once the xbox360 gamepad driver is
loaded, it 'injects' a fake USB Hid gamepad device which is used by
dinput (and likely the legacy joystick API). There is no good way to
differentiate between the two gamepads. Microsoft recommends
applications which support both dinput and xinput to do enumeration
through dinput and then use WMI to check if the gamepad is an xbox
one. This doesn't work on Wine because we don't have proper WMI
support (yet).
+#define DEAD_ZONE 4096
...
+ if (e.number == 4) {
+ if (e.value == 1) {
+ FIXME(TRIGGER LEFT PRESSED\n);
+ pState-Gamepad.bLeftTrigger=32767;
+ }
+ else {
+ pState-Gamepad.bLeftTrigger=0;
+ }
...
+#define JOYMAX 3
+#define JOYMIN -3
The hardcoded numbers look questionable. The 4 and 1 are probably specific to
the joystick, the 32767 might have a symbolic name like XINPUT_MAX or
something.
The event interface provides proper limits for each axis. I think the
js interface has too (forgot the specifics).
Definitely axis and button names can't be hard coded to numbers. As I
mention later on these numbers (especially through the js-interface)
are device specific. Use BTN_A, ABS_X, and so on, but it is impossible
to do this for different gamepads.
A part of this seems to be needed due to the attempt to emulate an xbox
gamepad with a different device. Personally I'm not opposed to doing that, and
you might need some device specific tricks to pull this off. However, this
needs a more structured approach than hardcoding the values needed for one
specific Logitech device in the code.
There are a lot of gamepads from different vendors which are xinput
compatible. Supporting all of them is easy since they all use the same
button names since they use the same driver. We can support non-xinput
compatible ones, but it easily becomes tricky. What do you do if a
gamepad doesn't have the same buttons? How do you map different button
names (xpad devices use BTN_A/BTN_B, while others use BTN_BASE,
BTN_BASE2, ..) to the layout of the gamepad? Further input ranges
could in theory be different (you can scale values, but you could get
still run into issues).
Supporting non-xinput devices can be done, but I'm reluctant to doing
it in Wine. It is impossible to get it right (every device is
different) and it would be complicated for users too.
Then there is the whole design part. We had this discussion a couple
of times already. Alexandre used to be reluctant about adding
OS-specific code to xinput. Personally I think it is the only way to
properly implement xinput. Even though the xinput API is very
Re: DllMain() seems unused in ntoskrnl.exe
On Wed, Jun 13, 2012 at 07:46:47PM +0200, Francois Gouget wrote: The DllMain() function in ntoskrnl.exe appears to be unused: making it static causes a compiler warning to that effect and removing it entirely does not cause a compilation failure. Should it be removed or is there a build issue with ntoskrnl.exe? I added a FIXME() at the beginning, then typed notepad and it showed fixme:ntoskrnl:DllMain called So it is called. Not exactly sure, but I guess somehow via the loader magic. Ciao, Marcus
Re: msvcrt/tests: Fix portuguese locale test on NT4
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 http://testbot.winehq.org/JobDetails.pl?Key=19045 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: msvcrt/tests: Fix portuguese locale test on NT4
On 06/14/12 11:41, Marvin wrote: === WINEBUILD (build) === Patch failed to apply Looks like wine source was not updated on testbot yesterday.
Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).
Erich E. Hoover ehoo...@mymail.mines.edu writes: Real Name: Erich Hoover Description: This patch adds the ability in HTML Help to convert HTML encoded characters (e.g. ecirc;) into the Unicode character equivalent. This feature is needed by the table of contents and the index for displaying international characters in some CHM files. As of version 3 of the patch the decoding is done manually by parsing the HTML characters instead of using the web browser control, the search is a now a binary search, and it also includes some additional cleanup. It is important to note that HTML Help only supports characters within the ANSI code pages, so support for multi-byte characters is not necessary. I don't see why you'd want to use ANSI code pages for this, since they will be converted to Unicode anyway. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures
Hilko Bengen ben...@hilluzination.de writes: @@ -46,6 +46,8 @@ #include pshpack1.h +#include endian.h endian.h is not portable, you should use the endianness defines from the Wine headers instead. -- Alexandre Julliard julli...@winehq.org
Re: [05/11] windowscodecs: Add support for more types of IFD fields. Resend.
Dmitry Timoshkov dmi...@baikal.ru writes:
@@ -650,30 +672,43 @@ static HRESULT load_IFD_entry(IStream *input, const
struct IFD_entry *entry,
SWAP_ULONG(count);
type = entry-type;
SWAP_USHORT(type);
+item-value.vt = tag_to_vt(type);
value = entry-value;
SWAP_ULONG(value);
switch (type)
{
+ case IFD_BYTE:
+ case IFD_SBYTE:
+if (count == 1)
+{
+item-value.u.bVal = *(BYTE *)value;
+break;
+}
+FIXME(loading multiple byte fields is not implemented\n);
+break;
This seems to contradict the endianness support. Are you really supposed
to byte-swap arrays of bytes?
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 4).
Erich E. Hoover ehoo...@mymail.mines.edu writes: On Thu, Jun 14, 2012 at 11:22 AM, Alexandre Julliard julli...@winehq.org wrote: ... I don't see why you'd want to use ANSI code pages for this, since they will be converted to Unicode anyway. It's important to use the ANSI code page because of the way the characters are handled internally (you can see this in part 4). If you just convert the characters straight to unicode then ecirc; will become ê instead of ę in the Polish (?) code page (similar behavior in other code pages). You can see an example in the screenshot from Bug #27767 : http://bugs.winehq.org/attachment.cgi?id=35529 . If you converted straight to Unicode then you'd need to convert it a second time to get the proper character, unless I'm missing something. Wow, is Windows really doing it this way? That's a good contestant for the Most Stupid Win32 API Behavior award. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver
On Wed, Jun 13, 2012 at 09:02:33PM +0200, Alexandre Julliard wrote:
Andrew Eikum aei...@codeweavers.com writes:
The configure.ac changes and parts of the driver itself were written by
Maarten Lankhorst.
It doesn't work here, it's apparently using the driver even though
PulseAudio is not running on this box:
I've tried this on two operating systems, one with libpulse 2.0 and
one with libpulse 1.1, and I can't reproduce it. It always works
correctly.
Also, I should change this to load libpulse at runtime instead of
compile time, right? It works fine as-is, except it prints a
load_builtin_dll err. I'll do that for the next version of the patch.
../../../tools/runtest -q -P wine -M amstream.dll -T ../../.. -p
amstream_test.exe.so amstream.c touch amstream.ok
err:pulse:AudioClient_Initialize PulseAudio no longer running?
err:quartz:DSoundRender_create Cannot create Direct Sound object (88890010)
fixme:ole:CoCreateInstance no instance created for interface
{56a86895-0ad4-11ce-b03a-0020af0ba770} of class
{79376820-07d0-11cf-a24d-0020afd79767}, hres is 0x88890010
amstream.c:274: Test failed: IAMMultiMediaStream_AddMediaStream returned:
88890010
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver
Andrew Eikum aei...@codeweavers.com writes: Also, I should change this to load libpulse at runtime instead of compile time, right? It works fine as-is, except it prints a load_builtin_dll err. I'll do that for the next version of the patch. Failing to load when libpulse is missing is fine, there's no need to load it dynamically. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH (try2)] winepulse.drv: Add PulseAudio driver
On Thu, 14 Jun 2012 13:00:33 -0500 Andrew Eikum aei...@codeweavers.com wrote: On Wed, Jun 13, 2012 at 09:02:33PM +0200, Alexandre Julliard wrote: It doesn't work here, it's apparently using the driver even though PulseAudio is not running on this box: I've tried this on two operating systems, one with libpulse 2.0 and one with libpulse 1.1, and I can't reproduce it. It always works correctly. A forum user reported this behavior with the Ubuntu 12.04 wine1.5 packages, which are apparently only available with the winepulse patch. http://forum.winehq.org/viewtopic.php?t=15747 -- Rosanne DiMesio dime...@earthlink.net
Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures
* Alexandre Julliard: endian.h is not portable, you should use the endianness defines from the Wine headers instead. So, do I need to define my own htobe16 and htobe32 functions or macros based on whether WORDS_BIGENDIAN is defined or not? -Hilko
RFC: comdlg32: Fix null lpstrFile uses in FILEDLG95_OnOpen
Hi, I have written a patch to fix bug 17229 and would like to request help to complete the test part. The test creates a common dialog and select a filename (file does not need to exist), it was copied from other tests in the same file (comdlg32/tests/filedlg.c). It's not possible to have a default file name because lpstrFile is used to do this and it's NULL. To fill a filename in the common dialog control that appears I have used EnumChildWindows to find the textbox and set the filename in it. The main problem is how to detect that a HWND is a textbox? Currently I'm sending SetWindowText to every control and that does work but I think the patch may be rejected by that. The patch can be downloaded at: https://testbot.winehq.org/JobDetails.pl?Key=19074 The problem is in the line 56. Thanks in advance, Bruno
Re: [05/11] windowscodecs: Add support for more types of IFD fields. Resend.
Alexandre Julliard julli...@winehq.org wrote:
+ case IFD_BYTE:
+ case IFD_SBYTE:
+if (count == 1)
+{
+item-value.u.bVal = *(BYTE *)value;
+break;
+}
+FIXME(loading multiple byte fields is not implemented\n);
+break;
This seems to contradict the endianness support. Are you really supposed
to byte-swap arrays of bytes?
It doesn't matter at this point. I'm planning to add a test for endianness
handling in IFD reader, if this is proved to be wrong the fix will be trivial.
Please consider accepting the patch as is.
--
Dmitry.
MSVCP60.dll
Firstly, I'm not a Linux user. I'm a Windows programmer but I have a passing knowledge of Linux (and several friends who are Linux programmers). I write a Windows application which gets launched as a child process by a popular Linux DAW. My program was first written many years ago when the (then) current version of Wine was about v0.9.58. Over a hundred people are using my program with old versions of Wine and I've had no complaints so far. Recently however, two customers tried to use it with Wine v1.5.35. In both cases the program crashed - apparently because some particular function wasn't found in MSVCP60.dll (at the moment, we don't know which function). Both customers went to a web site called WineTricks from where they were able to install an alternative version of MSVCP60.dll. My app now gets past the place where it previously crashed although it now crashes further on... :-( It looks as if the MSVC6 runtime module(s) that now come with Wine aren't the same as the ones from v0.9.58. Either they're different versions of the Microsoft DLLs or maybe they're now being implemented by somebody else, perhaps as part of Wine development? Either way, they don't work with my particular app any more. I still have Visual C++6 installed on an old computer, together with both the source code and the (InstallShield) packager for my original app. So is there anything I can do to make this work? For example, do I need to link against a particular version of the MSVC6 runtime? Or do I need to configure my packager so that it specifically distributes the runtime modules that my app linked to? I never did that in the past - because whichever runtime came with Wine seemed to work. Any advice? John
