July 2014 - Wine-Devel - list.winehq.org

Confusion with submitting changes

by Kyle Marek

I am looking at the pages on winehq for development for wine. I am noticing that everything is talking about guidelines for making patches and submitting patches. Can I not make a pull request on my changes? I also noticed that it said that not everyone can submit patches and i inferred by the linked pages that it's to prevent legal trouble. How can I become eligible to submit changes?

July 30, 2014

Re: mshtml: Added IHTMLInputElement_get_form method implementation. (try 2)

by Jacek Caban

Hi Zhenbo, On 07/29/14 05:24, Zhenbo Li wrote: > + nsres = nsIDOMHTMLInputElement_GetForm(This->nsinput, &nsform); > + if (NS_FAILED(nsres) || nsform == NULL) { > + ERR("GetForm failed: %08x, nsform: %p\n", nsres, nsform); > + p = NULL; Not setting output value would be probably fine in this case, but if you do, please do it right (*p = NULL;). Jacek

July 29, 2014

Re: mshtml: Added IHTMLWindow2::navigate implementation.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=8129 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

July 28, 2014

Re: XInput over SDL

by akjsdfk sdkfnskd

> The advantage of using SDL is that we don't have to worry about how to > map any joystick to the required xinput layout, because SDL does that > for us. That advantage only applies to xinput. Not really true, you can do it other way as well https://wiki.libsdl.org/MigrationGuide?action=fullsearch&context=180&value=… this is off course if controller is mapped in SDL (which is happening a lot lately since configurations made in steam bpm are reported directly to SDL2 AFAIK) . - you can always request axis/button id by name. - you can always load custom simple SDL string mapping for your controller That is one great thing of SDL, it always works both ways. It provides low (device) and high level (just works) access to everything with regards, wh1sper_123 On 28 July 2014 22:58, Vincent Povirk <madewokherd(a)gmail.com> wrote: > On Mon, Jul 28, 2014 at 12:50 PM, Stefan Dösinger > <stefandoesinger(a)gmail.com> wrote: > > Using SDL is probably > > fine if there are good arguments that support its use and the > > Wine-internal layering makes sure that xinput_*.dll, dinput > > and winmm see the same joystick configuration. You could think about > > calling SDL from winex11.drv or dinput. > > SDL has two different api's, a joystick api and a game controller api. > They roughly correspond to dinput (generic joystick support) and > xinput (support for gamepads with a specific button layout) > respectively. > > The advantage of using SDL is that we don't have to worry about how to > map any joystick to the required xinput layout, because SDL does that > for us. That advantage only applies to xinput. >

July 28, 2014

Re: XInput over SDL

by Vincent Povirk

On Mon, Jul 28, 2014 at 12:50 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Using SDL is probably > fine if there are good arguments that support its use and the > Wine-internal layering makes sure that xinput_*.dll, dinput > and winmm see the same joystick configuration. You could think about > calling SDL from winex11.drv or dinput. SDL has two different api's, a joystick api and a game controller api. They roughly correspond to dinput (generic joystick support) and xinput (support for gamepads with a specific button layout) respectively. The advantage of using SDL is that we don't have to worry about how to map any joystick to the required xinput layout, because SDL does that for us. That advantage only applies to xinput.

July 28, 2014

Re: [3/3] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables

by Andrei Slăvoiu

În ziua de Lun 28 Iul 2014, la 14:24:12, Henri Verbeet a scris: > On 26 July 2014 20:24, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > > + /*Direct 3D 11*/ > > I guess this happened while rebasing. Yes, I also noticed that the first patch was still matching TNT explicitly and this one removed that. I'm not sure how I managed to do that but I'll send an update for both.

July 28, 2014

Re: XInput over SDL

by akjsdfk sdkfnskd

> My 2c is that this is more of an issue than SDL. Using SDL is probably > fine if there are good arguments that support its use and the > Wine-internal layering makes sure that xinput_*.dll, dinput > and winmm see the same joystick configuration. You could think about > calling SDL from winex11.drv or dinput. I think you missed the point completely here. Example I posted link for is not if you see/can use device or you don't as device is visible full time. Games use this code to decide which interface they use that way to run, DInput or XInput. And since that code does following - enumerate all DInput visible devices (XInput are exposed there too) ---- for each DInput device check if it is XInput ------ for each passed DInput device parse trough all system devices and when you find it (!!!!!) -------- check if device ID contains "IG_", if it does lets proclaim this XInput compatible now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") and use XInput API, if there was no compatible device then LoadLibrary ("DInput.dll") and use DInput API. This all happens in game, not in Windows or Wine. In wine case, NO compatible device is reported (!!!!!) - This part is where my question was aiming for, which part of wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket This part has nothing to do with DInput or XInput. Wine simply doesn't provide XInput compatible device when game parses them with CoSetProxyBlanket setup enumeration Maybe you missed it before "*If you want your game to support legacy DirectInput <http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).a…>** devices, you may use DirectInput and XInput side by side. When enumerating your DirectInput devices, all DirectInput devices will enumerate correctly. All XInput devices will show up as both XInput and DirectInput devices, but they should not be handled through DirectInput. You will need to determine which of your DirectInput devices are legacy devices, and which are XInput devices, and remove them from the enumeration of DirectInput devices.*" >From same page > I guess here you mean the X input extension rather than Microsoft's > xinput_*.dll, right? I guess XInput works better in remote X11 > situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I > don't really know how SDL talks to the joystick.) No, I meant exactly what I said. XInput is terribly deficient API. And as far as remote situations, X11 has way too terrible remote display to be usable for game in 50x50 resolution, way off some normal @Vincent Povirk > From what I could tell, SDL has a game controller api that's very > similar to xinput, which is pretty nice, and it can be configured to > map to any controller. It goes further, you can access same device as Joystick and handle axis and buttons manually or you can access it as Gamepad and have instant correct axis/button mapping. Not to mention haptic in XInput is downright terribly deficient (set left/right, ok it works), SDL is downright brilliant on haptic handling Since I'm not native english speaker, some parts might sound like I would try to persuade in use of SDL. If it does, I sincerely apologize and believe me... I don't, I'm honestly only interested in my question regarding who/where creates devices in CoSetProxyBlanket part p.s. sorry for double message Stefan, accidentally only sent response to you and not to list with regards wh1sper_123 On 28 July 2014 20:43, akjsdfk sdkfnskd <wh1sper.123.wtfit(a)gmail.com> wrote: > > My 2c is that this is more of an issue than SDL. Using SDL is probably > > fine if there are good arguments that support its use and the > > Wine-internal layering makes sure that xinput_*.dll, dinput > > and winmm see the same joystick configuration. You could think about > > calling SDL from winex11.drv or dinput. > > I think you missed the point completely here. > > Example I posted link for is not if you see/can use device or you don't as > device is visible full time. Games use this code to decide which interface > they use that way to run, DInput or XInput. And since that code does > following > - enumerate all DInput visible devices (XInput are exposed there too) > ---- for each DInput device check if it is XInput > ------ for each passed DInput device parse trough all system devices and > when you find it (!!!!!) > -------- check if device ID contains "IG_", if it does lets proclaim this > XInput compatible > > now if any of devices was XInput compatible LoadLibrary ("XInput1_3.dll") > and use XInput API, if there was no compatible device then LoadLibrary > ("DInput.dll") and use DInput API. This all happens in game, not in Windows > or Wine. In wine case, NO compatible device is reported > > (!!!!!) - This part is where my question was aiming for, which part of > wine creates devices here, so I wouldn't need to hack CoSetProxyBlanket > > This part has nothing to do with DInput or XInput. Wine simply doesn't > provide XInput compatible device when game parses them with CoSetProxyBlanket > setup enumeration > > Maybe you missed it before "*If you want your game to support > legacy DirectInput > <http://msdn.microsoft.com/en-us/library/windows/desktop/ee416842(v=vs.85).a…>** devices, > you may use DirectInput and XInput side by side. When enumerating your > DirectInput devices, all DirectInput devices will enumerate correctly. All > XInput devices will show up as both XInput and DirectInput devices, but > they should not be handled through DirectInput. You will need to determine > which of your DirectInput devices are legacy devices, and which are XInput > devices, and remove them from the enumeration of DirectInput devices.*" > From same page > > > I guess here you mean the X input extension rather than Microsoft's > > xinput_*.dll, right? I guess XInput works better in remote X11 > > situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I > > don't really know how SDL talks to the joystick.) > > No, I meant exactly what I said. XInput is terribly deficient API. And as > far as remote situations, X11 has way too terrible remote display to be > usable for game in 50x50 resolution, way off some normal > @Vincent Povirk > > From what I could tell, SDL has a game controller api that's very > > similar to xinput, which is pretty nice, and it can be configured to > > map to any controller. > > It goes further, you can access same device as Joystick and handle axis > and buttons manually or you can access it as Gamepad and have instant > correct axis/button mapping. Not to mention haptic in XInput is downright > terribly deficient (set left/right, ok it works), SDL is downright > brilliant on haptic handling > > > Since I'm not native english speaker, some parts might sound like I would > try to persuade in use of SDL. If it does, I sincerely apologize and > believe me... I don't, I'm honestly only interested in my question > regarding who/where creates devices in CoSetProxyBlanket part > > with regards > wh1sper_123 > > > On 28 July 2014 19:50, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2014-07-26 22:52, schrieb akjsdfk sdkfnskd: >> > - hotplugging/unplugging (well, only if game didn't use DInput to >> > scan new devices. if it is pure XInput, then it just works) >> My 2c is that this is more of an issue than SDL. Using SDL is probably >> fine if there are good arguments that support its use and the >> Wine-internal layering makes sure that xinput_*.dll, dinput >> and winmm see the same joystick configuration. You could think about >> calling SDL from winex11.drv or dinput. >> >> > - far better API than XInput >> I guess here you mean the X input extension rather than Microsoft's >> xinput_*.dll, right? I guess XInput works better in remote X11 >> situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I >> don't really know how SDL talks to the joystick.) >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJT1o1zAAoJEN0/YqbEcdMwWiYP/1/hOzt/v6VIp+gDS+cYJF5u >> 4fRyjT4zoWoFmOUrtApSj1VaBA2DeIaeeT97D0AAvD+FQ0GLaSYcEbn2EqLTcPJO >> N2IGHeTABdt3IBcD1Ya4AOVAryITaqoR83qmI6KElv/jrdpNDD6BaMemcFDno4Tm >> pqAYdlZBlFUWP5kEcSp7OsztNWCin0gdQ6BRRnU8nhtBtlOC5qV9VQPW5CQ66SDK >> +CM+3YkzARMoqmPk1qNu/OnkrubRRuwpHLsCySkfE9WnIDd29tIEAvMThUeZ8ucN >> OKmdIhs+RSOijrZecj0QDzhNA3fPR+EYx+OFr6h10Y3PxOgdwwAstDoakEhk1x4Y >> /jQu0XKtP6hDqCtSruxE8Ny3Hpb8p/zsdodHIhmp1W99QdHLbnKVdZJiCYBLToFW >> AVJ69NPm4Ae92jerN8pesHEl5B7kIGkQepCCpxWUjwPVWEjbB6fEcegGcGN/ccNn >> EWiBm1+14L5wgPSPCG/DhAfEPtfsig7TLdsL6zIZFLq0/+O6PVmjW9ezjT1PD00U >> NP7VqmYWY5Is7XtWI6NQ1Vqi5En47uKz+ZaQLPB0ExQB57XrubMo6C6aE53Q4HRg >> 5Kmh7vTBZecXPZGToT6Eg3z3y1Bc6B9piipxxfRzuqOU6EUzqHO8RzG/LuMrOLG7 >> kHdS1Q1gRro1FRAFDT3M >> =gcqc >> -----END PGP SIGNATURE----- >> > >

July 28, 2014

Re: XInput over SDL

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-26 22:52, schrieb akjsdfk sdkfnskd: > - hotplugging/unplugging (well, only if game didn't use DInput to > scan new devices. if it is pure XInput, then it just works) My 2c is that this is more of an issue than SDL. Using SDL is probably fine if there are good arguments that support its use and the Wine-internal layering makes sure that xinput_*.dll, dinput and winmm see the same joystick configuration. You could think about calling SDL from winex11.drv or dinput. > - far better API than XInput I guess here you mean the X input extension rather than Microsoft's xinput_*.dll, right? I guess XInput works better in remote X11 situations than anything SDL, /dev/js* or /dev/event/* based. (But tbh I don't really know how SDL talks to the joystick.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT1o1zAAoJEN0/YqbEcdMwWiYP/1/hOzt/v6VIp+gDS+cYJF5u 4fRyjT4zoWoFmOUrtApSj1VaBA2DeIaeeT97D0AAvD+FQ0GLaSYcEbn2EqLTcPJO N2IGHeTABdt3IBcD1Ya4AOVAryITaqoR83qmI6KElv/jrdpNDD6BaMemcFDno4Tm pqAYdlZBlFUWP5kEcSp7OsztNWCin0gdQ6BRRnU8nhtBtlOC5qV9VQPW5CQ66SDK +CM+3YkzARMoqmPk1qNu/OnkrubRRuwpHLsCySkfE9WnIDd29tIEAvMThUeZ8ucN OKmdIhs+RSOijrZecj0QDzhNA3fPR+EYx+OFr6h10Y3PxOgdwwAstDoakEhk1x4Y /jQu0XKtP6hDqCtSruxE8Ny3Hpb8p/zsdodHIhmp1W99QdHLbnKVdZJiCYBLToFW AVJ69NPm4Ae92jerN8pesHEl5B7kIGkQepCCpxWUjwPVWEjbB6fEcegGcGN/ccNn EWiBm1+14L5wgPSPCG/DhAfEPtfsig7TLdsL6zIZFLq0/+O6PVmjW9ezjT1PD00U NP7VqmYWY5Is7XtWI6NQ1Vqi5En47uKz+ZaQLPB0ExQB57XrubMo6C6aE53Q4HRg 5Kmh7vTBZecXPZGToT6Eg3z3y1Bc6B9piipxxfRzuqOU6EUzqHO8RzG/LuMrOLG7 kHdS1Q1gRro1FRAFDT3M =gcqc -----END PGP SIGNATURE-----

July 28, 2014

Re: XInput over SDL

by Vincent Povirk

>From what I could tell, SDL has a game controller api that's very similar to xinput, which is pretty nice, and it can be configured to map to any controller. So, although it is a heavy dependency, it could get us a good solution very quickly. Few other advantages: * The resulting xinput library could be used on Windows to support non-xinput-compatible controllers. * Steam has a controller configuration GUI, which happens to be compatible with SDL. The only alternative for picking up this configuration would be to duplicate logic from SDL. (Admittedly, this only helps for Wine-based ports of games on Steam, and possibly other games when Steam is used as a launcher.) We have very little control over heavy dependencies like SDL and can end up with unfixable bugs. One immediate concern is that SDL sets up signal handlers during initialization. I'd be interested in seeing your code for this even without the cleanup.

July 28, 2014

Re: mshtml: Added IHTMLInputElement_get_form method implementation.

by Jacek Caban

On 07/28/14 16:58, Zhenbo Li wrote: > My code is a little ugly, and I'm wondering if there is a better > solution. Is there any reason why you don't use nsIDOMHTMLInputElement::GetForm? Jacek

July 28, 2014