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

[PATCH 1/2] ntoskrnl: Update the interface if it is already in the device_interfaces tree

by Rémi Bernon

As we are going to reuse the same device id when re-plugging a previously plugged SDL controller, the device interfaces are still present in the tree and IoRegisterDeviceInterface was not updating the device pointer. Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntoskrnl.exe/pnp.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/dlls/ntoskrnl.exe/pnp.c b/dlls/ntoskrnl.exe/pnp.c index 30865a05dcb..79aa343c1b2 100644 --- a/dlls/ntoskrnl.exe/pnp.c +++ b/dlls/ntoskrnl.exe/pnp.c @@ -622,7 +622,9 @@ NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *cla WCHAR device_instance_id[MAX_DEVICE_ID_LEN]; SP_DEVICE_INTERFACE_DETAIL_DATA_W *data; NTSTATUS status = STATUS_SUCCESS; + UNICODE_STRING device_path; struct device_interface *iface; + struct wine_rb_entry *entry; DWORD required; HDEVINFO set; @@ -660,19 +662,32 @@ NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *cla data->DevicePath[1] = '?'; TRACE("Returning path %s.\n", debugstr_w(data->DevicePath)); + RtlCreateUnicodeString( &device_path, data->DevicePath); + + entry = wine_rb_get( &device_interfaces, &device_path ); + if (entry) + { + iface = WINE_RB_ENTRY_VALUE( entry, struct device_interface, entry ); + if (iface->enabled) + ERR("Device interface %s is still enabled.\n", debugstr_us(&iface->symbolic_link)); + } + else + { + iface = heap_alloc_zero( sizeof(struct device_interface) ); + RtlCreateUnicodeString(&iface->symbolic_link, data->DevicePath); + if (wine_rb_put( &device_interfaces, &iface->symbolic_link, &iface->entry )) + ERR("Failed to insert interface %s into tree.\n", debugstr_us(&iface->symbolic_link)); + } - iface = heap_alloc_zero( sizeof(struct device_interface) ); iface->device = device; iface->interface_class = *class_guid; - RtlCreateUnicodeString(&iface->symbolic_link, data->DevicePath); if (symbolic_link) RtlCreateUnicodeString( symbolic_link, data->DevicePath); - if (wine_rb_put( &device_interfaces, &iface->symbolic_link, &iface->entry )) - ERR("Failed to insert interface %s into tree.\n", debugstr_us(&iface->symbolic_link)); - HeapFree( GetProcessHeap(), 0, data ); + RtlFreeUnicodeString( &device_path ); + return status; } -- 2.20.1

July 25, 2019

Re: [PATCH v2] windowscodecs: Move from_sRGB_component into the same section as its sole sole user.

by Zebediah Figura

Typo in the title, for whatever it's worth ("sole sole user").

July 24, 2019

Re: [PATCH v2 5/6] server: Don't emulate rawinput mouse events if native exist.

by Derek Lesho

With emulate_raw_mouse_press, I wanted to keep our options open as Xi_RawButtonPress/Release do exist, and maybe in the future a usecase will come up where we want to use them. If we can confirm that there is no point to keeping them for either the mac or x11 driver, I'll remove it. On Wed, Jul 24, 2019 at 6:28 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > On Tue, 2019-07-23 at 12:16 -0400, Derek Lesho wrote: > > Well, while it is certainly possible to use actual rawinput for sending > > keyboard events and mouse presses, I don't see much of an incentive to. > > With mouse motion, the DE is bypassed so mouse acceleration and > sensitivity > > are bypassed (just like on windows), but I don't think DE's modify > keyboard > > events or mouse presses in any meaningful way. > > Then you don't need the emulate_raw_mouse_press flag. Keyboard raw > input is another topic of course. > > If you drop the emulate_raw_mouse_press flag, which isn't going to be > enabled anyway as you said, I believe your patch, and the code, will be > simpler. I think you can drop the big if and only change: > > - msg_data->rawinput.mouse.x = x - desktop->cursor.x; > - msg_data->rawinput.mouse.y = y - desktop->cursor.y; > + msg_data->rawinput.mouse.x = emulate_raw_mouse_move ? x - > desktop->cursor.x : 0; > + msg_data->rawinput.mouse.y = emulate_raw_mouse_move ? y - > desktop->cursor.y : 0; > > You could then conditionally call queue_hardware_message below if the > button data is empty in order to avoid sending empty events. > -- > Rémi Bernon <rbernon(a)codeweavers.com> > >

July 24, 2019

TestBot news

by Francois Gouget

First I upgraded the w2003std VM to have all the Windows updates as of this week. But that's just a side-show. Mainly I upgraded half the Linux boxes to Debian 10. The one everyone will be interested in is debian10, the aptly named new Linux test VM. - It has FAudio. More tests! - It has sse3 so the bcrypt tests no longer fail. The debian9 VM is still available in case you want to use it as a reference point for the debian10 results. Note that I moved it to vm2 which has an old Opteron 6128 processor which does not support sse3 (it's the only such processor in the TestBot stable). For now debian9 still runs the same tests as before but only on demand or for the daily WineTest run. Eventually I'll trim it down. I'll be monitoring the debian10 results from afar but please, do let me know if you notice something weird of if you get TestBot errors (the other reason for keeping debian9 around is as a fallback for the new debian10 VM). I also upgraded the cw1-hd6800 and cw2-gtx560 boxes to Debian 10 so they too get FAudio support now. And I upgraded one of the VM hosts, vm2, to Debian 10. That really went badly :-( First I locked myself out of that box when it lost network access after the upgrade. I guess that's a warning tale for those having only LDAP accounts on their servers. Normally that shouldn't have been an issue because our KVM makes it possible to boot from an ISO (from there you can mount the filesystem, chroot and fix things). But the BIOS on this machine stubbornly refused to even see the virtual USB CD drive. But the real problem is that since the upgrade the w2003std and wvistau64 VMs this machine normally runs get into a boot loop. Yet other VMs like debian9 and w7u seem to run fine. So I suspect this issue only impacts Windows Vista and older :-/ I did not find useful information on this online. I tried various workarounds like downgrading QEmu from 1:3.1+dfsg-8~deb10u1 back to 1:2.8+dfsg-6+deb9u5, or changing the emulated CPU, removing virtual hardware, replacing virtio devices with regular ones, etc. All to no avail. I'm a bit surprised downgrading QEmu did not help. That would mean the issue comes from elsewhere: kernel, C library, libvirt? My development machine runs the same QEmu version on Debian 10 and everything looks ok here, including running the w2003std VM. So I suspect some CPU / motherboard support issue. So I'll wait a bit before upgrading the other VM hosts: I can compensate the lost of a host by shuffling the VMs around (it takes time though). But losing a second host entirely or even partially would really start to make a dent in the TestBot performance and require that I move another bunch of VMs around :-( -- Francois Gouget <fgouget(a)codeweavers.com>

July 24, 2019

Re: [PATCH] dxgi: Obey image count limits for Vulkan swapchains.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

July 24, 2019

Re: [PATCH v2 5/6] server: Don't emulate rawinput mouse events if native exist.

by Rémi Bernon

On Tue, 2019-07-23 at 12:16 -0400, Derek Lesho wrote: > Well, while it is certainly possible to use actual rawinput for sending > keyboard events and mouse presses, I don't see much of an incentive to. > With mouse motion, the DE is bypassed so mouse acceleration and sensitivity > are bypassed (just like on windows), but I don't think DE's modify keyboard > events or mouse presses in any meaningful way. Then you don't need the emulate_raw_mouse_press flag. Keyboard raw input is another topic of course. If you drop the emulate_raw_mouse_press flag, which isn't going to be enabled anyway as you said, I believe your patch, and the code, will be simpler. I think you can drop the big if and only change: - msg_data->rawinput.mouse.x = x - desktop->cursor.x; - msg_data->rawinput.mouse.y = y - desktop->cursor.y; + msg_data->rawinput.mouse.x = emulate_raw_mouse_move ? x - desktop->cursor.x : 0; + msg_data->rawinput.mouse.y = emulate_raw_mouse_move ? y - desktop->cursor.y : 0; You could then conditionally call queue_hardware_message below if the button data is empty in order to avoid sending empty events. -- Rémi Bernon <rbernon(a)codeweavers.com>

July 24, 2019

Re: Another Call for WineConf 2019 presentations

by Michael Stefaniuc

On 7/23/19 7:46 PM, Aric Stewart wrote: > Hello again! > > Another call for talks! I have gotten only one single person contacting me. This means right now we have nothing scheduled presentation wise and 10 open slots. > > Please send me information if you would like to do a talk! Volunteer your self, Volunteer your friends, Volunteer your dog. Lets get some more on this schedule. If there is interest I could do a coccinelle tutorial / presentation on how to use it to find code patterns and do quick and not so dirty code transformations. bye michael > On 5/29/19 11:39 AM, Aric Stewart wrote: >> Hello, >> >> Again this year I am helping coordinate the talks and presentations! I hope that people find it helpful and useful! Last work worked out well enough that I am sticking to the same rough format. I think it worked for most other people as well! >> >> If you would like to give a presentation! Please e-mail wineconf(a)winehq.org or me directly! I will keep the Wiki updated with presentations and scheduling as we get it worked out. >> When you propose your talk if you have a preference toward a time slot and Saturday or Sunday please express that. >> >> General Guidelines: >> * Please provide an estimate of how long your talk will be. We are shooting for approximate 40 minute slots with between 15-20 minutes of talk and with likely an equal amount of question and discussion time afterward. Generally shorter talks are not an issue, however longer talks will need to be discussed and will be considered based on the rest of the schedule. >> >> * Topics should obviously be of interest to the other attendees, i.e., the broader Wine community, but note that that doesn't imply the talk has to be about Wine itself >> >> * If you have a preferred time and date for your talk please indicate that to me when you submit your talk. We will try to make it work as best we can. >> >> Here are the rough proposed slots, They will be changed and modified as required by the addenda as it gets fleshed out. Understand that even with this shift toward a scheduled day we will not disrupt productive conversation to fit to the schedule. The schedule will warp and flow as required to facilitate the talk, not force the talks to conform to it. This does mean if you are planing to try to attend a given talk you will likely want to arrive a bit early and understand if when you arrive the schedule is either behind or ahead of plan. >> >> Daily Slots: >> >> 09:00 - 09:40 slot 1 >> 09:45 - 10:25 slot 2 >> 10:30 - 11:00 break >> 11:00 - 11:40 slot 3 >> 12:00 - 13:00 lunch break >> 13:00 - 13:40 slot 4 >> 13:45 - 14:25 slot 5 >> 14:30 - 15:00 break >> 15:00 - 15:40 slot 6 >> 15:45 - 16:25 slot 7 >> 16:25 - 17:00 Overflow time / small group discussion / short presentations >> >> We will track proposed presentations on the WineConf Wiki: https://wiki.winehq.org/WineConf2019 >> >> Likely we will have open time at the conference which we will propose presentations and fill at the time. We have never had a problem finding things we all want to talk about. >> >> thanks! >> -aric >> >> _______________________________________________ >> wineconf mailing list >> wineconf(a)winehq.org >> https://www.winehq.org/mailman/listinfo/wineconf >> > >

July 23, 2019

Re: [PATCH 2/2] msctf: Accept ITfInputProcessorProfileActivationSink in ThreadMgr AdviseSink

by Marvin

Hi, While running your changed tests, 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=54846 Your paranoid android. === wvistau64 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === wvistau64_zh_CN (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === wvistau64_fr (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === wvistau64_he (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === w2008s64 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === w7u (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w7pro64 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w8 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w864 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w1064v1507 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w1064v1809 (32 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === wvistau64 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === w2008s64 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call === w7pro64 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w864 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w1064v1507 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call === w1064v1809 (64 bit report) === msctf: inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call inputprocessor.c:754: Test failed: unexpected call

July 23, 2019

Re: [PATCH v2 6/6] user32/tests: Test changing activation from within WM_ACTIVATE's WA_INACTIVE message

by Marvin

Hi, While running your changed tests, 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=54841 Your paranoid android. === wvistau64_zh_CN (32 bit report) === Report errors: user32:win is missing some failure messages === w1064v1809 (32 bit report) === user32: win.c:3163: Test failed: SetActiveWindow returned 00000000 instead of 000803BE win.c:3221: Test failed: expected 000803BE, got 00000000 win.c:3863: Test failed: hwnd 00040038 message 0060 win.c:4003: Test failed: hwnd 00BD0380/00BD0380 message 00a1 win.c:3307: Test failed: SetActiveWindow(0) returned 00000000 instead of 000803BE === w1064v1809 (64 bit report) === user32: win.c:3163: Test failed: SetActiveWindow returned 0000000000000000 instead of 00000000000803BE win.c:3221: Test failed: expected 00000000000803BE, got 0000000000000000 win.c:3863: Test failed: hwnd 0000000000040038 message 0060 win.c:4003: Test failed: hwnd 0000000000BD0380/0000000000BD0380 message 00a1 win.c:3307: Test failed: SetActiveWindow(0) returned 0000000000000000 instead of 00000000000803BE === debian9 (64 bit WoW report) === user32: msg.c:8746: Test failed: WaitForSingleObject failed 102 msg.c:8752: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x000f instead msg.c:8752: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0014 instead msg.c:8752: Test failed: destroy child on thread exit: 2: the msg sequence is not complete: expected 0014 - actual 0000

July 23, 2019

Re: [PATCH v2 4/6] user32/tests: Add test for a window that doesn't want to be deactivated

by Marvin

Hi, While running your changed tests, 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=54839 Your paranoid android. === wvistau64_zh_CN (32 bit report) === Report errors: user32:win is missing some failure messages === w1064v1809 (32 bit report) === user32: win.c:3152: Test failed: SetActiveWindow returned 00000000 instead of 000803BE win.c:3210: Test failed: expected 000803BE, got 00000000 win.c:3834: Test failed: hwnd 00040038 message 0060 win.c:3974: Test failed: hwnd 000B0170/000B0170 message 00a1 win.c:3278: Test failed: SetActiveWindow(0) returned 00000000 instead of 000803BE === w1064v1809 (64 bit report) === user32: win.c:3152: Test failed: SetActiveWindow returned 0000000000000000 instead of 00000000000803BE win.c:3210: Test failed: expected 00000000000803BE, got 0000000000000000 win.c:3834: Test failed: hwnd 0000000000040038 message 0060 win.c:3974: Test failed: hwnd 0000000000BD02FA/0000000000BD02FA message 00a1 win.c:3278: Test failed: SetActiveWindow(0) returned 0000000000000000 instead of 00000000000803BE === debian9 (32 bit Chinese:China report) === user32: win.c:10173: Test failed: Expected foreground window 000E0120, got 00E300D4 win.c:10175: Test failed: GetActiveWindow() = 00000000 win.c:10175: Test failed: GetFocus() = 00000000 win.c:10176: Test failed: Received WM_ACTIVATEAPP(1), did not expect it. win.c:10177: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:10185: Test failed: Expected foreground window 000E0120, got 00000000 win.c:10187: Test failed: GetActiveWindow() = 00000000 win.c:10187: Test failed: GetFocus() = 00000000 win.c:10195: Test failed: Received WM_ACTIVATEAPP(1), did not expect it.

July 23, 2019