Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Dylan Smith]

On Sat, Feb 11, 2012 at 2:27 PM, Maarten Lankhorst
wrote:

>   Are you sure? I don't see any example calls being wrapped to ITextHost
> for example..
>

 Yup, I worked on it myself.  All those ITextHost_*(...), which you can
easily grep for in editor.c, are using macros in editor.h:

--- snip ---
#ifdef __i386__ /* Use wrappers to perform thiscall on i386 */
#define TXTHOST_VTABLE(This) (&itextHostStdcallVtbl)
#else /* __i386__ */
#define TXTHOST_VTABLE(This) (This)->lpVtbl
#endif /* __i386__ */
 /*** ITextHost methods ***/
#define ITextHost_TxGetDC(This) TXTHOST_VTABLE(This)->TxGetDC(This)
...
--- end snip ---

So for i386 it will use the itextHostStdcallVtbl, which is defined in
txthost.c to pop the This pointer off the stack and into a register, then
grab the pointer to the vtable, and jump to the thiscall method.

--- snip ---
#define STDCALL(func) __stdcall_ ## func
#define DEFINE_STDCALL_WRAPPER(num,func,args) \
   extern typeof(func) __stdcall_ ## func; \
   __ASM_STDCALL_FUNC(__stdcall_ ## func, args, \
   "popl %eax\n\t" \
   "popl %ecx\n\t" \
   "pushl %eax\n\t" \
   "movl (%ecx), %eax\n\t" \
   "jmp *(4*(" #num "))(%eax)" )

DEFINE_STDCALL_WRAPPER(3,ITextHostImpl_TxGetDC,4)
...

const ITextHostVtbl itextHostStdcallVtbl = {
NULL,
NULL,
NULL,
__stdcall_ITextHostImpl_TxGetDC,
...
--- end snip ---

The ITextHost interface is also implemented in txthost.c for non-windowless
richedit controls.  That interface is implemented using thiscall wrappers
which do the reverse of the standard call wrappers.

Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Maarten Lankhorst]

Hey Dylan,

Op 11-02-12 18:48, Dylan Smith schreef:
On Sat, Feb 11, 2012 at 9:50 AM, Maarten Lankhorst 
mailto:m.b.lankho...@gmail.com>> wrote:


I have my doubts about these for example:
- Richedit windowless mode - There's no way this can be a student
project until someone does the thiscall that works both ways, this
has been the biggest stumbling block to implementing it.


Actually, that stumbling block has been implemented.  The next step is 
implementing ITextServices::TxDraw.
Are you sure? I don't see any example calls being wrapped to ITextHost 
for example..


~Maarten

Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Dylan Smith]

On Sat, Feb 11, 2012 at 9:50 AM, Maarten Lankhorst
wrote:

> I have my doubts about these for example:
> - Richedit windowless mode - There's no way this can be a student project
> until someone does the thiscall that works both ways, this has been the
> biggest stumbling block to implementing it.
>

Actually, that stumbling block has been implemented.  The next step is
implementing ITextServices::TxDraw.

Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Jerome Leclanche]

On Sat, Feb 11, 2012 at 2:50 PM, Maarten Lankhorst
wrote:

> Hey Jeremy,
>
> Op 10-02-12 20:23, Jeremy White schreef:
>
>  Hi Folks,
>>
>> It's that time of year again - summer of code is going to start up soon.
>>
>> Maarten, you've been coordinating things for us for a while now - are
>> you still game?  Would you like help?  Anyone else willing to volunteer
>> to help admin the process?
>>
>>  I'll apply wine again this year, but I want to ask everyone to help
> update our summer of code project wiki page.
>
> http://wiki.winehq.org/**SummerOfCode
>
> I feel like we're not getting enough accessible projects that also have
> the correct length. I'm looking for something that's non-trivial but can
> still be done incrementally, having huge delta's to winehq has proven to
> not lead to meaningful contributions, and some of the projects on that list
> are too small, too complicated or might not be integrated into wine because
> it would be above a student's level get it done
> right.
>
> I have my doubts about these for example:
> - Message mode pipes - if AJ doesn't know how to do it, how can a student
> do it right?
> - Sandboxing, what's to prevent an app from simply doing syscalls in
> assembly, a real sandbox is not going to work
> - Richedit windowless mode - There's no way this can be a student project
> until someone does the thiscall that works both ways, this has been the
> biggest stumbling block to implementing it.
> - TestSuite - All previous attempts have failed, I believe that compiling
> testsuites for other projects would be a good project instead, fixing all
> problems that show up and don't show up on windows. Improving winetestbot
> to something more standardized and maintained would be nice too, but hardly
> a summer of code project, since it's too short.
>
> But that's just my opinion, feel free to add your own projects to that
> list. :-)
>
> ~Maarten
>

The problem with GSOC projects, in my opinion, is that too many people see
them as "projects"; the kind that needs to be finished by a deadline and
have visible changes, new gui or this sort of thing.

While there are interesting bits that could be done that way, having looked
at a lot of bugs and their lifetime it feels to me there are areas of wine
that could just use generic improvements, which are the kind that help wine
the most: gradually implemented, tends to have a visible impact on bugs,
many different areas to pick from, etc.
The uniscribe/bidi improvements over the past few releases are a good
example of a project that could have been picked up by someone familiar
with/willing to familiarise themselves with the area.

J. Leclanche

Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27

[Maarten Lankhorst]

Hey Jeremy,

Op 10-02-12 20:23, Jeremy White schreef:

Hi Folks,

It's that time of year again - summer of code is going to start up soon.

Maarten, you've been coordinating things for us for a while now - are
you still game?  Would you like help?  Anyone else willing to volunteer
to help admin the process?

I'll apply wine again this year, but I want to ask everyone to help 
update our summer of code project wiki page.


http://wiki.winehq.org/SummerOfCode

I feel like we're not getting enough accessible projects that also have 
the correct length. I'm looking for something that's non-trivial but can 
still be done incrementally, having huge delta's to winehq has proven to 
not lead to meaningful contributions, and some of the projects on that 
list are too small, too complicated or might not be integrated into wine 
because it would be above a student's level get it done

right.

I have my doubts about these for example:
- Message mode pipes - if AJ doesn't know how to do it, how can a 
student do it right?
- Sandboxing, what's to prevent an app from simply doing syscalls in 
assembly, a real sandbox is not going to work
- Richedit windowless mode - There's no way this can be a student 
project until someone does the thiscall that works both ways, this has 
been the biggest stumbling block to implementing it.
- TestSuite - All previous attempts have failed, I believe that 
compiling testsuites for other projects would be a good project instead, 
fixing all problems that show up and don't show up on windows. Improving 
winetestbot to something more standardized and maintained would be nice 
too, but hardly a summer of code project, since it's too short.


But that's just my opinion, feel free to add your own projects to that 
list. :-)


~Maarten

Re: winealsa.drv patch to enum all software devices from .asoundrc

[Chris Robinson]

On Saturday, February 11, 2012 2:05:18 PM Нискородов Серёжа wrote:
> > Nope, it won't open in a rate other than 48000hz without plug:. But again,
> > that's fine for mmdevapi as it doesn't support rate conversion by default.
> 
> Hmm... Ok. But how it works in Windows? Does you mean that
> applications take care of sample rate conversion in Windows? Seems
> like it's not.

That's how it works in Windows:
http://msdn.microsoft.com/en-
us/library/windows/desktop/dd370811%28v=vs.85%29.aspx
"An application that uses WASAPI to manage shared-mode streams can rely on the 
audio engine to perform only limited format conversions. The audio engine can 
convert between a standard PCM sample size used by the application and the 
floating-point samples that the engine uses for its internal processing. 
However, the format for an application stream typically must have the same 
number of channels and the same sample rate as the stream format used by the 
device."

I remember seeing this happen with some of my own stuff in Windows, too.

> Here is another trouble with snd_ctl_open. Not all devices in alsa
> configuration files have a predefined ctl. Especially defined by user,
> for example I don't always define a ctls for all my devices in
> .asoundconf

You can use the "hw:" prefix for snd_ctl_open. All you need it for is to get 
the card info and the available device indices, which doesn't rely on a custom 
prefix.

Hmm, actually it seems winealsa already does this enumerating. Except it 
hardcodes the plughw: prefix for the device string, uses the card index 
instead of the name, and doesn't explicitly specify the parameter names (it 
uses "x,y" instead of "CARD=x,DEV=y"). Perhaps I'll see about making some 
patches.

> So what I suggest and what I can do for now:
> 1) To enumerate all devices, that ALSA can enumerate. First in list -
> default device (like it was before), after that - hardware devices
> (like it was before), and below all devices, that returns "aplay -L";
> 2) To disable the testing of device avaliability (by alsa_try_open)
> while enumerating it. Thus, even devices that inaccessible at the time
> of enumeration can be added to the list.
> What you think about?

The problem with also taking everything shown by "aplay -L" is that it has a 
tendency to list the same device multiple times (which themselves are already 
mostly duplicated from the snd_card_next+etc enumeration, just with different 
prefixes). It can greatly increase the number of devices for no reason, IMO. 
You also can't get meaningful names from them (who would know what to make of 
it seeing "HDA NVidia, ALC888 Analog" and "HDA NVidia, ALC888 Digital" next to 
"HDA NVidia - ALC888 Analog" and "HDA NVidia - ALC888 Digital"?).

Registry options to skip device enumeration and to supply a custom list of 
devices will be fine, I think, as well as options to specify custom prefixes.

I'd agree with getting rid of alsa_try_open, unless there's a reason to keep 
it. I don't think there's a good reason to prevent enumerating the extra 
devices that can't be opened here though. It's status as unavailable/in-use 
can be handled later, I think.

Re: winealsa.drv patch to enum all software devices from .asoundrc

[Нискородов Серёжа]

> As I mentioned, native mmdevapi doesn't do samplerate conversion or channel
> remixing. For shared mode, the device only opens with a pre-defined, user-
> selected rate and channel config. The only thing the default native mmdevapi
> will do is accept different sample depths/type (prefering float32). It's up to
> the app or whatever component is using mmdevapi to convert to the
> rate/channels given by GetMixFormat.
>
> Any other conversion besides sample type is reliant on the user having
> installed plugins that'll do the wanted conversion. If it really becomes an
> issue (which it shouldn't), Wine could support these and have some by default.

I'm sorry, but I have no time to dive so deep and to study how
mmdevapi works and how it have to work...
So I cannot answer you.

> My dmix51 device is defined in /etc/asound.conf. The difference is, it's
> defined to accept CARD, DEV, and SUBDEV parameters similar to regular dmix, so
> ALSA will enumerate it for each CARD and DEV that can support its output
> parameters.

Ok. I understand, I cannot ignore devices with colon in names.

>> Do you can play wav mono 11025Hz directly to your dmix51 device?
>> Without "plug:" wrapper?
>> With my soundcard I can't.
>
> Nope, it won't open in a rate other than 48000hz without plug:. But again,
> that's fine for mmdevapi as it doesn't support rate conversion by default.

Hmm... Ok. But how it works in Windows? Does you mean that
applications take care of sample rate conversion in Windows? Seems
like it's not.

> What I'd suggest is using snd_card_next, snd_ctl_open (which won't lock the
> device like snd_pcm_open), snd_ctl_pcm_next_device, and related, to enumerate
> available card names and device indices

Here is another trouble with snd_ctl_open. Not all devices in alsa
configuration files have a predefined ctl. Especially defined by user,
for example I don't always define a ctls for all my devices in
.asoundconf
So to use snd_ctl_open instead of snd_pcm_open I have to write some
logic to fallback to hardware ctl if software device does not have own
defined ctl.
It's much more complicated, than I can do... At least for now.

>, and have a configuration option in
> winecfg or somewhere to specify the prefix used ("dmix:", "plughw:", something
> custom, etc). Maybe another option to specify an additional list of custom
> devices that can't be detected this way, though most users shouldn't need that
> with the appropriate device prefix selected.
>
> Just make sure to use the card name given by snd_ctl_card_info_get_id, so that
> the CARD parameter remains constant even if the card index changes.

I think you are greatly complicates this all.
If all this devices can be enumerated and accessed by ALSA natively,
then it all can be listed in WINE, why not? And user can select a
device at his own risk.
So what I suggest and what I can do for now:
1) To enumerate all devices, that ALSA can enumerate. First in list -
default device (like it was before), after that - hardware devices
(like it was before), and below all devices, that returns "aplay -L";
2) To disable the testing of device avaliability (by alsa_try_open)
while enumerating it. Thus, even devices that inaccessible at the time
of enumeration can be added to the list.
What you think about?