USB status ...Who maintains wineserver?

[Rolf Kalbermatter]

>Mike McCormick wriote:
>> I'll point out to you once again that Wine is not the right place to
>> implement drivers.  Drivers that are loaded in the kernel in Windows 
>> also belong in the kernel in Linux, not in Wine.
>
>I don't care about Windows kernel drivers, just
>replicating the interface to them from user space
>software so that user-space drivers (which are
>abundant in Windows) can work.

In the case of video capturing through avicap32 and most probably quartz
too, we would be talking about "installable" drivers (loaded with
winmm.OpenDriver) which reside in user space. It's the same driver
interface used for audio drivers (alsa, oss, etc) and image companders
(IC).

I think it would be a good idea to add a winev4l driver into winmm so
that quartz and avicap/vfw could make use through a standard interface
and adding new capture interfaces would be possible without the need
to hack into avicap or quartz at all.

> Have a look at the work that Maarten Lankhorst is
> doing on Web cameras
> ... he's doing things the right way.

>> You can continue trying to modify CreateFile,
>> ReadFile, WriteFile etc.
>> to make it work, but you'll realize sooner or later
>> that a handle is 
>> tied to a unix fd.
>
>In fact, it's tied to an "object" in wineserver: what
>fd would HWINDOW and HICON represent?

Mike was refering to handles returned by CreateFile only. It is the
interface to create kernel device driver instances under Windows and
consequently wineserver would need to be involved somehow.
HWINDOW and such while handles too, are completely different objects
and managed by independent object managers both in Windows and Wine.

A clean implementation for kernel driver support would need to support
all kernel driver API interfaces through wineserver somehow, a nightmare
both for performance and implementation reasons.

Rolf Kalbermatter