June 2015 - Wine-devel - list.winehq.org

[1/14]include: add ddk/hidclass.h
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/hidclass.h | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 include/ddk/hidclass.h

1 0

HID work, two sets of patches
by Aric Stewart 22 Jun '15

22 Jun '15

Hi all, So I have been working on HID support for the last few months. I have something ready for public review. It is not quite in shape to submit but since this is such a huge bit of work with so many moving pieces I thought it would be useful to have people able to help me make sure it works right. Answer to question #1, This is only implemented for Mac right now. That is because I know the mac HID stuff well and could do it. There will of course be a need for a linux minidriver as well, (like the mac minidriver) but I am not qualified to write that. I would be more than happy to help someone write it. Answer to question #2, No, this is not hooked up anywhere yet. Ideally it will get hooked up to be the bases for the winejoystick.drv, dinput, xinput and RawInput. I have a very rough implementation for winejoystick.drv but it is so rough that I am not presenting it yet. Answer to question #3, yes it works. I both have written my own HID client as well as the Microsoft hclient.exe test application and they work using this code as expected. Answer to question #4, No, this will most likely NOT support windows minidrivers. Mostly because of the lack of any sort of real plug and play support. There are some architecture bits that may be tricky with windows native minidrivers in .sys format. It is not outside the realm of doable eventually but I do not expect it to work right now. Finally, this is only the start. It is not implementing output or feature reports and there are still a lot of things to improve and implement. But I feel like I need to start getting this out into the public. Yes I will be submitting these and going through the whole process, but the more eyes and people willing to help me make these correct the better. That is why they are going to wine-devel first. So all comments welcome, but be kind. this was a lot of work and I am sure I made some stupid mistakes somewhere. -aric

1 0

Re: gdi32/freetype: Properly handle loading of FT_Long-sized types (Valgrind)
by Marc Bessières 21 Jun '15

21 Jun '15

Hi Nicolay, May I ask you a question on your patch? Why is the last line of the below extract still using reg_load_dword, and not reg_load_ftlong, while the cast was removed? It doesn't seem good to me, or there is something special about the flags? Cheers, Marc @@ -1541,10 +1549,10 @@ static void load_face(HKEY hkey_face, WCHAR *face_name, Family *family, void *bu else face->FullName = NULL; - reg_load_dword(hkey_face, face_index_value, (DWORD*)&face- >face_index); + reg_load_ftlong(hkey_face, face_index_value, &face->face_index); reg_load_dword(hkey_face, face_ntmflags_value, &face->ntmFlags); - reg_load_dword(hkey_face, face_version_value, (DWORD*)&face- >font_version); - reg_load_dword(hkey_face, face_flags_value, (DWORD*)&face->flags); + reg_load_ftlong(hkey_face, face_version_value, &face->font_version); + reg_load_dword(hkey_face, face_flags_value, &face->flags);

2 2

Re: server: return NULL from device_open_file on failure to allocate fd
by Sebastian Lackner 19 Jun '15

19 Jun '15

On 20.06.2015 00:22, Daniel Lehman wrote: > > Does this patch address a real issue or is it just by looking at the source? &file->obj should not lead to an invalid memory access because its just a more convenient way to do a type conversion. If file == NULL, then &file->obj will also be NULL. Of course its a matter of taste what is easier to read. Regards, Sebastian

2 1

Re: DInput axis mapping explanation
by Michael Gardner 19 Jun '15

19 Jun '15

Thank you, Aric! I have a couple more questions, if you have time to answer them. 1) Is Wine affected by the joystick mapping that can be done via jscal (and if not, why)? 2) How would I see the list of values as returned by the device, so I know what mapping to construct?

1 0

Re: [PATCH 5/5] wined3d: Add a setting for requesting OpenGL core profile usage.
by Henri Verbeet 19 Jun '15

19 Jun '15

On 19 June 2015 at 00:07, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -199,6 +200,14 @@ static BOOL wined3d_dll_init(HINSTANCE hInstDLL) > > if (hkey || appkey) > { > + if (!get_config_key( hkey, appkey, "UseCore", buffer, size)) > + { > + if (!strcmp(buffer,"enabled")) > + { > + TRACE("Requested OpenGL Core profile.\n"); > + wined3d_settings.use_core = TRUE; > + } > + } > if ( !get_config_key( hkey, appkey, "UseGLSL", buffer, size) ) > { > if (!strcmp(buffer,"disabled")) Would it make sense to express this in terms of the maximum (desktop) GL version to use instead? I imagine that at some point we'll want to use GL versions beyond 3.2, at which point it may be useful to have something a bit more flexible than just core/classic. > @@ -1711,6 +1709,7 @@ struct wined3d_gl_limits > > struct wined3d_gl_info > { > + BOOL legacy_gl; > DWORD glsl_version; > struct wined3d_gl_limits limits; > DWORD reserved_glsl_constants, reserved_arb_constants; This could probably just be an entry in the wined3d_gl_extension enum, which I suppose might have advantages if we need this information for building e.g. state or format tables.

2 2

Re: [PATCH 1/8] kernel32: Implement GetVolumePathName.
by Nikolay Sivov 19 Jun '15

19 Jun '15

> + const WCHAR fallbackpathW[] = { 'C',':','\\',0 }; This doesn't look right, could we make it dynamic using actual system drive? Same goes for tests, where you got hardcoded C:\ drive. According to docs this function should follow symlinks, will it potentially work with this implementation? Was it tested? I think it makes sense to submit tests first, maybe combining them a little, to have 1 tests patch instead of 4.

2 1

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 19 Jun '15

19 Jun '15

> First, yes, we do have hacks in CrossOver, but I think 'a lot' is > unfair. We really try to avoid those hacks, and we work hard to > eliminate them. For example, I reviewed our tracker that lists our > hacks. We have about 100 outstanding; in the last 6 months, we removed > 4 with upstream fixes, and added 1 new one. Further, we have long felt > that our diff with winehq was tragically large. But nicely, I can now > compare it to wine-staging, and claim that it is relatively modest > <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files > for wine-staging [1]. May I suggest you eliminate those hacks by merging them into the Wine codebase? Right now I have a feeling that Wine is wonderful, but Codeweavers is evil. It seems that this feeling is shared by many non-Codeweavers Wine developers. Codeweavers has done a lot of work on Wine, which I really appreciate, but I wish they would be much more open. I think there should, at least, be a public database listing all the hacks that are in Crossover. That way, I would know what the heck was going on inside those windowless walls. This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks. Not the Crossover-only ones like sendwndcmd.exe. Or the ones that can't be released because of NDAs. I mean the ones that would improve the vanilla Wine distribution. It seems possible to me that you're not releasing these hacks because they would improve vanilla Wine to the point where nobody would be willing to pay for Crossover anymore. If that is true, it's the other reason that I think Codeweavers is evil. I mean, can't you make enough money on consulting for companies that think that Crossover/Codeweavers is better because it costs more money? If there's no openness about what Crossover is doing to Wine, I just can't trust them to develop it. ~Theodore

20 29

Re: gdi32/tests: Japanese Win 7 uses MS Shell Dlg as its default GUI font.
by Marvin 19 Jun '15

19 Jun '15

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=14490 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

2 1

Re: [etags] repair make etags
by Alexandre Julliard 18 Jun '15

18 Jun '15

marc.bessieres(a)mykolab.com writes: > @@ -68,7 +68,7 @@ TAGSFLAGS = --langmap='c:+.idl.l.rh,make:(Make*.in)' > > TAGS etags: > $(RM) TAGS > - (test -d .git && git ls-files || find -L $(top_srcdir) -name '*.[ch]' -print) | xargs etags -a $(TAGSFLAGS) > + (test -d .git && git ls-files '*.[chly]' '*.idl' || find -L $(top_srcdir) -name '*.[ch]' -print) | xargs etags -a This will make the results less useful. You could add different commands based on the available etags, though installing exuberant-ctags may be an easier fix... -- Alexandre Julliard julliard(a)winehq.org

2 1