February 2009 - Wine-Devel - list.winehq.org

Re: Status of USB driver support?

by emiliano esposito

Alexander Morozov wrote: >> If that USB Key is not of a supportable kind, then I apologize for >> asking. >> > > I think you should try. > Thanks. I tried this way: git clone git://source.winehq.org/git/wine.git ~/wine-git git-am 0001... git-am 0002... ./tools/wineinstall When launching a Wine application, I get some errors, I think this is the important one: err:winedevice:ServiceMain driver L"Usbhub" failed to load I have installed the Key driver but not yet added the registry keys. Should I do that or something else first? Thanks.

Feb. 18, 2009

Re: Need help on couple of patches

by Igor Tarasov

>> I just cant think of any regression test for that patch. It should >> test if the notification is really being forwarded? > Yes, that's what I mean. You're right, that might be hard, since you > have to simulate a mouse click. Now I don't get it. Looked through listview tests and there are not even one mouse-related test. And my patch could be tested by just sending HDN_ITEMCLICKW to listview control. And capturing the response notifications. But the code is: static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, const NMHEADERW *lpnmh) { ... switch (lpnmh->hdr.code) { ... case HDN_ITEMCLICKW: case HDN_ITEMCLICKA: { ... notify_forward_header(infoPtr, lpnmh); } break; Is that really should be tested for being executed, by simulating mouse click? Or I just don't understand something? >> And does that mean that tests for the second patch are also required? > Required? Not necessarily, but they always help. Obviously correct > patches tend to get applied even without regression tests, but even > they would benefit from them. Okay, gonna try.

Feb. 18, 2009

Re: Status of USB driver support?

by Eliot Blennerhassett

Alexander Morozov wrote: > I know nothing about these devices and I did not test them. But I think for > working with them a driver is also necessary (not only dll). To clarify, does your patch provide the general services on which all (many) USB .sys drivers are built? or is it very specific to usb security keys? I'm wondering whether to try your patch with the following drivers. Eg. I have a USB device. One driver is used to bootload the device, which then reappears with a different ID, and a second driver is used: Vid_0a63&Pid_0001 -> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DSLOADER] "Type"=dword:00000001 "Start"=dword:00000003 "ErrorControl"=dword:00000001 "Tag"=dword:00000014 "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\ 73,00,6c,00,6f,00,61,00,64,00,65,00,72,00,2e,00,73,00,79,00,73,00,00,00 "DisplayName"="Prism Sound dScope Series III - uninitialised (dsloader.sys)" "Group"="Base" Vid_0a63&Pid_0002 -> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DSUSBDRV] "Type"=dword:00000001 "Start"=dword:00000003 "ErrorControl"=dword:00000001 "Tag"=dword:00000015 "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\ 73,00,75,00,73,00,62,00,64,00,72,00,76,00,2e,00,73,00,79,00,73,00,00,00 "DisplayName"="Prism Sound dScope Series III (dsusbdrv.sys)" "Group"="Base" regards Eliot

Feb. 18, 2009

Re: msctf crosstest build failed

by Aric Stewart

Not sure. I can crossbuild it here on my mac with mingw without any issue. I will admit my knowledge of why is pretty limited. -aric Nikolay Sivov wrote: > Aric Stewart wrote: >> could you check to see if uuid is being build properly? >> >> -aric > Aric, is there any reason that we don't usually link to uuid in tests? > For example guids stored in uuid are redefined inline in > urlmon/tests/url.c: > > DEFINE_GUID(CLSID_IdentityUnmarshal,0x0000001b,0x0000,0x0000,0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46); > > DEFINE_GUID(IID_IBindStatusCallbackHolder,0x79eac9cc,0xbaf9,0x11ce,0x8c,0x82,0x00,0xaa,0x00,0x4b,0xa9,0x0b); > > > Could this be a reason of my failed build? >> Nikolay Sivov wrote: >>> Building today crosstests I've got: >>> >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include >>> -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include >>> -I../../../include -g -O2 -o testlist.cross.o testlist.c >>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>> -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In >>> function `initialize': >>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: >>> undefined reference to `_CLSID_TF_InputProcessorProfiles' >>> collect2: ld returned 1 exit status >>> make[2]: *** [msctf_crosstest.exe] Error 1 >>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>> make: *** [dlls/__crosstest__] Error 2 >>> >>> This outputs after: >>> make clean >>> ./configure >>> make depend && make >>> make crosstest >>> >>> What seems to be a problem? >>> >>> >> > >

Feb. 18, 2009

Re: msctf crosstest build failed

by Nikolay Sivov

Aric Stewart wrote: > could you check to see if uuid is being build properly? > > -aric Aric, is there any reason that we don't usually link to uuid in tests? For example guids stored in uuid are redefined inline in urlmon/tests/url.c: DEFINE_GUID(CLSID_IdentityUnmarshal,0x0000001b,0x0000,0x0000,0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46); DEFINE_GUID(IID_IBindStatusCallbackHolder,0x79eac9cc,0xbaf9,0x11ce,0x8c,0x82,0x00,0xaa,0x00,0x4b,0xa9,0x0b); Could this be a reason of my failed build? > Nikolay Sivov wrote: >> Building today crosstests I've got: >> >> i586-mingw32msvc-gcc -c -I. -I. -I../../../include >> -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c >> i586-mingw32msvc-gcc -c -I. -I. -I../../../include >> -I../../../include -g -O2 -o testlist.cross.o testlist.c >> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >> -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In >> function `initialize': >> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: >> undefined reference to `_CLSID_TF_InputProcessorProfiles' >> collect2: ld returned 1 exit status >> make[2]: *** [msctf_crosstest.exe] Error 1 >> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >> make[1]: *** [msctf/tests/__crosstest__] Error 2 >> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >> make: *** [dlls/__crosstest__] Error 2 >> >> This outputs after: >> make clean >> ./configure >> make depend && make >> make crosstest >> >> What seems to be a problem? >> >> >

Feb. 18, 2009

Re: msctf crosstest build failed

by Aric Stewart

could you check to see if uuid is being build properly? -aric Nikolay Sivov wrote: > Building today crosstests I've got: > > i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include > -g -O2 -o inputprocessor.cross.o inputprocessor.c > i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include > -g -O2 -o testlist.cross.o testlist.c > i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o > msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid > -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 > -luuid -lole32 -luser32 -lkernel32 > inputprocessor.cross.o: In function `initialize': > /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined > reference to `_CLSID_TF_InputProcessorProfiles' > collect2: ld returned 1 exit status > make[2]: *** [msctf_crosstest.exe] Error 1 > make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' > make[1]: *** [msctf/tests/__crosstest__] Error 2 > make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' > make: *** [dlls/__crosstest__] Error 2 > > This outputs after: > make clean > ./configure > make depend && make > make crosstest > > What seems to be a problem? > >

Feb. 18, 2009

msctf crosstest build failed

by Nikolay Sivov

Building today crosstests I've got: i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o testlist.cross.o testlist.c i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In function `initialize': /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined reference to `_CLSID_TF_InputProcessorProfiles' collect2: ld returned 1 exit status make[2]: *** [msctf_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' make[1]: *** [msctf/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' make: *** [dlls/__crosstest__] Error 2 This outputs after: make clean ./configure make depend && make make crosstest What seems to be a problem?

Feb. 18, 2009

Re: Need help on couple of patches

by Juan Lang

Hi Igor, > I just cant think of any regression test for that patch. It should > test if the notification is really being forwarded? Yes, that's what I mean. You're right, that might be hard, since you have to simulate a mouse click. > And does that mean that tests for the second patch are also required? Required? Not necessarily, but they always help. Obviously correct patches tend to get applied even without regression tests, but even they would benefit from them. --Juan

Feb. 18, 2009

Re: Need help on couple of patches

by Igor Tarasov

Hi Juan, Thanks for quick reply. > A regression test would go a long way toward proving your fix is correct. There are two problems: 1. I am not that good in C and I have never written any regression tests in C. 2. I just cant think of any regression test for that patch. It should test if the notification is really being forwarded? And does that mean that tests for the second patch are also required? P.S: > Getting your first patch committed is usually the toughest. Good > luck, and thanks for helping Wine, That's not my first patch ;) I just not too sure of what should I do.

Feb. 18, 2009

Re: Need help on couple of patches

by Juan Lang

Hi Igor, > It's a single-line patch that adds forwarding notification that was > omitted in wine code. This fix looks pretty simple, but it included > lots of reading/testing/debugging, and here is what I came with. And > as I told there it fixes one wine bugzilla bug. A regression test would go a long way toward proving your fix is correct. > The patch adresses 3 problems that all together fix that bug. My > question there was if I should send it in one patch or in several. But > it seems that no one have noticed that post. Several patches would definitely improve this one's chance of success. Getting your first patch committed is usually the toughest. Good luck, and thanks for helping Wine, --Juan

Feb. 18, 2009