On Mon Feb 6 15:36:14 2023 +0000, Timo Zuccarello wrote:
> Is there anything I can help with? I obviously have a bit of a personal
> interest in having this "fixed" finally.
Well if you feel like it, you can always have a look at the MR and review the changes.
I also opened https://gitlab.winehq.org/wine/wine/-/merge_requests/2122 with the complete changes, if you want to give it a try, and confirm that it does the right thing for you as well. I've done a bit of testing but I don't often use any very fancy keyboard layout either.
Then I suspect that what's expected here is actually a bit more wider testing, so probably I should try to get this into Wine Staging or Proton first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_23264
Not completely sure if it's worth having for 8.0, but opening this to share the target I'm trying to reach.
--
v6: ntdll: Add a thread-specific category group cache.
ntdll: Use atomics and lock-free list for category groups.
ntdll: Implement Low Fragmentation Heap frontend.
ntdll: Count allocations and automatically enable LFH.
ntdll: Increase heap block tail_size capacity to 16 bits.
ntdll: Implement HeapCompatibilityInformation.
ntdll: Fix HeapWalk with empty uncommitted consecutive subheaps.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1628
WinRT apps check if the Windows theme is set to dark mode through IUISettings3::GetColorValue().
An option needs to be added to Winecfg to enable dark mode support, which just sets the registry key AppsUseLightTheme to 0 for dark mode and 1 for light mode. It will have to be in a separate merge request. Also, not sure if a dark mode checkbox should be added or if dark mode should be automatically set based on the loaded theme in Wine. Though, for the latter there needs to be a property that returns the mode of the theme. Name alone might not be sufficient.
--
v3: windows.ui/tests: Add IUISettings3::GetColorValue() tests.
windows.ui: Implement IUISettings3::GetColorValue().
windows.ui: Add IUISettings3 stub interface.
windows.ui: Add stub DLL.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2103
This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man…
Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them?
--
v2: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
user32: Add tests for WM_INPUT_DEVICE_CHANGE messages
https://gitlab.winehq.org/wine/wine/-/merge_requests/2120
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v5: windows.media.speech: Implement Vosk create and release functions in the unixlib.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
As these handles to a file don't have an unix-name attached, the
FileAllInformation query fails.
So only implement GetFileInformationByHandle() on top of queries which
don't fail.
I tested if the three ntdll calls instead of one did impact performance.
On cached handles they don't: a simple x100000 loop even shows a
~10% improvement, likely because we don't grab the filename from wineserver.
Note: that NtQueryInformationFile(FileAllInformation) (as other queries
returning file's name) will still fail on these unix-redirected handles.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51813
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1665
Windows has a 2G/2G split by default, but some addresses are fixed
in the win32 API, so we have to ensure that those addresses are still
available in the virtual memory space and not taken by Linux.
Kudos to stefand for taking the time to explain on IRC.
--
v6: ntdll: Explaining why 3G/1G split is needed on 32bit
https://gitlab.winehq.org/wine/wine/-/merge_requests/2118