winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
Hi, Johannes Kroll wrote: 9.532:003a:trace:midi:modLongData dwBufferLength=88 ! f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z. 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@... 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|. 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 01 7f f7 00 00 00 Could you please log dwBytesRecorded next to TRACE(dwBufferLength=%u !\n, lpMidiHdr-dwBufferLength); I once proved that dwBytesRecorded is what gets used with midiSTREAMout So there is an F7 there... Maybe the app expects that the driver scans through the buffer for the F7 and doesn't send the following bytes... Net.wisdom is that modLongData need be scanned for coalesced regular status messages, e.g. some people use it to play chords, arguing that one LongMsg is faster than 3 consecutive midiOutShortMsg. That's a patch yet to be written. However, I wouldn't know what to do with the three 00 bytes. That's not MIDI! Also, I'm wondering what ALSA does with that packet. Do the bytes as shown really make their way over the serial port? (Perhaps you could use some virtual MIDI device to dump what ALSA processes internally?) Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and does not require us to tell it what a sysex might be. I already tested that disguising a chord as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW synth). Thank you, Jörg Höhle
Re: [PATCH] netstat: Clarify labels in UDP statistics.
On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä lauri.ken...@gmail.com wrote: On 2013-02-09 23:15, Frédéric Delanoy wrote: Invalid Datagrams is too vague. It could mean datagrams sent or received. I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it. Yet it's what Windows uses, and is more specific, so I don't really think this should modified On 2013-02-09 23:15, Frédéric Delanoy wrote: If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating This isn't (only) a translation ambiguity issue, this is about the original texts, especially No Ports. Or are you trying to suggest that I add #msgctxt#udp_received_stats# to that Invalid Datagrams? I meant if you find a msgstr ambiguous(which is not really a problem for the No ports IMHO), you can use msgctxt so that other translators benefit as well. Frédéric
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Dmitry Timoshkov dmi...@baikal.ru writes: This patch not only fixes a todo_wine in the tests, but also makes print preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Alexandre Julliard julli...@winehq.org wrote: This patch not only fixes a todo_wine in the tests, but also makes print preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. Do you prefer a separate patch or resend this one? -- Dmitry.
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@winehq.org wrote: This patch not only fixes a todo_wine in the tests, but also makes print preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. Do you prefer a separate patch or resend this one? Either way is fine. A couple of tests for the other functions would probably also be a good idea. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make sure that actual clipping region is updated for a EMF DC.
Alexandre Julliard julli...@winehq.org wrote: This patch not only fixes a todo_wine in the tests, but also makes print preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. Do you prefer a separate patch or resend this one? Either way is fine. A couple of tests for the other functions would probably also be a good idea. Ok, I'll see what can be done regarding the tests for other clipping APIs, please consider accepting this patch in the mean time. -- Dmitry.
Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
On Wed, 13 Feb 2013 09:29:19 +0100
joerg-cyril.hoe...@t-systems.com wrote:
Hi,
Johannes Kroll wrote:
9.532:003a:trace:midi:modLongData dwBufferLength=88 !
f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z.
7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@...
00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|.
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f
7f 7f 01 7f f7 00 00 00
Could you please log dwBytesRecorded next to
TRACE(dwBufferLength=%u !\n, lpMidiHdr-dwBufferLength);
I once proved that dwBytesRecorded is what gets used with midiSTREAMout
I did. It is in the log line that you deleted. Immediately after the
hex dump...
TRACE(dwBufferLength=%u !\n, lpMidiHdr-dwBufferLength);
//~ TRACE( %02X %02X %02X ... %02X %02X %02X\n,
//~ lpData[0], lpData[1], lpData[2],
lpData[lpMidiHdr-dwBufferLength-3],
//~ lpData[lpMidiHdr-dwBufferLength-2],
lpData[lpMidiHdr-dwBufferLength-1]);
{ unsigned long dwToGo;
#define dprintf(x...) fprintf(stderr, x)
for (dwToGo = 0; dwToGo lpMidiHdr-dwBufferLength; dwToGo += 16)
{
DWORD i;
BYTEch;
for (i = 0; i min(16, lpMidiHdr-dwBufferLength - dwToGo);
i++)
dprintf(%02x , lpData[dwToGo + i]);
for (; i 16; i++)
dprintf( );
for (i = 0; i min(16, lpMidiHdr-dwBufferLength - dwToGo);
i++) {
ch = lpData[dwToGo + i];
dprintf(%c, (ch = 0x20 ch 0x7F) ? ch : '.');
}
dprintf(\n);
}
TRACE(dwBytesRecorded=%d\n, lpMidiHdr-dwBytesRecorded);
}
So there is an F7 there... Maybe the app expects that the driver scans
through the buffer for the F7 and doesn't send the following bytes...
Net.wisdom is that modLongData need be scanned for coalesced regular status
messages, e.g. some people use it to play chords, arguing that one LongMsg is
faster than 3 consecutive midiOutShortMsg. That's a patch yet to be written.
However, I wouldn't know what to do with the three 00 bytes. That's not MIDI!
No. Maybe dwBytesRecorded *should* be the length of the data. But it
isn't, it's always zero. Yes, really, I checked in several runs.
Also, I'm wondering what ALSA does with that packet. Do the bytes as shown
really
make their way over the serial port? (Perhaps you could use some virtual
MIDI device
to dump what ALSA processes internally?)
If I figure out a way to do that I'll let you know...
Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and
does
not require us to tell it what a sysex might be. I already tested that
disguising a chord
as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW
synth).
No, I don't have wineOSS. Does it require a proper OSSv4? Or would it
work with ALSA OSS emulation? I don't have 'real' OSS.
Re: msi/tests: Move a couple of tests from install.c to msi.c.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=24381
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:5673: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
Re: [PATCH] netstat: Clarify labels in UDP statistics.
On 2013-02-13 11:03, Frédéric Delanoy wrote: On Tue, Feb 12, 2013 at 7:56 PM, Lauri Kenttä lauri.ken...@gmail.com wrote: On 2013-02-09 23:15, Frédéric Delanoy wrote: Invalid Datagrams is too vague. It could mean datagrams sent or received. I think it's pretty obvious. Nobody should send invalid datagrams anyway, especially not using any actual datagram functions, so it would be ridiculous to have a counter for it. Yet it's what Windows uses, and is more specific, so I don't really think this should modified Ok, I'll leave it alone. On 2013-02-13 11:03, Frédéric Delanoy wrote: I meant if you find a msgstr ambiguous(which is not really a problem for the No ports IMHO), you can use msgctxt so that other translators benefit as well. My main point is that No Ports is not only ambiguous but also wrong in two ways. Bad wording: Why ports and not only port when this only concerns the single destination port of each datagram? How can there not be a port when the datagram always has a port field which can't be empty? (The RFC says that zero means empty only in the source port field, which implies that zero could be a valid destination.) Bad meaning: dwNoPorts actually includes also datagrams with non-zero port if the port is closed (not listening). MSDN hints something like this, and this can be easily verified on Windows (2003 Server). Ambiguity: There are many kinds of no and many kinds of ports, and most people (even programmers!) probably don't know what's a datagram with no ports. Also, translating X is quite different from translating number of received datagrams with X, even more so when the source text is inaccurate. Windows has lots of bad texts, I hope Wine doesn't need to provide compatibility for that. But if you still say so, I'll just add a msgctxt. -- Lauri Kenttä
Re: advapi32: Report world-access ownership by default for registry objects (try 2).
Erich E. Hoover ehoo...@mymail.mines.edu writes: The attached patch fixes an issue where the Opera installer expects registry keys to return ownership information (Bug #32904), concluding the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the issue by ensuring that NULL owner and group information is never returned for registry keys and instead returns the World SID (S-1-1-0) when this information is unavailable, which is sufficient to keep the Opera installer from encountering an error. The included test shows that this behavior is essentially the case for system keys on Windows, though the Administrators SID is returned instead. Since GetNamedSecurityInfo historically returned the World SID, and several other routines use it as well) I've opted to use the World SID for now. We should do the same as Windows unless there's a very good reason to be different. -- Alexandre Julliard julli...@winehq.org
Re: kernel32: Indicate that HeapValidate called by GlobalHandle is not the sign of heap corruption.
Dmitry Timoshkov dmi...@baikal.ru writes: This helps to distinguish this one from real signs of heap corruption, and saves quite a bit of effort analysing +heap or warn+heap logs. Avoiding HeapValidate would probably be a better approach. -- Alexandre Julliard julli...@winehq.org
Re: winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
These two patches look fine to me. Thanks! On Mon, Feb 11, 2013 at 01:28:09PM +0100, joerg-cyril.hoe...@t-systems.com wrote: Hi, This completes my winmm Prepare Header changes on the wave side. XyzPrepare: +header-dwFlags = ~(WHDR_DONE|WHDR_INQUEUE); /* flags cleared since w2k */ I choose to implement the behavior since w2k. Hopefully this will not break some w9x app. WINMM_UnprepareHeader: -header-dwFlags |= WHDR_DONE; Never ever observed. Neither w95 nor xp or w7. Perhaps MS would have been wise to do so, as simply looking at a header you cannot tell whether it's been processed or not (returned with error code). I choose to implement compatible behaviour. -if(!(lpWaveInHdr-dwFlags WHDR_PREPARED)) -return MMSYSERR_NOERROR; if(lpWaveInHdr-dwFlags WHDR_INQUEUE) return WAVERR_STILLPLAYING; +if(!(lpWaveInHdr-dwFlags WHDR_PREPARED)) +return MMSYSERR_NOERROR; Note the subtle difference in behaviour between wave and midi headers... IMHO calling named winmm:xyz functions should be equivalent to dispatching MM* messages I forgot to add that I'm still surprised that Andrew Eikum could reimplement waveIn/OutMessage *without* using MMDRV_Message by simply returning MMSYSERR_NOTSUPPORTED. Either all apps use the named winmm:waveIn/OutXyz functions instead of calling waveOutMessage() or nobody bothered to complain that some apps (perhaps w3.1 ones?) lack sound. That area obviously needs some testing... Regards, Jörg Höhle
Re: [PATCH] dsound: copy program parameters in SetFormat
On Mon, Feb 11, 2013 at 02:06:42PM +0100, Maarten Lankhorst wrote: Fixes bug #32312, apparently some programs depend on the format it specifies being returned. Just set wBitsPerSample, nSamplesPerSec and nChannels to make those applications happy. The patch seems fine, but can you add some tests for this so we can nail down exactly what we should be taking from the SetFormat format? E.g. should we just do device-primary_fmt = CopyFormat(passed_fmt) in all cases, or can you find a case where the GetFormat() result is changed? FYI, your patch applies with an offset and the Wine patch tracker didn't like this: --- a/dlls/dsound/primary.c +++ a/dlls/dsound/primary.c but git-am imported the raw mail file just fine. Andrew
winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
Johannes Kroll wrote: It is in the log line that you deleted. Oops. No, I don't have wineOSS. Does it require a proper OSSv4? Currently, yes. You'd have to try out wine-1.3.24 or older. I'll try and see how to use virtual MIDI devices to dump data without using a serial port. Anyway, I'll start writing a patch that decomposes LongMsg into snippets, although I don't know how to handle the three 00 00 00 bytes. Regards, Jörg Höhle
Re: [1/4] gdi32: Add more EMF clipping tests.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24394 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [2/4] gdi32: OffsetClipRgn should update actual clipping region for a EMF DC.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24395 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24396 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
