August 2024 - wine-gitlab

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 30 Aug '24

30 Aug '24

On Thu Aug 29 23:38:23 2024 +0000, Vibhav Pant wrote: > @zfigura Testing it is tricky. My plan was to utilize it in the > bluetooth driver by directly calling `plugplay_send_event` from the > driver code itself, and I'm not sure what the equivalent of that would > be in Windows. > @rbernon I'm okay with using reserved as an offset to pass the device > path, but we'd still have to pass it for every message for filtering. I > didn't want to utilize `reserved` mostly out of caution, if it ever > turned out to be that the field did have some undocumented semantics > after all. After doing a bit of research, I believe the Windows interface is IoReportTargetDeviceChange(). See [1], which mentions using that function to report the device notification, and that user mode should register for it with RegisterDeviceNotification(). That function is probably only used for DBT_DEVTYP_HANDLE. I suspect there is no public interface for DBT_DEVTYP_DEVICEINTERFACE. The corresponding kernel-mode identifier for that one is EventCategoryDeviceInterfaceChange, but I suspect that IoReportTargetDeviceChange() only deals with EventCategoryTargetDeviceChange. This would make sense since device interface notifications should only be generated by the kernel anyway. [I have no idea about the other DBT_DEVTYPE_* values. Are they even ever sent in NT?] [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-pnp… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80501

1 0

Re: [PATCH v7 0/1] MR6299: ntdll: Determine the available address space dynamically for 64bit architectures.
by Garrett Mesmer (＠gmesmer) 30 Aug '24

30 Aug '24

On Fri Aug 30 02:21:05 2024 +0000, Alexandre Julliard wrote: > Much better, thanks. Could you please fix the authorship information in > the commit to use your full name? My apologies. I thought the authorship name was supposed to match the gitlab username instead of full name. It is corrected now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6299#note_80500

1 0

Re: [PATCH v5 0/1] MR5509: Add tests to MF Media Engine
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

@nsivov Should I close this one? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5509#note_80498

1 0

[PATCH v2 0/1] MR5978: winegstreamer: Optimise copy to DXGI buffer.
by Brendan McGrath (＠redmcg) 30 Aug '24

30 Aug '24

Using IMF2DBuffer2_Lock2DSize with LockFlags_Write dramatically improves performance over IMFMediaBuffer_Lock when using a DXGI buffer. IMFMediaBuffer_Lock does not know that this buffer will not be read and therefore performs an unnecessary transfer of the texture from GPU to CPU before it is overwritten. -- v2: winegstreamer: Optimise copy to DXGI buffer. https://gitlab.winehq.org/wine/wine/-/merge_requests/5978

3 7

[PATCH v5 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v5: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

3 7

[PATCH v4 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 30 Aug '24

30 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v4: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. bluetoothapis: Implement BluetoothSdpEnumAttributes. bluetoothapis: Implement BluetoothSdpGetContainerElementData. bluetoothapis: Implement BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

[PATCH v3 0/6] MR6402: bluetoothapis: Implement basic SDP methods.
by Vibhav Pant (＠vibhavp) 29 Aug '24

29 Aug '24

The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`: * `BluetoothSdpEnumAttributes` * `BluetoothSdpGetContainerElementData` * `BluetoothSdpGetElementData` * `BluetoothSdpGetAttributeValue` -- v3: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue. bluetoothapis: Implement BluetoothSdpGetAttributeValue. bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData. https://gitlab.winehq.org/wine/wine/-/merge_requests/6402

2 6

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 29 Aug '24

29 Aug '24

On Thu Aug 29 16:19:09 2024 +0000, Elizabeth Figura wrote: > Actually, I'm a bit confused, because now I'm not sure where RPC does do > that? I was assuming it was a user-marshalled type which implicitly > calls DuplicateHandle(), but that's not the case. > The lack of tests in this patch set is a little disturbing. Is it > possible to test this behaviour? I don't know under what circumstances > handle events are sent [and I can't easily find anyone successfully > using DBT_DEVTYP_HANDLE online]. We do have support for testing PnP > drivers, though, if that's necessary; see dlls/ntoskrnl.exe/tests/driver_pnp.c. @zfigura Testing it is tricky. My plan was to utilize it in the bluetooth driver by directly calling `plugplay_send_event` from the driver code itself, and I'm not sure what the equivalent of that would be in Windows. @rbernon I'm okay with using reserved as an offset to pass the device path, but we'd still have to pass it for every message for filtering. I didn't want to utilize `reserved` mostly out of caution, if it ever turned out to be that the field did have some undocumented semantics after all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80493

1 0

[PATCH 0/1] MR6403: winemac.drv: Call CGWindowListCreateImageFromArray through a dlsym-obtained pointer.
by Brendan Shanks (＠bshanks) 29 Aug '24

29 Aug '24

The macOS Sequoia SDK has "obsoleted" this function: calling it triggers a build error when targeting macOS Sequoia. It can still be used though, either by targeting pre-Sequoia or by getting a pointer to the function through dlsym(). This is intended to be temporary until ScreenCaptureKit.framework or some other approach can be used (see !5935). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6403

2 1

Re: [PATCH v2 0/1] MR6371: mfreadwrite: Always try inserting a converter for non-video streams. - approved
by Alexandre Julliard (＠julliard) 29 Aug '24

29 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6371

1 0

2025

2024

2023

2022

wine-gitlab August 2024