Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS_bypass_compositor.patch Fails to Apply #152

Open
gardotd426 opened this issue Nov 21, 2023 · 4 comments
Open

FS_bypass_compositor.patch Fails to Apply #152

gardotd426 opened this issue Nov 21, 2023 · 4 comments

Comments

@gardotd426
Copy link
Contributor

From prepare.log:

FS_bypass_compositor.patch -- ( Applied Fullscreen compositor bypass patch )
patching file dlls/winex11.drv/window.c
Hunk #1 FAILED at 985.
Hunk #2 succeeded at 1064 (offset 67 lines).
Hunk #3 succeeded at 1172 with fuzz 2 (offset 105 lines).
1 out of 3 hunks FAILED -- saving rejects to file dlls/winex11.drv/window.c.rej
patching file dlls/winex11.drv/x11drv.h
Hunk #1 FAILED at 444.
1 out of 1 hunk FAILED -- saving rejects to file dlls/winex11.drv/x11drv.h.rej
patching file dlls/winex11.drv/x11drv_main.c
Hunk #1 FAILED at 135.
1 out of 1 hunk FAILED -- saving rejects to file dlls/winex11.drv/x11drv_main.c.rej
@gardotd426
Copy link
Contributor Author

Hunk 1 at line 985 fails because none of what's in the patch is still in the file.

Starting at 1049, this is the closest match:

/********************************************************************>
 *     update_net_wm_states
 */
void update_net_wm_states( struct x11drv_win_data *data )
{
    UINT i, style, ex_style, new_state = 0;

    if (!data->managed) return;
    if (data->whole_window == root_window) return;

Note that the only difference is UINT i, style, ex_style, new_state = 0;, whereas in the patch, that line is DWORD i, style, ex_style, new_state = 0;

So it's literally just UINT instead of DWORD.

@gardotd426
Copy link
Contributor Author

I've got a fixed patch that applies properly, but I can't test the build because fsync_futex_waitv.patch is failing all over the place, even though I didn't enable that patch. The customization.cfg has been changed, and now it just says fsync=true or fsync=false, whereas it used to have multiple options for fsync, futex2, legacy, etc.

I just set _fsync="true" and nothing else, I don't know why the waitv patch is trying to be applied. Is that required for regular in-kernel fsync support now?

I've grepped recursively the whole repo and can't find anything useful.

Just to note I'm trying to build wine-tkg-git, using the empty template (so just my own configuration from customization.cfg and advanced-custiomization.cfg. In other words I leave PRESET empty and choose 0 when prompted during the start of ./non-makepkg-build.sh.

@gardotd426
Copy link
Contributor Author

So it seems there's been a mess-up in changes to customization.cfg.

If I add _fsync_legacy=false to my customization.cfg file, but keep _fsync="true", then that stupid patch doesn't attempt to be applied. I'll file on wine-tkg-git

@Tk-Glitch
Copy link
Member

waitv is the current implementation supported on upstream kernel. All other implementations are deprecated and abandoned, which is why the options are gone. On older trees where waitv isn't supported you'll get legacy fsync, which requires a specific additional kernel patch that isn't part of upstream (we are offering it in linux-tkg, but that's very niche).
The waitv patch should be fixed now, so feel free to test your changes out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants