Stub Implementations of UIViewSettings and InputPaneStatics. This will reduce the FIXME clutter of missing UIViewSettings class implementation in .NET applications esp: Paint .Net
--
v4: windows.ui: Add stub IInputPaneStatics implementation.
windows.ui: Add stubs for UIViewSettings class.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5314
This is a series of commits tackling dead key state handling and scan code to vkey mapping improvements (especially for French and German keyboards).
* https://gitlab.winehq.org/mzent/wine/-/commit/6c5c90b746cc341049eec216e3bb9…: Simplifies the logic a bit there and also correctly null-terminates dead keys in ToUnicodeEx
* https://gitlab.winehq.org/mzent/wine/-/commit/a05e2fc5068a22cae94bc800b4972…: Windows does not do it and some applications misbehave with this, fully fixed later in https://gitlab.winehq.org/mzent/wine/-/commit/7cf1f6a00f17b0626126448f77a1c…
* https://gitlab.winehq.org/mzent/wine/-/commit/4bd96932139a22f2c3b1311e44c43…: MSDN states single keys are always uppercased there.
* https://gitlab.winehq.org/mzent/wine/-/commit/bac8e97d7e6a7494672d76f5fc586…: There is a bug in `CFStringCompare` with the flags used there currently, resulting in the comparison of the identical buffers "ß" and "ß" to be false. In any case `UCCompareText` behaves correctly and is much faster there.
* https://gitlab.winehq.org/mzent/wine/-/commit/bac5f485a09fbddd39efb8f2c0d87…: I think this was an accidental mistake there, going through all modifiers first per symbol almost always results in the wrong match being made. The logic is adjusted there now to be similar to the other iterations involving `char_matches_string`.
* https://gitlab.winehq.org/mzent/wine/-/commit/ffde55df4ae3f6d53198839c58356…https://gitlab.winehq.org/mzent/wine/-/commit/a453d0d4c89c59c3e1ba6c24d2d0f…: Adds additional symbol vkey mappings (now completely maps a German Macintosh and PC keyboard correctly). There are still some minor defects with the French layout (around the ú region), however changing the symbol mapping there will cause issues with other layouts I think, since the wrong match happens very early there in the priority in these cases. With this change at least the number row is now behaving correctly. Additionally the French Macintosh keyboard layout is further complicated by the "=" key being next to right shift, which is in conflict with pretty much any other keyboard layout. To fix this properly would require a partial rewrite of the heuristic being used or a new approach, but most likely more of a long term project.
* https://gitlab.winehq.org/mzent/wine/-/commit/7cf1f6a00f17b0626126448f77a1c…: Gives dead keys friendly names in `GetKeyNameFriendlyText`, just like Windows does. I tried to be as exhaustive as possible, but if there are any missing the mapping can be easily extended.
All in all the incorrect scan code to vkey mapping is usually not that tragic, since an application would need to be aware of the layout and have its own mapping of scan codes of each (FFXIV does this though). The French layout corrections are now "good enough" to behave correctly for all the hotbar slots being assigned there with these changes now though.
--
v7: winemac.drv: Give dead keys a friendly name in GetKeyNameText.
winemac.drv: Add additional German symbol vkeys.
winemac.drv: Resolve symbol vkeys first without modifiers.
winemac.drv: Use UCCompareText in char_matches_string.
winemac.drv: Uppercase single keys in GetKeyNameText.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5319
This is a series of commits tackling dead key state handling and scan code to vkey mapping improvements (especially for French and German keyboards).
* https://gitlab.winehq.org/mzent/wine/-/commit/6c5c90b746cc341049eec216e3bb9…: Simplifies the logic a bit there and also correctly null-terminates dead keys in ToUnicodeEx
* https://gitlab.winehq.org/mzent/wine/-/commit/a05e2fc5068a22cae94bc800b4972…: Windows does not do it and some applications misbehave with this, fully fixed later in https://gitlab.winehq.org/mzent/wine/-/commit/7cf1f6a00f17b0626126448f77a1c…
* https://gitlab.winehq.org/mzent/wine/-/commit/4bd96932139a22f2c3b1311e44c43…: MSDN states single keys are always uppercased there.
* https://gitlab.winehq.org/mzent/wine/-/commit/bac8e97d7e6a7494672d76f5fc586…: There is a bug in `CFStringCompare` with the flags used there currently, resulting in the comparison of the identical buffers "ß" and "ß" to be false. In any case `UCCompareText` behaves correctly and is much faster there.
* https://gitlab.winehq.org/mzent/wine/-/commit/bac5f485a09fbddd39efb8f2c0d87…: I think this was an accidental mistake there, going through all modifiers first per symbol almost always results in the wrong match being made. The logic is adjusted there now to be similar to the other iterations involving `char_matches_string`.
* https://gitlab.winehq.org/mzent/wine/-/commit/ffde55df4ae3f6d53198839c58356…https://gitlab.winehq.org/mzent/wine/-/commit/a453d0d4c89c59c3e1ba6c24d2d0f…: Adds additional symbol vkey mappings (now completely maps a German Macintosh and PC keyboard correctly). There are still some minor defects with the French layout (around the ú region), however changing the symbol mapping there will cause issues with other layouts I think, since the wrong match happens very early there in the priority in these cases. With this change at least the number row is now behaving correctly. Additionally the French Macintosh keyboard layout is further complicated by the "=" key being next to right shift, which is in conflict with pretty much any other keyboard layout. To fix this properly would require a partial rewrite of the heuristic being used or a new approach, but most likely more of a long term project.
* https://gitlab.winehq.org/mzent/wine/-/commit/7cf1f6a00f17b0626126448f77a1c…: Gives dead keys friendly names in `GetKeyNameFriendlyText`, just like Windows does. I tried to be as exhaustive as possible, but if there are any missing the mapping can be easily extended.
All in all the incorrect scan code to vkey mapping is usually not that tragic, since an application would need to be aware of the layout and have its own mapping of scan codes of each (FFXIV does this though). The French layout corrections are now "good enough" to behave correctly for all the hotbar slots being assigned there with these changes now though.
--
v6: winemac.drv: Give dead keys a friendly name in GetKeyNameText.
winemac.drv: Add additional German symbol vkeys.
winemac.drv: Resolve symbol vkeys first without modifiers.
winemac.drv: Use UCCompareText in char_matches_string.
winemac.drv: Uppercase single keys in GetKeyNameText.
winemac.drv: Do not append " dead" to dead keycodes in GetKeyNameText.
winemac.drv: Handle length of dead keycodes in ToUnicodeEx correctly.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5319
--
v2: widl: Respect u and l modifiers in expressions.
widl: Use struct integer for the aNUM and aHEXNUM tokens.
widl: Store the hexadecimal flag inside of the expr_t union.
widl: Do not allow "lu" as an integer suffix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5906
--
v3: mmdevapi/tests: Add test for capturing render loopback.
winepulse.drv: Implement pulse_get_loopback_capture_device().
winepulse.drv: Factor out wait_pa_operation_complete().
mmdevapi: Stub AUDCLNT_STREAMFLAGS_LOOPBACK support.
mmdevapi: Adjust timing after main loop start in client_Initialize().
mmdevapi: Store device_name as a pointer in struct audio_client.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5870
This MR adds support for creating file mapping objects backed by large pages on Linux, by making the following changes:
## wineserver
* On Linux, `create_temp_file` will first attempt to use memfds as the backing fd. If it fails, it'll return to the current codepath, creating a temporary file in either the server or config directory.
* The created memfd will be sealed against writes, if the caller requesting the appropriate page protection flags.
* This removes the requirement that FDs be only created on filesystems/directories that aren't `noexec`.
* In the server method `create_mapping` , if large pages have been requested by the caller, hold that the calling thread's token holds `SeLockMemoryPrivilege` .
* Additionally, add `SeLockMemoryPrivilege` to the list of privileges enabled for the Administrator.
## `ntdll`
* Add `virtual_get_min_large_page_size` and its exported wrapper `wine_unix_get_min_large_page_size`.
* On Linux, the minimum page size is determined by going through `/sys/kernel/mm/hugepages`. If hugepage support was not detected, `STATUS_NOT_SUPPORTED` is returned instead. On other platforms, the older hard-coded value of 2\*1024\*1024 is returned instead.
* `NtCreateSection` will validate certain parameters if large pages are requested. Specifically, it will return STATUS_INVALID_PARAMETER if the requested mapping is not anonymous/unnamed, or the size is not a multiple of the minimum supported page size.
## `kernelbase`
* `GetLargePageMinimum` will use `wine_unix_get_min_large_page_size`.
## `kernel32/tests`
* Add new test test_large_page_file_mapping, which validates privilege enforcements and parameter validation while creating large pages backed file mapping obejcts. The tests are skipped if `GetLargePageMinimum` returns 0.
--
v25: psapi: Add tests for querying information for large pages.
ntdll: Use PAGEMAP_SCAN ioctl to implement get_working_set_ex, if available.
kernel32: Add tests for large pages support.
ntdll: Support allocating virtual memory, creating and mapping files backed by large pages (SEC_LARGE_PAGES, MEM_LARGE_PAGES).
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769
If the script cache was already freed before ScriptTextOut() runs and
hence the sfnt member is not available, use the definition from
init_script_cache() to conditionally apply the ETO_GLYPH_INDEX flag.
--
v2: uniscribe: Update ETO_GLYPH_INDEX flag even if script cache is freed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5893
Instead of accessing the surface with macdrv_get_surface_display_image.
--
v9: winemac: Remove unnecessary surface_clip_to_visible_rect.
winemac: Remove now unnecessary cocoa window surface pointer.
winemac: Push window surface image updates to the main thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5798
GStreamer uses _SC_NPROCESSORS_CONF to determine 'max-threads'. On the
Steam Deck, this is configured to be 16 (which is double its number
of logical cores).
_SC_NPROCESSORS_CONF also disregards a process's CPU affinity, thus it
can create more threads than is useful, which ultimately wastes memory
resources.
Using affinity to set 'max-threads' addresses both these problems.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5923