Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v26: win32u: add SNI driver for systray handling
win32u: add a SystrayRunLoop driver interface
win32u: Refactor NotifyIcon driver interface into separate calls.
win32u: add a ShowBalloon driver interface
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
This MR has a similar goal !3259, but the difference is that this MR aims to only isolate the XDG user dirs and nothing else. This is entirely possible to do through winecfg, but the problem with using winecfg is that you would have to manually run it on every new wineprefix, and therefore to automate this process without winecfg would require a manual removal of the symlinks. My solution was to create a simple on/off environment variable to disable or enable the creation of the symlinks.
--
v2: shell32: Add environment variable to prevent symlinking home folders.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4584
On Sun Dec 3 10:05:54 2023 +0000, Shmerl wrote:
> Ability to use whatever Wayland supports that X11 doesn't. Like proper
> HDR work and such.
I've noticed more overloading in Xwayland when playing oldrunescape, so I'm playing Wayland despite having no keyboard input.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54780
>You should test applications to see if a stub actually helps before
sending in an MR.
I do test , if the program is free, but this one isn't, so cannot test.
I think it's just fine to add the stub so that user can test it in the next
release to see if it helps workaround the bug and report back.
Apparently you have access to this program, and already knew the answer.
Please share this info in future in bugreport then.
Op vr 1 dec 2023 om 03:15 schreef Mohamad Al-Jaf (@maljaf) <
gitlab(a)winehq.org>:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4555#note_54778
On Sun Dec 3 09:48:00 2023 +0000, Snowiiii wrote:
> what are actually are all the advantages of using native wayland ?
Ability to use whatever Wayland supports that X11 doesn't. Like proper HDR work and such.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54774
On Sun Dec 3 09:14:08 2023 +0000, Shmerl wrote:
> No particular difference in performance. But I can't compare input due
> to it being broken.
what are actually are all the advantages of using native wayland ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54773
On Sun Dec 3 09:10:50 2023 +0000, Shmerl wrote:
> Just sharing a test result (running Cyberpunk 2077 with winewayland
> using Wine+esync+vkd3d-proton).
> 
> Note: Mouse input is broken as expected. Adaptive sync / VRR works fine.
> DE: KDE Plasma 5.27.9.
can you compare native wayland vs Xwayland ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54771
Just sharing a test result (running Cyberpunk 2077 with winewayland using Wine+esync+vkd3d-proton).

Note: Mouse input is broken as expected.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54769
On Sat Dec 2 17:59:48 2023 +0000, Petrichor Park wrote:
> Doing this would require changes to other test harness machinery;
> specifically it would stop printing any context if the shader fails to
> compile, or if there's some other problem.
> It would require a lot of changes to everything the harness could handle
> to provide better feedback in each case; I think that's kind of out of
> scope of this MR and probably out of scope for the harness in general.
(the change is to remove the `vkd3d_test_push_context` call on L1439, and then I'd need to remove the matching `vkd3d_test_pop_context` call that's somewhere)
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/499#note_54756
On Sat Dec 2 17:59:48 2023 +0000, Giovanni Mascellani wrote:
> Right now this prints both the line where the section starts and the
> line there the `probe` directive here. This feels a bit too much.
Doing this would require changes to other test harness machinery; specifically it would stop printing any context if the shader fails to compile, or if there's some other problem.
It would require a lot of changes to everything the harness could handle to provide better feedback in each case; I think that's kind of out of scope of this MR and probably out of scope for the harness in general.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/499#note_54755
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55075
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
--
v4: apisetschema: Add api-ms-win-core-com-l2-1-1
ole32: Move convert functions back from coml2
coml2: Remove temporary exports
ole32: Remove storage32.h
coml2: Move StgSetTimes from ole32
coml2: Move StgOpenStorageOnILockBytes from ole32
coml2: Move StgCreateDocfileOnILockBytes from ole32
coml2: Move StgOpenStorageEx from ole32
coml2: Move StgOpenStorage from ole32
coml2: Move storage interfaces from ole32
coml2: Move filelockbytes from ole32
coml2: Move IPropertyStorage implementation from ole32
ole32: Prepare for moving IPropertyStorage implementation
coml2: Move stream and block logic from ole32
coml2: Move stg_stream.c from ole32
coml2: Move IEnumSTATSTG from ole32
ole32: Refactor IEnumSTATSTGImpl_Construct to prepare for movement to coml2
coml2: Move StgCreatePropSetStg from ole32
coml2: Move StgIsStorageILockBytes from ole32
coml2: Move WriteClassStg from ole32
coml2: Move ReadClassStg from ole32
coml2: Move StgIsStorageFile from ole32
coml2: Move WriteClassStm from ole32
coml2: Move ReadClassStm from ole32
coml2: Move GetConvertStg from ole32
coml2: Add dll and move code from ole32/memlockbytes.c
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3106
If explicit_handle is defined in the *.idl file, c/s are uses explicit handles,
then an explicit handle must be passed in to the server-side interface
Add a test for explicit_handle.
v3.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4467
I have a shortcut to change input language - Shift+Alt_L, and it interprets this Shift like it's CAPS on.
Only pressing shift again reverts to lower-case.

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4455#note_54743
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v9: server: Check wineserver privileges on init with -20 niceness.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
push_dc_driver() places drivers based on their priorities, so the newly created driver is not
necessary on top. Thus in windrv_CreateDC(), find_dc_driver() should be used to find the dib
driver instead of assuming the dib driver is the top driver, which could be the path driver because
it has a higher priority.
--
v3: win32u: Find the correct DIB driver in windrv_CreateDC().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4374
Along with !4450, this fixes WMV videos in microkiri (https://bugs.winehq.org/show_bug.cgi?id=9127#c102) and Wagamama High Spec Trial Edition (https://wagahigh.com/download_trial.php#normal ; ダウンロード means download).
--
v8: wmvcore/tests: Add tests for compressed output.
winegstreamer: Implement compressed output support in WMSyncReader.
winegstreamer: Leave pts/duration unchanged if they're not set.
winegstreamer: Introduce mutex for wm_reader read_thread_shutdown and wg_parser.
winegstreamer: Move file size to struct wm_reader.
winegstreamer: Fill in a few more pieces of WMV format handling.
winegstreamer: Add codec_data to WMVs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v8: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
ntdll: Set RLIMIT_NICE to its hard limit.
server: Introduce new set_thread_priority helper.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v6: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
ntdll: Set RLIMIT_NICE to its hard limit.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v7: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v5: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
On Fri Dec 1 17:22:55 2023 +0000, Nikolay Sivov wrote:
> @DarkShadow44, sorry for confusion, turns out it's not either -import or
> a forward. You can also simply have no forward and no -import, and it
> still does the right thing. Please update to remove forwarding to coml2.
Oh I see, I didn't know that was possible. Sorry for that, and thanks for your patience!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4507#note_54601
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v4: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
ntdll: Set RLIMIT_NICE to its hard limit and inform the server.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
On Thu Nov 30 22:00:38 2023 +0000, Zebediah Figura wrote:
> This cast should be unnecessary. I'd also make this an ERR or FIXME.
My thinking was that uint32_t is unsigned long, so it needs a cast.
But you're right, that's wrong. This is Unix side code, so uint32_t is not unsigned long. Fixed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54576
On Thu Nov 30 22:00:39 2023 +0000, Zebediah Figura wrote:
> I don't like this pattern; in cases like this we should instead just
> split up the init_stream() helper to the part that's done on
> initialization and the part that's done on recreation. That said I would
> imagine more of this should be done on initialization...?
They're a bit intertwined; reader->streams can't be allocated before stream_count is known, which requires creating the wg_parser.
But yes, creating the reader from two places is cleaner than these conditionals, even if it's a few more lines of code.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54577
On Thu Nov 30 22:00:44 2023 +0000, Zebediah Figura wrote:
> "if (x) ok(0)" should almost always be "ok(!x)".
It does more than just ok(0). I did it like this to ensure that everything is in order except exactly one unexpected rewind.
Would you prefer if I just tell the tests to explicitly rewind the stream when changing compression mode? [As mentioned in wm_reader.c](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winegst…, no plausible program reconfigures streams dynamically anyways.
Always hard to know which tests are important, and which are safe to relax...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54578
On Thu Nov 30 22:00:46 2023 +0000, Zebediah Figura wrote:
> I don't think you need the if (winetest_platform_is_wine) here.
Native doesn't rewind anything when the stream is switched to or from compressed mode.
I could remove it, and the ok(!callback->todo_rewind) below, but then we won't notice if someone fixes the rewinding and the todo_rewind stuff becomes unnecessary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54579
On Thu Nov 30 22:00:40 2023 +0000, Zebediah Figura wrote:
> This seems unrelated, and what's the motivation?
The motivation is the todo_wine ok(sample_duration == 460000) in the test. If has_duration is false, duration is uninitialized, and occasionally equal to 460000. Making the write conditional allows me to set duration to 1234 in the caller, which is guaranteed not equal to 10000 or 460000.
Unrelated, good point. I'll split it to a separate commit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54580
On Thu Nov 30 22:00:39 2023 +0000, Zebediah Figura wrote:
> This is ugly. Either we should explicitly block the read thread, or shut
> it down and restart it. The latter is probably simpler.
Recreating the thread throws approximately 99999 test failures about being called from wrong thread. Should I throw some todo_wine or something at them instead? Some of those tests feel kinda overzealous.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54575
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v3: server: Check wineserver privileges on init with -20
server: Use setpriority to update thread niceness when safe.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
--
v4: wined3d: Set d3d 1-9 textures in the state as SRVs.
d3d9: Use wined3d_texture_acquire_identity_srv().
wined3d: Introduce an API for creating an identity SRV on a texture.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4436
The tests show that the first argument must not be null, that the handle
returned via the fourth argument is not an HTHEME, and that that handle
can be passed to CloseThemeFile without error.
--
v2: uxtheme/tests: Add some tests for OpenThemeFile.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4531
Overwatch 2 doesn't like the win32u `-syscall` conversion that happened a while back, because it hooks KiUserCallbackDispatcher. This MR fixes it up to match what Overwatch 2 expects.
--
v3: ntdll: Pass KiUserCallbackDispatcher parameters on stack.
ntdll: Add 5-byte nop to start of KiUserCallbackDispatcher.
ntdll: Align stack pointer when calling KiUserCallbackDispatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1152
This fixes the layout of the tabcontrol when a font other than the
system font is used.
--
v3: comctl32: Modify test_width to try different fonts
comctl32: Fix tabcontrol tests to work with different fonts
comctl32: Use selected font to determine default min tab width
https://gitlab.winehq.org/wine/wine/-/merge_requests/4484
I don't know why this was merged. A stub doesn't help here, now it will just silently exit. It needs an implementation.
You should test applications to see if a stub actually helps before sending in an MR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4555#note_54521
An anticheat assumes some specific layout of KiUserExceptionDispatcher (in an 64 bit app). After checking two bytes (obviously instruction opcode) at (KiUserExceptionDispatcher + 1), it extracts memory address from this instruction and places its hook function address at that address, expecting that to be called on CPU exceptions (but not software raised exceptions).
I tried to make something out of it so supporting this mechanics is not completely artificial and fits into our implementation. I don't know if that hook has really something to do with wow64 in Windows implementation (while I guess that's possible), but it seems to me in our implementation doing it this way is a bit more straightforward. Specifically, it seems to me a bit easier to follow when a single function (KiUserExceptionDispatcher) doesn't mix different unwind models (while having the same runtime function info).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4290
When running wineserver under valgrind there is a bunch of uninitialised bytes warnings when sending the req_get_mapping_info reply.
This warning can easily be reproduced by running `valgrind wineserver -f` and then `winecfg`.
Tested using self compiled wine.
Reason is the `pe_image_info_t` struct having bitfields:
```
unsigned char contains_code : 1;
unsigned char wine_builtin : 1;
unsigned char wine_fakedll : 1;
```
The last 5 bits are never initialized. This MR fixes this by zeroing the entire struct before it is filled.
I hope "issues" like this are allowed to be fixed so valgrind has less false positives.
Valgrind message for reference:
```
==628662== 716 errors in context 3 of 3:
==628662== Syscall param writev(vector[1]) points to uninitialised byte(s)
==628662== at 0x49C3A87: writev (writev.c:26)
==628662== by 0x14C2F3: send_reply (request.c:268)
==628662== by 0x14C50F: call_req_handler (request.c:316)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Address 0x53ec56e is 62 bytes inside a block of size 88 alloc'd
==628662== at 0x48416D4: malloc (vg_replace_malloc.c:431)
==628662== by 0x1348D0: mem_alloc (object.c:119)
==628662== by 0x14BEB9: set_reply_data_size (request.c:160)
==628662== by 0x1301C1: req_get_mapping_info (mapping.c:1291)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Uninitialised value was created by a client request
==628662== at 0x134873: mark_block_uninitialized (object.c:110)
==628662== by 0x1348EA: mem_alloc (object.c:120)
==628662== by 0x134B87: alloc_object (object.c:199)
==628662== by 0x134F92: create_named_object (object.c:337)
==628662== by 0x12F12B: create_mapping (mapping.c:939)
==628662== by 0x12FFE9: req_create_mapping (mapping.c:1250)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
```
--
v3: server: Fully initialize pe mapping struct to avoid uninitialized memory when sending req_get_mapping_info reply (valgrind)
https://gitlab.winehq.org/wine/wine/-/merge_requests/4414