[Wine] Fwd: Re: Any progress on bug 16147?

[Gert van den Berg]

On Wed, Oct 13, 2010 at 16:19, James Mckenzie
<jjmckenzie51 at earthlink.net> wrote:
> Robert Benjamin <benjie1 at cox.net> wrote:
>>Sent: Oct 13, 2010 4:26 AM
>>To: wine-users at winehq.org
>>Subject: Re: [Wine] Fwd: Re: Any progress on bug 16147?
>>
>>Just wondering why I haven't had a reply about the webcam problem
>>with iSpQ and icuii. There are a few previous posts about testing the
>>cam from Gert but nothing lately.
>
> Maybe because no one is working on this (mostly) voluteer project on webcams at this time, or someone is quietly doing so and will release a fix when it is ready.  Gert may be doing so.  Have you filed or updated a bug report with this information?  If so, progress will be reported through the bugzilla and not here.
>
Not working on it. The gstreamer integration is what I think should
properly fix it... It was out as a GSoC project, not sure if someone
actually worked on it and if any progress was made...

(My video capture programming experience involved using OpenCV under
Windows, which hides most details...) For someone to fix this they
probably need to know Directshow and whatever interface they're using
on Linux (v4l, v4l2 or a higher level library such as gstreamer) quite
well...

> No, getting a patch into Wine is a lengthy and necessarily difficult process.  This takes time (I have been working on a patch for over two years to add a function to richedit and continue to do so.)  There have been patches for non-storage USB devices, like WebCams that were submitted and rejected, several times.

Adding an interface to native video capture drivers probably makes
more sense (running the Windows drivers are likely to cause conflicts,
and that might make more sense in a separate project allowing the
drivers to be used through native interfaces (like ndiswrapper for
network drivers)) (I've got no idea how drivers interact with the OS
under Windows) (My guess is that each of the device types that you can
see in device manager have a certain set of functions that gets
accessed by the relevant Windows API) (This migh make supporting all
windows USB drivers hard - and things like USB network adaptors would
probably be hard to support already)

Interfacing with the native drivers might be easier, but it limits
Wine's hardware support to that of the native OS. (And for
portability, working directly with the host OS might be inefficient
(such as audio currently, where you should support CoreAudio (OS X),
ALSA (Linux), OSS (Linux, other unixes?) and pulseaudio (mutiple
platforms) as a minimum to work in most places))

Gert