January 2017 - Wine-Devel - list.winehq.org

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Bruno Jesus

On Tue, Jan 31, 2017 at 4:23 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Tue, Jan 31, 2017 at 12:16 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. >> >> A comparison before and after patch using gmidimonitor as ouput MIDI port: >> http://alexa.pro.br/~bruno/wine/midi.png >> >> I believe the patch to be correct, I don't own any MIDI hardware to test but gmidimonitor seems good enough. > > Do wineoss / winepulse need similar fixes? wineoss code at [1] in a quick look at [2] suggests it may be wrong because MAYBE system real time messages are supposed to be _TIMER_EVENT like SEQ_START_TIMER or SEQ_STOP_TIMER... Hard to tell beucase these messages values don't match the MIDI spec. winepulse seems to forward mid stuff to ALSA because the only time "mid" is found is in the spec file: winepulse.drv.spec:@ stdcall -private midMessage(long long long long long) winealsa.drv.midMessage [1] http://source.winehq.org/source/dlls/wineoss.drv/midi.c#1435 [2] https://github.com/torvalds/linux/blob/master/include/uapi/linux/soundcard.h Best wishes, Bruno

Jan. 31, 2017

Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

by Austin English

On Tue, Jan 31, 2017 at 12:16 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages. > > A comparison before and after patch using gmidimonitor as ouput MIDI port: > http://alexa.pro.br/~bruno/wine/midi.png > > I believe the patch to be correct, I don't own any MIDI hardware to test but gmidimonitor seems good enough. Do wineoss / winepulse need similar fixes? -- -Austin GPG: 14FB D7EA A041 937B

Jan. 31, 2017

Re: [PATCH] regedit: When processing 3.1 ignore any lines that don't begin with HKCR.

by Zebediah Figura

On 01/30/2017 09:46 PM, Nikolay Sivov wrote: > On 31.01.2017 5:51, Zebediah Figura wrote: >> Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> >> --- >> programs/regedit/regproc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c >> index c055c10..b6de728 100644 >> --- a/programs/regedit/regproc.c >> +++ b/programs/regedit/regproc.c >> @@ -616,8 +616,9 @@ static void processRegEntry31(WCHAR *line) >> int res; >> >> static WCHAR empty[] = {0}; >> + static WCHAR hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; >> >> - if (line[0] == '\0') return; >> + if (memcmp(line, hkcr, sizeof(hkcr) - sizeof(WCHAR))) return; >> >> /* get key name */ >> while (line[key_end] && !isspaceW(line[key_end])) key_end++; >> > > Is it guaranteed 'line' is a least that large? Also you can remove > terminating 0 from hkcr to avoid sizeof(WCHAR) subtraction. > > Sorry for my lack of C knowledge, but isn't this a valid use of memcmp? (And yes, I will fix that; thank you.)

Jan. 31, 2017

Re: xmllite: Add Unknown to map (Coverity)

by Nikolay Sivov

On 31.01.2017 1:11, André Hentschel wrote: > CID 1364307 > > Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > --- > dlls/xmllite/reader.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c > index 1e3c7aa..f99ea66 100644 > --- a/dlls/xmllite/reader.c > +++ b/dlls/xmllite/reader.c > @@ -85,6 +85,7 @@ typedef enum > > static const WCHAR utf16W[] = {'U','T','F','-','1','6',0}; > static const WCHAR utf8W[] = {'U','T','F','-','8',0}; > +static const WCHAR unknownW[] = {'U','n','k','n','o','w','n',0}; > > static const WCHAR dblquoteW[] = {'\"',0}; > static const WCHAR quoteW[] = {'\'',0}; > @@ -151,8 +152,9 @@ struct xml_encoding_data > }; > > static const struct xml_encoding_data xml_encoding_map[] = { > - { utf16W, XmlEncoding_UTF16, ~0 }, > - { utf8W, XmlEncoding_UTF8, CP_UTF8 } > + { utf16W, XmlEncoding_UTF16, ~0 }, > + { utf8W, XmlEncoding_UTF8, CP_UTF8 }, > + { unknownW, XmlEncoding_Unknown, ~0 }, > }; > > const WCHAR *get_encoding_name(xml_encoding encoding) > I don't think this fixes anything in a sense of making xmllite more compliant. We probably should just fail at CreateXmlWriterOutputWithEncodingName() and print encoding string that made it fail.

Jan. 31, 2017

Re: [PATCH] regedit: When processing 3.1 ignore any lines that don't begin with HKCR.

by Nikolay Sivov

On 31.01.2017 5:51, Zebediah Figura wrote: > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > programs/regedit/regproc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index c055c10..b6de728 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -616,8 +616,9 @@ static void processRegEntry31(WCHAR *line) > int res; > > static WCHAR empty[] = {0}; > + static WCHAR hkcr[] = {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0}; > > - if (line[0] == '\0') return; > + if (memcmp(line, hkcr, sizeof(hkcr) - sizeof(WCHAR))) return; > > /* get key name */ > while (line[key_end] && !isspaceW(line[key_end])) key_end++; > Is it guaranteed 'line' is a least that large? Also you can remove terminating 0 from hkcr to avoid sizeof(WCHAR) subtraction.

Jan. 31, 2017

Re: comctl32: Fix some more spec file entries

by André Hentschel

Am 30.01.2017 um 11:32 schrieb Huw Davies: > On Sun, Jan 29, 2017 at 09:58:36PM +0100, André Hentschel wrote: >> Signed-off-by: André Hentschel <nerv(a)dawncrow.de> >> --- >> dlls/comctl32/comctl32.spec | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/comctl32/comctl32.spec b/dlls/comctl32/comctl32.spec >> index c3e9167..dbfa123 100644 >> --- a/dlls/comctl32/comctl32.spec >> +++ b/dlls/comctl32/comctl32.spec >> @@ -93,7 +93,7 @@ >> 382 stdcall -noname SmoothScrollWindow(ptr) >> 383 stub -noname DoReaderMode >> 384 stdcall -noname SetPathWordBreakProc(ptr long) >> -385 stdcall -ordinal DPA_EnumCallback(long long ptr) >> +385 stdcall -ordinal DPA_EnumCallback(long ptr ptr) > > Should be: > 385 stdcall -ordinal DPA_EnumCallback(ptr ptr ptr) > > Huw. > True, thx! The reason is that I'm currently ignoring handles as we don't have a clear rule for them, and as the first parameter type begins with an H, my script thought it is a handle and ignored it...

Jan. 30, 2017

Re: wine/test.h: Identify test result lines printed by child processes.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > Currently the child process result lines are indistinguishable from the > main process one. This makes it impossible to automatically detect > when a process exits abruptly, i.e. without printing a result line, > if it has run a subprocess. By making the subprocess result lines > different analysis tools will detect that the main result line is > missing and automatically consider that the main process crashed, > thus marking the test as failed. > > Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com> > --- > > This should fix bug 32354: > https://bugs.winehq.org/show_bug.cgi?id=32354 I don't think the test framework should be modifying the environment in all the tests. It already breaks some things: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so environ && touch environ.ok environ.c:198: Test failed: Expected environment block pointer element to be non-NULL wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed2a986 (thread 0074), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

Jan. 30, 2017

Re: Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Józef Kucia

On Mon, Jan 30, 2017 at 5:26 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > Thank you for your feedback. > WineD3D/D3D11/OpenGL are complex APIs with lots of tricky details. > I know my implementation is far from perfect, but it seems that you learn > better by working, trying, so I do. > I have a basic but (likely) working tessellation implementation and I'll > submit it soon. But it's quite dirty, so I expect feedbacks to improve it > (if you haven't done it locally yet). Sure, a tessellation shaders implementation would be welcome. I haven't done much work on tessellation shaders, just some hacks to run a very basic tessellation shaders. I think that it might be a good idea to implement stream output/transform feedback first. Stream output should make writing tests for tessellation shaders so much easier. Basic support for stream output should also be easier to implement than tessellation shaders. > > Btw, I think you should write down somewhere who is currently working on > what at Crossover, to avoid useless duplicated work. This could be improved, but the truth is that we do not have much contributions to wined3d besides the work of core wined3d team. You can always write to wine-devel that you are interested in implementing a particular feature.

Jan. 30, 2017

Re: comctl32: Correctly set the colour table for ILC_COLOR4 and ILC_COLOR8 imagelists.

by Huw Davies

On 30 Jan 2017, at 16:38, Marvin <testbot(a)winehq.org> wrote: > 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 > https://testbot.winehq.org/JobDetails.pl?Key=28138 Yes, sorry about the noise. It seems that older versions of Windows don’t implicitly set the colour table from the added bitmap. I’ll work on another version. Huw.

Jan. 30, 2017

Re: [PATCH 05/10] wined3d: Add compute shaders cb/samplers state updates.

by Guillaume Charifi

I meant Codeweavers.

Jan. 30, 2017