-> ######################################################
->
-> Applying your own linux-5.7 patch /mnt/BigData/linux-tkg/linux57-tkg/workingset_protection.mypatch
->
-> ######################################################
patching file mm/vmscan.c
Hunk #1 succeeded at 2201 (offset -11 lines).
patching file include/linux/swap.h
Hunk #1 succeeded at 344 (offset -9 lines).
patching file kernel/events/uprobes.c
Hunk #1 succeeded at 190 (offset 6 lines).
patching file mm/huge_memory.c
Hunk #1 succeeded at 646 (offset 6 lines).
patching file mm/khugepaged.c
Hunk #1 succeeded at 1089 (offset -84 lines).
patching file mm/memory.c
Hunk #1 succeeded at 2745 (offset 34 lines).
Hunk #2 succeeded at 3279 (offset 19 lines).
Hunk #3 succeeded at 3426 (offset 19 lines).
Hunk #4 succeeded at 3688 (offset 23 lines).
patching file mm/migrate.c
Hunk #1 succeeded at 2834 with fuzz 2 (offset -22 lines).
patching file mm/swap.c
Hunk #1 succeeded at 448 with fuzz 1 (offset -28 lines).
patching file mm/swapfile.c
Hunk #1 succeeded at 1888 (offset -32 lines).
patching file mm/userfaultfd.c
Hunk #1 succeeded at 125 (offset 2 lines).
patching file mm/vmscan.c
Hunk #1 succeeded at 996 (offset -7 lines).
Hunk #2 succeeded at 1018 (offset -7 lines).
patching file include/linux/mmzone.h
Hunk #2 succeeded at 273 (offset 8 lines).
patching file mm/memcontrol.c
Hunk #1 succeeded at 1447 (offset 22 lines).
patching file mm/vmscan.c
Hunk #1 succeeded at 2701 (offset 6 lines).
Hunk #2 succeeded at 2715 (offset 6 lines).
Hunk #3 succeeded at 2993 (offset 6 lines).
patching file mm/vmstat.c
Hunk #1 succeeded at 1164 (offset 15 lines).
patching file mm/workingset.c
Hunk #2 succeeded at 275 (offset -6 lines).
Hunk #3 succeeded at 343 (offset -5 lines).
Hunk #4 succeeded at 355 (offset -11 lines).
patching file include/linux/swap.h
Hunk #1 succeeded at 407 (offset -9 lines).
Hunk #2 succeeded at 567 (offset -8 lines).
Hunk #3 succeeded at 581 (offset -8 lines).
patching file mm/shmem.c
Hunk #1 succeeded at 1358 (offset -16 lines).
patching file mm/swap_state.c
Hunk #1 succeeded at 111 (offset 1 line).
Hunk #2 succeeded at 135 (offset 1 line).
Hunk #3 succeeded at 165 (offset 1 line).
Hunk #4 succeeded at 178 (offset 1 line).
Hunk #5 succeeded at 222 (offset 1 line).
Hunk #6 succeeded at 260 (offset 1 line).
Hunk #7 succeeded at 462 (offset -11 lines).
patching file mm/swapfile.c
Hunk #1 succeeded at 702 (offset 6 lines).
Hunk #2 succeeded at 728 with fuzz 1 (offset 6 lines).
patching file mm/vmscan.c
Hunk #1 succeeded at 895 with fuzz 1 (offset -6 lines).
patching file include/linux/swap.h
Hunk #1 succeeded at 407 (offset -9 lines).
Hunk #2 succeeded at 567 (offset -9 lines).
patching file mm/memory.c
Hunk #1 succeeded at 3127 (offset 33 lines).
patching file mm/swap_state.c
Hunk #1 succeeded at 107 (offset 1 line).
Hunk #2 succeeded at 421 (offset 2 lines).
Hunk #3 succeeded at 477 (offset -11 lines).
patching file mm/vmscan.c
Hunk #1 succeeded at 853 (offset -6 lines).
Hunk #2 FAILED at 902.
1 out of 2 hunks FAILED -- saving rejects to file mm/vmscan.c.rej
patching file mm/workingset.c
Hunk #1 succeeded at 348 (offset -5 lines).
patching file mm/vmscan.c
Hunk #1 succeeded at 2200 (offset -11 lines).
==> ERROR: A failure occurred in prepare().
Aborting...
-> exit cleanup done

Error when building wine-staging 5.13.r0.

It's start here:

Applying your own patch guy1524_mfplat_WIP.mypatch
patching file dlls/mf/tests/mf.c
Reversed (or previously applied) patch detected!  Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file dlls/mf/tests/mf.c.rej
patching file dlls/mf/tests/mf.c
Hunk #1 succeeded at 1392 (offset 89 lines).
Hunk #2 succeeded at 1672 (offset 91 lines).
Hunk #3 succeeded at 1701 (offset 91 lines).
patching file dlls/mf/tests/mf.c
Hunk #1 succeeded at 1572 (offset 89 lines).
Hunk #2 succeeded at 1616 (offset 89 lines).
Hunk #3 succeeded at 1641 (offset 89 lines).
patching file dlls/mf/topology.c
Hunk #1 FAILED at 1913.
1 out of 1 hunk FAILED -- saving rejects to file dlls/mf/topology.c.rej

And more erros here:

patching file dlls/mf/topology.c
Hunk #1 FAILED at 2006.
Hunk #2 FAILED at 2145.
2 out of 2 hunks FAILED -- saving rejects to file dlls/mf/topology.c.rej
patching file dlls/mf/topology.c
Hunk #1 FAILED at 1928.
Hunk #2 FAILED at 2064.
Hunk #3 FAILED at 2117.
Hunk #4 FAILED at 2134.
Hunk #5 FAILED at 2145.
5 out of 5 hunks FAILED -- saving rejects to file dlls/mf/topology.c.rej

Log: prepare.log

not working

https://github.com/Frogging-Family/community-patches/blob/master/wine-tkg-git/ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch

relevant files in ValveSoftware/Proton#170 (comment)

new working patch
ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch.txt

tested with latest wine-tkg-git, and latest "skse64_2_00_19.7z"

Cannot find isl library name. GDB bindings not installed.
/usr/bin/mkdir -p '/tmp/mostlyportable-gcc/include/isl'
/usr/bin/install -c -m 644 include/isl/stdint.h '/tmp/mostlyportable-gcc/include/isl'
/usr/bin/mkdir -p '/tmp/mostlyportable-gcc/lib/pkgconfig'
/usr/bin/install -c -m 644 isl.pc '/tmp/mostlyportable-gcc/lib/pkgconfig'
/usr/bin/mkdir -p '/tmp/mostlyportable-gcc/include/isl'
/usr/bin/install -c -m 644 include/isl/cpp.h include/isl/val_gmp.h include/isl/aff.h include/isl/aff_type.h include/isl/arg.h include/isl/ast.h include/isl/ast_type.h include/isl/ast_build.h include/isl/constraint.h include/isl/ctx.h include/isl/fixed_box.h include/isl/flow.h include/isl/id.h include/isl/id_type.h include/isl/id_to_ast_expr.h include/isl/id_to_id.h include/isl/id_to_pw_aff.h include/isl/ilp.h include/isl/hash.h include/isl/hmap.h include/isl/hmap_templ.c include/isl/list.h include/isl/local_space.h include/isl/lp.h include/isl/mat.h include/isl/map.h include/isl/map_to_basic_set.h include/isl/map_type.h include/isl/maybe.h include/isl/maybe_ast_expr.h include/isl/maybe_basic_set.h include/isl/maybe_id.h include/isl/maybe_pw_aff.h include/isl/maybe_templ.h include/isl/multi.h include/isl/obj.h include/isl/options.h include/isl/point.h include/isl/polynomial.h include/isl/polynomial_type.h '/tmp/mostlyportable-gcc/include/isl'
/usr/bin/install -c -m 644 include/isl/printer.h include/isl/printer_type.h include/isl/schedule.h include/isl/schedule_node.h include/isl/schedule_type.h include/isl/set.h include/isl/set_type.h include/isl/space.h include/isl/space_type.h include/isl/stream.h include/isl/stride_info.h include/isl/union_map.h include/isl/union_map_type.h include/isl/union_set.h include/isl/union_set_type.h include/isl/val.h include/isl/val_type.h include/isl/vec.h include/isl/version.h include/isl/vertices.h '/tmp/mostlyportable-gcc/include/isl'
make[3]: Leaving directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1'
make[2]: Leaving directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1'
Making install in doc
make[2]: Entering directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1/doc'
make[3]: Entering directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1/doc'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1/doc'
make[2]: Leaving directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1/doc'
make[1]: Leaving directory '/mnt/BigData/mostlyportable-gcc/build/isl-0.22.1'
./mostlyportable-gcc.sh: line 578: cd: /mnt/BigData/mostlyportable-gcc/build/binutils-: No such file or directory

Would it be possible to integrate the fix into the normal wine version so that it is no longer needed to to apply the patch manually or install a separated patched version just for Roblox (which is a security risk if a binary wine version ist installed from any server)?

Patch:

https://github.com/Frogging-Family/community-patches/blob/master/wine-tkg-git/roblox_mouse_fix-fshack.mypatch

This appears wrong:

+compress-$(CONFIG_INITRAMFS_COMPRESSION_LZ4)   := zstd

Perhaps that variable should end with _ZSTD?

-> Found 1 userpatches for linux-5.6:
/mnt/BigData/linux-tkg/linux56-tkg/i915.mypatch
Do you want to install it/them? - Be careful with that ;)

N/y : y
-> ######################################################
->
-> Applying your own linux-5.6 patch /mnt/BigData/linux-tkg/linux56-tkg/i915.mypatch
->
-> ######################################################
patching file include/linux/pm_qos.h
Hunk #1 succeeded at 30 (offset 2 lines).
Hunk #2 succeeded at 160 with fuzz 2 (offset -3 lines).
patching file include/trace/events/power.h
Hunk #1 FAILED at 359.
1 out of 1 hunk FAILED -- saving rejects to file include/trace/events/power.h.rej
patching file kernel/power/qos.c
Hunk #1 FAILED at 271.
Hunk #2 FAILED at 297.
Hunk #3 FAILED at 323.
Hunk #4 succeeded at 651 with fuzz 2 (offset 227 lines).
3 out of 4 hunks FAILED -- saving rejects to file kernel/power/qos.c.rej
patching file drivers/gpu/drm/i915/gt/intel_engine_cs.c
Hunk #1 succeeded at 485 (offset -19 lines).
patching file drivers/gpu/drm/i915/gt/intel_engine_types.h
Hunk #1 succeeded at 256 (offset -10 lines).
patching file drivers/gpu/drm/i915/gt/intel_gt_pm.c
patching file drivers/gpu/drm/i915/gt/intel_gt_pm.h
patching file drivers/gpu/drm/i915/gt/intel_gt_types.h
patching file drivers/gpu/drm/i915/gt/intel_lrc.c
Hunk #1 succeeded at 1505 (offset -72 lines).
Hunk #2 succeeded at 2140 (offset -78 lines).
Hunk #3 succeeded at 2325 (offset -72 lines).
patching file drivers/gpu/drm/i915/i915_debugfs.c
Hunk #1 succeeded at 2210 with fuzz 2 (offset 465 lines).
Hunk #2 FAILED at 2456.
1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_debugfs.c.rej
patching file drivers/cpufreq/intel_pstate.c
Hunk #3 succeeded at 1879 (offset -1 lines).
Hunk #4 succeeded at 1890 (offset -1 lines).
Hunk #5 succeeded at 1901 (offset -1 lines).
Hunk #6 succeeded at 1912 (offset -1 lines).
Hunk #7 succeeded at 2019 (offset -1 lines).
Hunk #8 succeeded at 2588 (offset -1 lines).
Hunk #9 succeeded at 2755 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #8 succeeded at 1861 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #4 succeeded at 1898 (offset -1 lines).
Hunk #5 succeeded at 2026 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 1904 (offset -1 lines).
Hunk #2 succeeded at 2235 (offset -1 lines).
Hunk #3 succeeded at 2313 (offset -1 lines).
Hunk #4 succeeded at 2458 (offset -1 lines).
Hunk #5 succeeded at 2470 (offset -1 lines).
Hunk #6 succeeded at 2599 (offset -1 lines).
patching file Documentation/admin-guide/kernel-parameters.txt
Hunk #1 succeeded at 1829 (offset 1 line).
patching file Documentation/admin-guide/pm/intel_pstate.rst
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 3028 (offset -1 lines).
Hunk #2 succeeded at 3193 (offset -1 lines).
Hunk #3 succeeded at 3201 (offset -1 lines).
Hunk #4 succeeded at 3226 (offset -1 lines).
Hunk #5 succeeded at 3318 (offset 1 line).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 2232 (offset -1 lines).
Hunk #2 succeeded at 2273 (offset -1 lines).
Hunk #3 succeeded at 2783 (offset -1 lines).
patching file include/trace/events/power.h
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 1029 (offset -1 lines).
Hunk #2 succeeded at 3057 (offset -1 lines).
Hunk #3 succeeded at 3067 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 2462 (offset -1 lines).
Hunk #2 succeeded at 2495 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 1940 (offset -1 lines).
Hunk #2 succeeded at 2306 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 2298 (offset -1 lines).
Hunk #2 succeeded at 2397 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #6 succeeded at 1076 (offset -1 lines).
Hunk #7 succeeded at 2002 (offset -1 lines).
Hunk #8 succeeded at 2076 (offset -1 lines).
Hunk #9 succeeded at 2162 (offset -1 lines).
Hunk #10 succeeded at 2187 (offset -1 lines).
Hunk #11 succeeded at 2197 (offset -1 lines).
Hunk #12 succeeded at 2242 (offset -1 lines).
Hunk #13 succeeded at 2273 (offset -1 lines).
Hunk #14 succeeded at 2334 (offset -1 lines).
Hunk #15 succeeded at 2346 (offset -1 lines).
Hunk #16 succeeded at 2357 (offset -1 lines).
patching file drivers/cpufreq/intel_pstate.c
Hunk #1 succeeded at 1086 (offset -1 lines).
Hunk #2 succeeded at 1096 (offset -1 lines).
Hunk #3 succeeded at 2523 (offset -1 lines).
Hunk #4 succeeded at 2686 (offset -1 lines).
Hunk #5 succeeded at 3456 (offset -1 lines).
Hunk #6 succeeded at 3484 (offset -1 lines).
==> ERROR: A failure occurred in prepare().
Aborting...

patching file src/dxvk/hud/dxvk_hud_renderer.cpp
Hunk #2 succeeded at 19 (offset 1 line).
Hunk #3 succeeded at 42 with fuzz 2 (offset 1 line).
Hunk #4 succeeded at 93 with fuzz 2 (offset 4 lines).
patching file src/dxvk/hud/dxvk_hud_renderer.h
Hunk #2 FAILED at 88.
Hunk #3 succeeded at 149 (offset 18 lines).
1 out of 3 hunks FAILED -- saving rejects to file src/dxvk/hud/dxvk_hud_renderer.h.rej

When attempting to apply the GMEM_MOVEABLE patch to the latest wine-staging the patch fails to apply

Applying your own patch kernel32-implement-Windows-NT-style-GMEM_MOVEABLE-LM-staging.mypatch
patching file dlls/kernel32/heap.c
Hunk #1 succeeded at 155 (offset -57 lines).
Hunk #2 succeeded at 225 (offset -57 lines).
Hunk #3 succeeded at 239 (offset -57 lines).
Hunk #4 succeeded at 318 (offset -57 lines).
Hunk #5 FAILED at 387.
Hunk #6 FAILED at 398.
Hunk #7 succeeded at 416 (offset -57 lines).
Hunk #8 succeeded at 426 (offset -57 lines).
2 out of 8 hunks FAILED -- saving rejects to file dlls/kernel32/heap.c.rej
patching file dlls/kernel32/tests/heap.c
Hunk #1 succeeded at 334 (offset -3 lines).
patching file dlls/kernelbase/kernelbase.spec
Hunk #1 succeeded at 1777 (offset 8 lines).
patching file dlls/kernelbase/memory.c
Hunk #1 succeeded at 537 (offset 152 lines).
Hunk #2 succeeded at 703 (offset 152 lines).
Hunk #3 succeeded at 758 (offset 152 lines).
Hunk #4 succeeded at 898 (offset 165 lines).
Hunk #5 succeeded at 950 (offset 165 lines).
patching file include/winbase.h
Hunk #1 succeeded at 2919 with fuzz 2 (offset 4 lines).

kernel32-implement-Windows-NT-style-GMEM_MOVEABLE-LM-no-staging.mypatch is failing to apply on Wine 7.6 (mainline, obviously). Here's the prepare.log contents:

Applying your own patch kernel32-implement-Windows-NT-style-GMEM_MOVEABLE-LM-no-staging.mypatch
patching file dlls/kernel32/heap.c
Hunk #1 FAILED at 156.
Hunk #2 FAILED at 238.
Hunk #3 FAILED at 252.
Hunk #4 FAILED at 321.
Hunk #5 FAILED at 333.
Hunk #6 FAILED at 344.
Hunk #7 FAILED at 419.
Hunk #8 FAILED at 429.
8 out of 8 hunks FAILED -- saving rejects to file dlls/kernel32/heap.c.rej
patching file dlls/kernel32/tests/heap.c
Hunk #1 FAILED at 334.
1 out of 1 hunk FAILED -- saving rejects to file dlls/kernel32/tests/heap.c.rej
patching file dlls/kernelbase/kernelbase.spec
Hunk #1 succeeded at 1807 (offset 37 lines).
patching file dlls/kernelbase/memory.c
Hunk #1 FAILED at 521.
Hunk #2 FAILED at 611.
Hunk #3 FAILED at 655.
Hunk #4 FAILED at 790.
Hunk #5 FAILED at 816.
5 out of 5 hunks FAILED -- saving rejects to file dlls/kernelbase/memory.c.rej
patching file include/winbase.h
Hunk #1 succeeded at 2930 with fuzz 2 (offset 20 lines).

ValveSoftware/Proton#350 (comment)
AlexeyProkhin/wine@99e882a

Would love to see one included in user patches.

wine-tkg-staging.log

The patch doesn't apply on newer version of protonify wine-staging (v6.19).

Applying your own patch legoisland_168726.mypatch
patching file dlls/ddraw/ddraw_private.h
Hunk #1 succeeded at 344 (offset 18 lines).
Hunk #2 succeeded at 581 (offset 18 lines).
patching file dlls/ddraw/device.c
Hunk #1 succeeded at 351 (offset 45 lines).
Hunk #2 succeeded at 765 (offset 45 lines).
Hunk #3 succeeded at 1032 (offset 45 lines).
Hunk #4 succeeded at 1077 (offset 45 lines).
Hunk #5 succeeded at 7109 with fuzz 2 (offset 72 lines).
patching file dlls/ddraw/executebuffer.c
Hunk #3 succeeded at 212 (offset 2 lines).
Hunk #4 succeeded at 290 (offset 1 line).
Hunk #5 FAILED at 360.
1 out of 5 hunks FAILED -- saving rejects to file dlls/ddraw/executebuffer.c.rej
patching file dlls/ddraw/tests/ddraw1.c
Hunk #1 succeeded at 14448 (offset 1383 lines).
Hunk #2 succeeded at 14683 with fuzz 2 (offset 1383 lines).

I also provide the patch for legoisland_168726.mypatch to fix this issue.

legoisland_168726.mypatch.zip

The PATCH-RFC-x86-mm-pat-Restore-large-pages-after-fragmentation.mypatch and zstd.mypatch patches are still valid and work with 5.10.

Thus I suggest copying them from the linux59-tkg community patches to the linux510-tkg community-patches. (sorry for not being familiar on how to do this as a pull request)

So I was building a new Proton for MK11 and I went to apply the gamepad patch, and it failed. I checked prepare.log, and this was what I saw:

Applying your own patch mk11-gamepad-fix.mypatch
patching file dlls/wbemprox/class.c
Hunk #1 succeeded at 411 with fuzz 2 (offset 295 lines).
Hunk #2 FAILED at 125.
1 out of 2 hunks FAILED -- saving rejects to file dlls/wbemprox/class.c.rej

Offending code:

     *puReturned = 0;
-    if (ec->index >= view->result_count) return WBEM_S_FALSE;
-
-    table = get_view_table( view, ec->index );
-    hr = create_class_object( table->name, iface, ec->index, NULL, apObjects );
-    if (hr != S_OK) return hr;
-
-    ec->index++;
-    *puReturned = 1;
-    if (ec->index == view->result_count && uCount > 1) return WBEM_S_FALSE;
-    if (uCount > 1) return WBEM_S_TIMEDOUT;
+
+    for (i=0; i<uCount; ++i)
+    {
+        if (ec->index >= view->result_count) return WBEM_S_FALSE;
+        table = get_view_table( view, ec->index );
+        hr = create_class_object( table->name, iface, ec->index, NULL, apObjects );
+        if (hr != S_OK) return hr;
+
+        apObjects++;
+        ec->index++;
+        ++*puReturned;
+    }
     return WBEM_S_NO_ERROR;
 }

Which is the second of the two parts of the patch. looking in dlls/wbemprox/class.c, there is almost identical code in that spot:

    if (lTimeout != WBEM_INFINITE && !once++) FIXME("timeout not supported\n");

    *puReturned = 0;

    for (i = 0; i < uCount; i++)
    {
        if (ec->index >= view->result_count) return WBEM_S_FALSE;
        table = get_view_table( view, ec->index );
        hr = create_class_object( table->name, iface, ec->index, NULL, &apObjects[i] );
        if (hr != S_OK)
        {
            for (j = 0; j < i; j++) IWbemClassObject_Release( apObjects[j] );
            return hr;
        }
        ec->index++;
        (*puReturned)++;
    }

    return WBEM_S_NO_ERROR;
}

There are a couple formatting changes and some I-don't-know-if-they're-consequential-but-I'm-sure-you-will extremely minor tweaks that might also just be formatting, but yeah. Figured I'd let you know so you could just chop that part out or whatever else is appropriate, I removed the offending half of the patch and am running the build again, will report if the gamepad works, or doesn't (assuming MK11 actually works for me lol). I didn't want to file a PR because for 1 I'm sure you're sleeping at this time of night in France and 2, I don't know if you even want to just remove that part of the patch. Trying not to create unnecessary hassle for you.

I am running this new patch, with amd-pstate as kernel built-in, but I have this:

➜  ~ cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 2.20 GHz - 5.08 GHz
  available frequency steps:  3.40 GHz, 2.80 GHz, 2.20 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 2.20 GHz and 3.40 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.92 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: no

When looking at the patch messages, this is mentioned:

In some of Zen2 and Zen3 based processors, they are using the shared
memory that exposed from ACPI SBIOS. In this kind of the processors,
there is no MSR support, so we add acpi cppc function as the backend for
them.

It is using a module param (shared_mem) to enable related processors
manually. We will enable this by default once we address performance
issue on this solution.

and this

/* TODO: We need more time to fine tune processors with shared memory solution
with community together.

There are some performance drops on the CPU benchmarks which reports from
Suse. We are co-working with them to fine tune the shared memory solution. So
we disable it by default to go acpi-cpufreq on these processors and add a
module parameter to be able to enable it manually for debugging.
*/

static bool shared_mem = false;
module_param(shared_mem, bool, 0444);
MODULE_PARM_DESC(shared_mem,
                 "enable amd-pstate on processors with shared memory solution (false = disabled (default), true = enabled)");

Is this the case for a 5950X ?

patching file dlls/ddraw/ddraw_private.h
Hunk #1 succeeded at 335 (offset 9 lines).
Hunk #2 succeeded at 572 (offset 9 lines).
patching file dlls/ddraw/device.c
Hunk #1 succeeded at 344 (offset 38 lines).
Hunk #2 succeeded at 758 (offset 38 lines).
Hunk #3 succeeded at 1025 (offset 38 lines).
Hunk #4 succeeded at 1070 (offset 38 lines).
Hunk #5 succeeded at 7046 with fuzz 2 (offset 9 lines).
patching file dlls/ddraw/executebuffer.c
Hunk #3 succeeded at 211 (offset 1 line).
Hunk #5 succeeded at 360 with fuzz 1.
patching file dlls/ddraw/tests/ddraw1.c
Hunk #1 succeeded at 13369 (offset 304 lines).
Hunk #2 FAILED at 13300.
1 out of 2 hunks FAILED -- saving rejects to file dlls/ddraw/tests/ddraw1.c.rej

-> ######################################################
->
-> Applying your own mesa patch /mnt/BigData/mesa-git/VK_JOSH_depth_bias_info_radv.mymesapatch
->
-> ######################################################
patching file src/amd/vulkan/radv_cmd_buffer.c
Hunk #1 succeeded at 1312 (offset 88 lines).
Hunk #2 succeeded at 1584 with fuzz 2 (offset 108 lines).
patching file src/amd/vulkan/radv_device.c
Hunk #1 succeeded at 1352 with fuzz 1 (offset 364 lines).
patching file src/amd/vulkan/radv_extensions.py
Hunk #1 succeeded at 184 with fuzz 2 (offset 39 lines).
patching file src/amd/vulkan/radv_pipeline.c
Hunk #1 succeeded at 5184 (offset 869 lines).
patching file src/amd/vulkan/radv_private.h
Hunk #1 FAILED at 1452.
1 out of 1 hunk FAILED -- saving rejects to file src/amd/vulkan/radv_private.h.rej
==> ERROR: A failure occurred in prepare().
Aborting...
-> Cleanup done

FSR2 was open-sourced some time ago, supposedly; would be nice to have a patch for that for Wine to see how it compares to FSR1

NOTE: While I was typing this, wine-staging itself got updated and rebased against 7.0-rc1 so everything is broken right now, but amd_fsr_hack still needs to be rebased, so I'm still filing this anyway

I was trying to build in my usual wine-tkg-git repo directory, and it kept failing wine winevulkan errors. So I did a fresh git clone, built with defaults, and it built fine. I started removing stuff one by one, and figured out that amd_fsr_fshack.mypatch in _community_patches= was the culprit. It applies fine, but it causes a build failure.

There have been a ton of winevulkan commits in upstream wine, so that's probably why. I haven't had the time to bisect which upstream commit breaks it, but I'll try to get on that asap.

On a similar note, if it wouldn't be too difficult, I think wine-tkg-userpatches (or the build script in general) should be modified to allow for either:

• using both _plain_version= and _staging_version= on staging builds. I am unable to easily bisect which plain wine commit broke FSR because fshack isn't allowed on plain wine builds, and you can't specify _plain_version on staging builds. But since there have been several winevulkan commits to plain wine in between the working and broken staging commits, it's impossible for me to find out which one broke it (at least not without a huge amount of hassle).

• being able to patch the plain wine tree with wine-tkg-userpatches before the wine-staging patches get applied. I used git format-patch to create patches to revert the 3 commits I suspected, but none of them would apply when placed in wine-tkg-userpatches because they could only be applied after the staging and hotfixer stuff, which meant that they could no longer cleanly apply.

I hope either of those suggestions at least make sense as to what I'm actually asking.

But anyway, yeah somewhere between staging commits 2653c32 and 155e98e, the FSR patch got brokeded and won't apply.

Obviously I know that your priority will probably be fixing the script and hotfixer for 7.0-rc1 since now you can't build anything targeting current wine-staging, but still, just wanted to make the report.

Quick port of the winex11-fs-no_above_state.mypatch for plain wine. Not sure if needed. Not sure if necessary, but that is your prerogative.

It compiles, it didn't break any of the games I run and it seems to function fine so the very least it seems to be harmless.

0000-noabovestate.zip

The subpatch "[PATCH 17/18] ntdll: Unroll memset instead of preventing optimization" conflict with "[PATCH 2/2] ntdll: Use the unrolled memset from msvcrt." From mainline. Removing this subpatch allow the patch to apply.

Today, due to a roblox update, some users of the grapejuice wrapper have reported that they have a FFlag called "FFlagDetectWine", after a couple of hours of the roblox update being pushed, many MANY, grapejuice users have reported that roblox just instantly crashes on launch using wine-tkg or wine-staging, regardless of the wine version, wheter it's 6.11 or 6.14 or 6.9

There are no current logs that can be found.

My OS and renderer: Direct3D11 using DXVK, Artix Linux 64 bit.

Screenshot of roblox crashing
https://imgur.com/a/S7sZFyi

I haven't had the time to build my own custom wine-tkg build in weeks, so I'm rusty as hell at debugging issues like this but I think I found at least the direction of the problem.

Anyway, using no presets and trying to enable amd_fsr_fshack-alternative.mypatch from community-patches fails every time with prepare.log saying:

Applying your own patch amd_fsr_fshack-alternative.mypatch
patching file dlls/winevulkan/vulkan.c
Hunk #1 FAILED at 879.
Hunk #2 FAILED at 914.
2 out of 2 hunks FAILED -- saving rejects to file dlls/winevulkan/vulkan.c.rej
patching file dlls/winevulkan/make_vulkan
Hunk #1 FAILED at 3207.
1 out of 1 hunk FAILED -- saving rejects to file dlls/winevulkan/make_vulkan.rej
patching file dlls/winevulkan/vulkan.c
Hunk #1 succeeded at 1546 (offset -460 lines).
Hunk #2 succeeded at 1559 (offset -163 lines).

followed by a ton more lines reporting success.

If I remove -alternative and just try to use the original fsr patch, it applies cleanly. This is weird, because at least some of the lines that are failing are unchanged and are exactly the same in the original amd_fsr_fshack.mypatch. So that shouldn't be happening.

So I looked into it, and there has to be some hotfix or some other patch that is getting applied when the user specifies amd_fsr_fshack.mypatch in customization.cfg, but not when they specify amd_fsr_fshack-alternative.mypatch.

Both patches have this:

 --- a/dlls/winevulkan/make_vulkan
+++ b/dlls/winevulkan/make_vulkan
@@ -3207,7 +3207,7 @@ class VkGenerator(object):
         f.write("     * resolution; user_sz will contain the app's requested mode; and dst_blit\n")
         f.write("     * will contain the area to blit the user image to in real coordinates.\n")
         f.write("     * All parameters are optional. */\n")
-        f.write("    VkBool32 (*query_fs_hack)(VkSurfaceKHR surface, VkExtent2D *real_sz, VkExtent2D *user_sz, VkRect2D *dst_blit, VkFilter *filter);\n")
+        f.write("    VkBool32 (*query_fs_hack)(VkSurfaceKHR surface, VkExtent2D *real_sz, VkExtent2D *user_sz, VkRect2D *dst_blit, VkFilter *filter, BOOL *fsr, BOOL *fsr_lite, float *sharpness);\n")

None of that code is in the upstream tree (or staging), the line that's being replaced doesn't exist. Grepping recursively through all the files in the wine-tkg-git/wine-tkg-git directory for content from those lines returns a ton of results, but nothing that adds the lines in the first place, so I haven't found where they originally come from. But hopefully you know what the issue is from my description and it's an easy fix. Once I get finished with my Regolith DE port updating to version 2.0 from 1.6 (which 2.0 changed literally everything about everything, so it's a nightmare and I'm the sole maintainer for all of Arch Linux for the Regolith Linux org, ugh), I plan to get back into helping out as much as I can with you, GE, and reporting and bisecting bugs in DXVK/VKD3D/etc.

dlls/iphlpapi/icmp.c no longer exists as a file, so the patch doesn't apply. The file was deleted in 7156d2b1e4dd7be5ee6194c60afa6aafec8b2544.

Do you know how we can fix the BF4 ping issue in Proton builds now without that patch? Since _allow_wine_net_raw isn't an option in proton-tkg.cfg or proton-tkg-profiles/advanced-customization.cfg.

It seems the zstd addition to 5.9 allowing a zstd compressed kernel imaged, omitted the parts of the patch allowing the modules to be zstd compressed.

I changed zstd.mypatch from 5.8 and retained the bits and pieces needed to be able to compress the modules as well: https://pastebin.com/XHKuWR2g

It's a quick and dirty hack, I'm not sure the changes to xxhash.c are actually needed, nor have I tried out if it works with 5.10 (though it should).

When ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch is enabled, IDA Pro fail to load an existing database or to analyze a executable, terminating with an unspecified internal error.
This was tested with IDA Pro 7.2.

I am using wine-tkg-git (wine-tkg-6.14) w/DXVK on roblox on artix linux

I don't think I've ever managed to get this patch to work when switching on MODULE_COMPRESS_ZSTD.

It seems something within mkinitcpio still insists on only accepting modules with the .gz suffix, and every attempt I've made results in the same message when compiling the kernel, "No modules were added to the image. This is probably not what you want."

Compressing the kernel image with zstd works just fine, but the module compression doesn't work for me.

Hunk #1 succeeded at 591 (offset -42 lines).
Hunk #2 succeeded at 599 (offset -42 lines).
Hunk #3 FAILED at 668.
1 out of 3 hunks FAILED -- saving rejects to file dlls/mf/samplegrabber.c.rej
patching file dlls/mf/session.c
patching file dlls/mf/topology.c
patching file dlls/mf/topology.c
patching file dlls/winegstreamer/media_source.c
patching file dlls/winegstreamer/mf_decode.c
patching file dlls/winegstreamer/mfplat.c
patching file dlls/mf/samplegrabber.c
Hunk #1 FAILED at 789.
1 out of 1 hunk FAILED -- saving rejects to file dlls/mf/samplegrabber.c.rej
patching file dlls/winegstreamer/mfplat.c
patching file dlls/mfplat/tests/mfplat.c
patching file dlls/mfreadwrite/tests/mfplat.c
patching file dlls/mfreadwrite/tests/resource.rc
patching file dlls/mfplat/tests/mfplat.c
patching file dlls/mfreadwrite/tests/mfplat.c
patching file dlls/mfreadwrite/tests/resource.rc
==> ERROR: A failure occurred in prepare().
    Aborting...

Also, version 3 of The new cgroup slab memory controller patch released. https://patchwork.kernel.org/cover/11504523/

Failing to apply guy1524_mfplat_WIP.mypatch on proton-tkg. Please find the log file attached.

prepare.log

I realize an issue with amdags and msvcrt was fixed a while back, but now I'm getting this problem when I try to apply it.
../wine-mirror-git/dlls/amd_ags_x64/amd_ags_x64_main.c:2: error: system header stdbool.h cannot be used with msvcrt

Doesn't matter whether I enable or disable the msvcrt proton patch, same thing happens. Prepare.log doesn't seem to complain about it, although it does show a bunch of unhandled chain conversions for vulkan which may or may not be relevant at all.

star-citizen-StorageDeviceSeekPenaltyProperty.mypatch is not needed anymore with wine 6.20. You might want to add a comment indicating that into the README.

(Could have done so myself but I didn't want to make a pull-request for such a tiny change)

I have a Hyperkin Duke Xbox One controller that reboots every 40 seconds supposedly due to not being included properly in the current driver(?)

As for the Joy-Con support, the kernel module for it isn't available (at least) for 5.14.21-227 and a support patch for that would be appreciated.

Hi first of all i apologize if I'm doing this wrong. I'm trying to compile wine-tkg with FSR added on top but the patch fails to apply. wine-tkg by itself compiles fine.

My procedure is as follow:

• Downloaded wine-tkg source (as of commit 2b7a968)
• Placing "amd_fsr_fshack.mypatch" in Wine
• Patching file with "patch -p1 < ./amd_fsr_fshack.mypatch" command
• Error in terminal as per attached - terminal_log.txt
  source root folder

Hi frogs,

As indicated by the title, the patch need update with the last commits.
Here is the errors logs : patch_error.log

Thanks for all you've done 💯

https://github.com/varmd/wine-wayland

patches failed on linux 5.7.8

Hi, when building a wine-tkg package with the 0002-proton_LFH.mypatch community patch enabled a prefix creation hang resulting in a boot timeout.
Process state druign the hang seems to indicate the hang happens during install_mono phase.

Last lines of the log are

0078:err:winedevice:ServiceMain Failed to load L"C:\\windows\\system32\\win32k.sys"
0078:err:winedevice:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgkrnl.sys"
0078:err:winedevice:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgmms1.sys"
0024:err:environ:run_wineboot boot event wait timed out
wine: could not load kernel32.dll, status c0000135

The first 3 lines are present also on a normal wine/wine-staging

Prefix updates seems to works properly instead, at elast when a mono update isn't involved.

Hello TkG,

Like describe in the title, here is the prepare.log.

As always, thank you for everything 🐸

I received errors when trying to apply the patch using proton-tkg.sh.

It seems like this change was integrated into valve_proton_fullscreen_hack.patch last year, Tk-Glitch/PKGBUILDS@9be1dee, which I assume is enabled through _proton_fs_hack in the .cfg, so I'm wondering if it replaces the winex11_limit_resources-nmode.mypatch?

prepare.log

The workaround for the kernel bug was removed in 75bccf99d1f90555c998f2c9b907ed9292ce47f3

    Applying your own patch 0001-Add-some-semi-stubs-in-user32.mypatch
    patching file dlls/user32/sysparams.c
    Hunk #1 FAILED at 4487.
    Hunk #2 FAILED at 4527.
    Hunk #3 FAILED at 4538.
    Hunk #4 succeeded at 5045 with fuzz 1 (offset 471 lines).
    3 out of 4 hunks FAILED -- saving rejects to file dlls/user32/sysparams.c.rej

Is this still relevant?

Hi,

Hmm weird, the patch doesn't apply but it has been updated 46f6112
Here are the logs : patch_error.log

Thanks again and always

I'm going to assume its supposed to be cloned in same directory as where wine-tkg-git was cloned, but this would be very nice to have actually be written somewhere.

Hi frogs,

Here are the log : makepkg log

Thanks for the future fix again and again :D

Good afternoon Etienne, when applying the patch in Wine 5.6 exactly staging version '4370386' and plain version '5e75310' he fails with this error:

patching file tools/make_makefiles
patching file tools/makedep.c
Hunk #1 FAILED at 182.
Hunk #2 succeeded at 190 (offset 1 line).
Hunk #3 succeeded at 1373 (offset 1 line).
Hunk #5 succeeded at 4249 (offset 1 line).
1 out of 5 hunks FAILED -- saving rejects to file tools/makedep.c.rej
patching file dlls/mf/Makefile.in
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file dlls/mf/Makefile.in.rej
patching file dlls/mf/handler.c
patching file dlls/mf/handler.h
patching file dlls/mf/main.c

makedep.c.rej:
--- tools/makedep.c
+++ tools/makedep.c
@@ -182,6 +182,7 @@ struct makefile
struct strarray install_lib;
struct strarray install_dev;
struct strarray extra_targets;

• struct strarray parent_dirs;
  struct strarray extra_imports;
  struct list sources;
  struct list includes;

Makefile.in.rej:
--- dlls/mf/Makefile.in
+++ dlls/mf/Makefile.in
@@ -5,6 +5,7 @@ IMPORTS = advapi32 mfplat ole32 uuid mfuuid
EXTRADLLFLAGS = -mno-cygwin

C_SRCS = \

• handler.c
  evr.c
  main.c
  samplegrabber.c \

prepare.log

Have a good day and take care of your health, even more in this difficult time