Patchsets that need review by experienced Wine Developers
triplesquarednine at gmail.com
Fri Jan 4 11:56:19 CST 2013
>> The original patches/sources (that i have based my version on, are
>> found here: http://www.museresearch.com/support/receptor-faq.php
>> ...at the bottom of the page / last link:
>> these patches fix Wine problems (in most areas) for people using
>> linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes
>> for wine. It's Gpl'd (obviously), so it would be worthwhile to have a
>> look anyway. - didn't include every patch (some of them aren't of
>> interest to me, outdated, etc).
> I looked over them briefly.
> Not sure why this is needed?
I'm not sure why either, but i am guessing it improves things in a
linux-rt/VST setting (in fact, removing it causes regressions on my
L_pa systems - so i am keeping it.
> a user32.EnableWindow 2008 patch ... is it still needed for you,
> as quite some enhancements have happened...
> Would need review (likely from julliard or other user32 guru)
> and testcases.
Seems to be, yeah.
> A new synchronization method using UNIX pipe(2)s.
> This is definitely not going in as is...
Figured as much :) (that was pretty obvious lol.)
> It would be interesting to know what deficit in regular Wine is
> fixed by it. wineserver overhead?
Yeah, Wineserver is probably the number one thing that slows down
when, when you are looking for low-latency / high-performance. (ext4
is also terrible on stock settings).
> Remove the MUSE specific fixmes and use the same FIXME() style
> for stub parameters as in the other FIXME()s. Then
> its ready for wine-patches I would say.
Awesome :) I must have missed that ~ you will notice that i removed
them from the new variables used by L_ (didn't want any
hassles/trademark issues with Muse).
> Use same FIXME() style as used for other stub functions, then
> ready for submission.
> Good for submission as-is.
> Not submittable as-is ...
> It would be good to know the reason and/or what MUSE expects.
You can contact them. They don't seem to get the idea of FOSS - by
having our help, they could have _Less_ of a delta they are keeping.
But as far as this patch is concerned, i am not sure. (this is why i
got in touch with you guys).
> Smells like the wrong place to do it. Perhaps mountmgr.sys,
> but perhaps different.
> Also unclear if Alexandre likes it.
I think for their purposes it probably is though, so i have kept it as
well (for now, unless told that i shouldn't for good reason).
> Looks already good for submission to me.
Yeah, it fixes BIG hassles for N.I users like myself.
> Needs design and discussion... So far a RT solution
> was not accepted for Wine yet.
Yeah - that is in fact, one of the most important patches for us
(linuxaudio folks). The FSThost developer (wraps wineVSTs, single
hosted) said it is the 'holy grail' for fixing his software to
properly handle windows VSTs and it does so very well :) ~ windows
VSTs are highly performant, synchronized and run like normal
Jack_cleints without wineserver getting in the way.
> local hacks
> Seems like a mistaken patch that was needed as we had
> the old DIB sections.
> gdb would have accepted "continue" here.
> Should not be necessary anymore these days with the
Okay, i will try reverting it locally and make sure everything is good.
> Might be submittable as-is.
> Might need autoconf checks for non-Linux.
good. but i am not the guy to do this ~ i have a _ton_ of work right
now, both professionally and for my own projects. I just wanted to
make sure anything that _should_ be in wine goes into Wine to improve
the experience for everyone.
> Alexandre usually does not like override files
> like this unless necessary.
> What is actually expected? you mentioned rendering issues?
I am not sure about this one. it needs investigating but i have it
applied. As far as rendering issues, yes upstream wine causes ugly
flickering in some apps/VSTs, while L_pa-Wine does not (at all, ever).
> Hmm, needs user32 windowing guru review.
> If this is not just a hack, could be submitted as-is.
It's my hack. If using themes in wine (like windows themes) the custom
menus often don't work properly, andthe line color often is tied into
a color the user cannot change within winecfg ~ so i added a hack to
tie it into the desktop color so my themes don't look horrible.
> A Linux kernel patch? Likely wrong here.
yup. (i must have accidently added that).
I hope some of this stuff is helpful to Wine and CodeWeavers ~ I'm
just trying to be a good FOSS citizen :)
Let me know if there is anything more you need from me...
I'll keep my own on release info ~ to see when i can remove certain patches.
More information about the wine-devel