Re: USB Device Support

[Juan Lang]

Hi Scott,

>        I've been working through my Dell Inspiron 1545 with Linux/Ubuntu
> 10.04 LTS experiences with ongoing reviews.  I'd like to provide some help
> to others considering making the transition from Windows to Linux.  I'm
> trying to get my Garmin GPS to talk to its Mapsource (running under WINE)
> application through a USB port.  This allows tracks to be read from and
> written to the GPS itself.  So far no luck.  Can someone there please
> provide some advice?  If this functionality isn't available yet then so be
> it.  The Mapsource application runs fine it's just the USB communication
> that isn't working.  Many thanks.

Such questions are better addressed to the Wine forum.  Thanks,
--Juan

Re: USB Device Support

[Scott]

Hi,

	I've been working through my Dell Inspiron 1545 with Linux/Ubuntu 
10.04 LTS experiences with ongoing reviews.  I'd like to provide some 
help to others considering making the transition from Windows to 
Linux.  I'm trying to get my Garmin GPS to talk to its Mapsource 
(running under WINE) application through a USB port.  This allows 
tracks to be read from and written to the GPS itself.  So far no 
luck.  Can someone there please provide some advice?  If this 
functionality isn't available yet then so be it.  The Mapsource 
application runs fine it's just the USB communication that isn't 
working.  Many thanks.


Best - Scott

bluetooth cpl support (Re: USB Device Support - Nokia PC Suite)

[Hin-Tak Leung]

--- On Fri, 18/2/11, Mike Yates  wrote:

> After rebooting, I did get a full
> list of "fixme" lines:-
> 
> mike@myvmubuntu:~$ wine .wine/drive_c/Program\
> Files/Nokia/Nokia\ PC\
> Suite\ 7/PCSuite.exe



> err:module:import_dll Library irprops.cpl (which is needed
> by
> L"C:\\Program Files\\PC Connectivity
> Solution\\Transports\\NclMSBTSrv.exe") not found
> err:module:LdrInitializeThunk Main exe initialization for
> L"C:\\Program Files\\PC Connectivity
> Solution\\Transports\\NclMSBTSrv.exe" failed, status
> c135



> (0x14c0d00)->(0x33bcc8)
> I/O warning : failed to load external entity
> "ConfServer.dtd"
> err:msxml:domdoc_validateNode Could not load the external
> subset
> "ConfServer.dtd"


There are really only two important error messages here - I am not sure about 
the latter, but the first one is simply that part of the Nokia PC suite tries 
to load "irprops.cpl", which AFAIK is the bluetooth control panel applet. It is 
not surprising that it fails - that hasn't been written in wine yet.

I think both sides are 'barking up the wrong tree' - the initial poster thought 
PC suite failure is due to lack of sufficient USB support in wine; and some of 
the wine devs can possibly take a quick look before shouting the poster down. 
The lack of bluetooth implementation is a valid development discussion?

It appears that since Nokia PC suite supports bluetooth connectivity to mobile 
phones (as well as serial cable, infrared, AFAIK, I own nokia phones for about 
10 years), it tries to load some windows OS bluetooth bits and fails. If the 
poster doesn't actually need bluetooth connectivity, adding a stub minimal 
implementation of irprops.cpl which does nothing can probably get the software 
to run?

OTOH, I already mentioned both on and off list a few times: xnokii/gnokii does 
what I need with nokia phones and I have never been drawn to look at running 
the windows nokia software in wine. 


  

Re: USB Device Support - Nokia PC Suite

[GOUJON Alexandre]

On 02/18/2011 05:08 PM, Mike Yates wrote:

After rebooting, I did get a full list of "fixme" lines:-

mike@myvmubuntu:~$ wine .wine/drive_c/Program\ Files/Nokia/Nokia\ PC\
Suite\ 7/PCSuite.exe

[snip]

Mike, this is a developer's mailing list. With questions about how to 
use Wine please refer to Wine user forum: http://forum.winehq.org/


Vitaliy


Please stop flooding the dev mailing list.
It won't make your app working.
And developers won't help you here.

Please file a bug in Bugzilla as other users.
Attach there your compressed log, explain how to reproduce the crash, 
indicate a URL where this piece of software can be downloaded ... and 
*wait*.

Some 'NEW' bugs are solved months, days or years later, it depends.
The USB support in wine is still 'experimental' and may work or not.

If you want to help, feel free to send a patch.
Or ask a question here if it's related to wine development.

But please, stop flooding here.
Thanks

Re: USB Device Support - Nokia PC Suite

[Mike Yates]

After rebooting, I did get a full list of "fixme" lines:-

mike@myvmubuntu:~$ wine .wine/drive_c/Program\ Files/Nokia/Nokia\ PC\
Suite\ 7/PCSuite.exe
fixme:userenv:GetUserProfileDirectoryW 0x100 (nil) 0x32f43c
err:ole:CoInitializeEx Attempt to change threading model of this
apartment from apartment threaded to multi-threaded
fixme:msxml:domdoc_get_readyState stub! (0x16c9a0)->(0x32ec38)
I/O warning : failed to load external entity "ConfServer.dtd"
err:msxml:domdoc_validateNode Could not load the external subset
"ConfServer.dtd"
fixme:font:WineEngAddFontResourceEx Ignoring flags 10
fixme:font:WineEngAddFontResourceEx Ignoring flags 10
fixme:font:WineEngAddFontResourceEx Ignoring flags 10
fixme:font:WineEngAddFontResourceEx Ignoring flags 10
fixme:msxml:domdoc_get_readyState stub! (0x181780)->(0x32eb94)
I/O warning : failed to load external entity "ConfServer.dtd"
err:msxml:domdoc_validateNode Could not load the external subset
"ConfServer.dtd"
fixme:msxml:domdoc_get_readyState stub! (0x1af030)->(0x32eac8)
I/O warning : failed to load external entity "ConfServer.dtd"
err:msxml:domdoc_validateNode Could not load the external subset
"ConfServer.dtd"
err:ole:CoInitializeEx Attempt to change threading model of this
apartment from apartment threaded to multi-threaded
fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50076 0x0001
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbdef8 0xbbdef4
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbdc64 0xbbdc5c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbe794 0xbbe790
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbe500 0xbbe4f8
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateSessionsW Stub (nil) 0x 0x0001
0xbbe350 0xbbe34c
fixme:wtsapi:WTSFreeMemory Stub (nil)
fixme:wtsapi:WTSEnumerateProcessesW Stub (nil) 0x 0x0001
0xbbe0bc 0xbbe0b4
fixme:wtsapi:WTSFreeMemory Stub (nil)
err:module:import_dll Library irprops.cpl (which is needed by
L"C:\\Program Files\\PC Connectivity
Solution\\Transports\\NclMSBTSrv.exe") not found
err:module:LdrInitializeThunk Main exe initialization for
L"C:\\Program Files\\PC Connectivity
Solution\\Transports\\NclMSBTSrv.exe" failed, status c135
err:ole:CoGetClassObject class {0af10cec-2ecd-4b92-9581-34f6ae0637f3}
not registered
err:ole:CoGetClassObject no class object
{0af10cec-2ecd-4b92-9581-34f6ae0637f3} could be created for context
0x1
fixme:ole:CoInitializeSecurity
(0x5af948,-1,(nil),(nil),4,3,(nil),0,(nil)) - stub!
fixme:ole:CoResumeClassObjects stub
fixme:advapi:RegisterEventSourceW ((null),L"ServiceLayer"): stub
fixme:advapi:ReportEventW
(0xcafe4242,0x0004,0x,0x,(nil),0x0001,0x,0x8be7c0,(nil)):
stub
fixme:advapi:DeregisterEventSource (0xcafe4242) stub
fixme:ole:LPSAFEARRAY_UserSize size interfaces
fixme:ole:LPSAFEARRAY_UserMarshal marshal interfaces
fixme:ole:LPSAFEARRAY_UserUnmarshal marshal interfaces
fixme:msxml:domdoc_get_readyState stub! (0x1a9570)->(0x32eaf8)
I/O warning : failed to load external entity "ConfServer.dtd"
err:msxml:domdoc_validateNode C

Re: USB Device Support - Nokia PC Suite

[Vitaliy Margolen]

Mike, this is a developer's mailing list. With questions about how to use 
Wine please refer to Wine user forum: http://forum.winehq.org/


Vitaliy

Re: USB Device Support

[Hin-Tak Leung]

--- On Thu, 17/2/11, Mike Yates  wrote:

> Hi
> I (and a lot of contributors to the Nokia forums) would
> like to use the
> Nokia PC Suite in Wine.
> The current status in the AppDB of Nokia PC Suite
> 
> v7.x.x.x is "Garbage" because, although installation and
> all the other
> functions now (wine v1.2.2) work just fine, it is totally
> useless
> without its "Connect a Phone" function.
> I have written in AppDB:-

I know it is a bit off topic - but what functionality of Nokia PC Suite that 
you need which isn't provided by gnokii/xnokii ? I have nokia phones for nearly 
10 years (actually I have never owned a different brand), and gnokii/xnokii has 
been sufficient for my needs all these days. Connectivity via 
infrared/bluetooth are okay.

> 
> by Dave 
> on
> Sunday September 12th 2010, 3:34
> > Running Wine 1.2 (latest version on ubuntu
> repository), trying to
> > install nokia pc suite 7.1.51.0. I get past the
> license agreement (all
> > icons are black though, but it's not hard to guess
> which one is
> > "NEXT") and choosing which directory to install to
> (accept the
> > default). But then it quits and I get a window that
> says,
> > ERROR_INSTALL_FAILURE. According to your website this
> has been tested
> > and should install, so what's wrong?
> 
> 
> Using latest Ubuntu-10.10 wine the installation is all
> visible.
> No connectivity, but there IS kernel support.
> Still investigating - will report more later...
> 
> The kernel connects to my Nokia 6300 by USB as
> /dev/ttyACM0
> I have used this with with wvdial (and other apps) to use
> the 6300 as an
> Edge modem and also with kmobile-tools to sync contacts.
> Surely there is a way of linking /dev/ttyACM0 into wine as
> a raw USB or
> serial port?
> Anyone know how?
> 
> Well?
> --
> Mike Yates             
>      Cowley  Middlesex England
> *
> 
> *
> 
> 
> 


  

Re: USB Device Support - Nokia PC Suite

[Mike Yates]

Stefan D?singer wrote:-
> ln -s /dev/ttyACM0 "~/.wine/dosdevices/com0:" or something like that. It may 
> be "COM0:" or "com0" without the :.
> Then ttyACM0 is available as COM 0, but it is a classic serial port. If the 
> app is looking for a usb to serial device
> with a specific USB vendor and device ID it won't find the port.

Thanks Stefan, that's a good start.
The "Click here to connect a phone" still induces a wine crash but
takes longer thinking about it.
The "Settings/Manage Connections" now doesn't crash now but brings up
an empty list of connections to choose from.
Unfortunately these are both too separated from a console launch to
capture any "fixme" lines, I only get this one from the main program:-

mike@myvmubuntu:~$ wine .wine/drive_c/Program\ Files/Nokia/Nokia\ PC\
Suite\ 7/PCSuite.exe
fixme:userenv:GetUserProfileDirectoryW 0xfc (nil) 0x32f43c
mike@myvmubuntu:~$

I'll try different COM ports and let you know...

Re: USB Device Support

[Stefan Dösinger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Am 17.02.2011 um 21:34 schrieb Mike Yates:
> Surely there is a way of linking /dev/ttyACM0 into wine as a raw USB or
> serial port?
> Anyone know how?
ln -s /dev/ttyACM0 "~/.wine/dosdevices/com0:" or something like that. It may be 
"COM0:" or "com0" without the :. Then ttyACM0 is available as COM 0, but it is 
a classic serial port. If the app is looking for a usb to serial device with a 
specific USB vendor and device ID it won't find the port.

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

iQIcBAEBAgAGBQJNXi9yAAoJEN0/YqbEcdMwS9cP/0MfKvdnQaAjukqrwO6qEP6a
WqvcYze5kMQ1TolNykRPw6gVG7KHk72lWuXDbb/5mj515JiFZ8wlS/VQy5kMRj7q
U9IoQawwxZGJMUtORESuXCt0n6dBDzhwA1vvnrBO0pKUSHNjkhNbbhzJ9wJ/Plrl
4wHaAhsx7lm7I/yjcWkYC8sE8/SlTftrZ/KyClIUt8bDecnx3WBGj6Ew1n9K9Z/8
/IdTrlc37P1LWYeEaE1iboJwSen8hhKn3a/SefWNPIUcWYbRKtrPaJl8x5z22LYe
g3Jc3Trzy2+Dp7cPdcfzXaehbo8XqhmScU3b+U6PkwoyphEvghwZzFLx8Vh08szl
ZnYLXkq4v0I3rmhyc5U5JldFurmSZCffMi8CKEQ5qmu2hsFIo9X1I8VRIIH+4iuz
UNkK9DHCgM7WslgbcvjcDMG5zqLrOUiKf/2Znr3oQ9PjH+K9NGDE1R7UiOarVKap
Aga6m/86182XWuE56gql+ZXpSoq+Mc/bFGUjme+EPZTM8oWEs8IvmQpgUmof2kOk
/AYL5OOABY4DuiAE+6i7Xm1XpbDrFcFPEBszYYLn4wmGt9oDCqUBi/ZU9RKlTNBz
WlamVjQ8ETA8nJLUihSz163GVTv/5O+y/BwIpnY4D8CPPByCEHnmE3oW3MsOk9PP
t9F2QDdxKpXl2+OL0wXm
=LxfA
-END PGP SIGNATURE-

Re: USB Device Support

[Mike Yates]

Hi
I (and a lot of contributors to the Nokia forums) would like to use the
Nokia PC Suite in Wine.
The current status in the AppDB of Nokia PC Suite

v7.x.x.x is "Garbage" because, although installation and all the other
functions now (wine v1.2.2) work just fine, it is totally useless
without its "Connect a Phone" function.
I have written in AppDB:-

by Dave  on
Sunday September 12th 2010, 3:34
> Running Wine 1.2 (latest version on ubuntu repository), trying to
> install nokia pc suite 7.1.51.0. I get past the license agreement (all
> icons are black though, but it's not hard to guess which one is
> "NEXT") and choosing which directory to install to (accept the
> default). But then it quits and I get a window that says,
> ERROR_INSTALL_FAILURE. According to your website this has been tested
> and should install, so what's wrong?


Using latest Ubuntu-10.10 wine the installation is all visible.
No connectivity, but there IS kernel support.
Still investigating - will report more later...

The kernel connects to my Nokia 6300 by USB as /dev/ttyACM0
I have used this with with wvdial (and other apps) to use the 6300 as an
Edge modem and also with kmobile-tools to sync contacts.
Surely there is a way of linking /dev/ttyACM0 into wine as a raw USB or
serial port?
Anyone know how?

Well?
--
Mike Yates   Cowley  Middlesex England
*

*

Re: USB Device Support

[Tom Spear]

On Wed, Sep 22, 2010 at 2:26 AM, Damjan Jovanovic wrote:

> On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear  wrote:
> > On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic 
> > wrote:
> >>
> >> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear 
> wrote:
> >> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic
> >> > 
> >> > wrote:
> >> >>
> >> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear 
> >> >> wrote:
> >> >> > Attached is the lsusb -v output, trimmed to only include the
> >> >> > pedometer's
> >> >> > info. I have many USB devices, so I didn't want to leave you to
> sort
> >> >> > through
> >> >> > a bunch of useless info.
> >> >> >
> >> >> > I don't have the webcam with me at the moment, but I will see if I
> >> >> > can
> >> >> > find
> >> >> > it when I am at home soon.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Tom
> >> >> >
> >> >> >
> >> >> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> Please send the output of "lsusb -v" first so I can see if it's
> >> >> >> useful.
> >> >> >>
> >> >> >> Thank you for the offer
> >> >> >> Damjan
> >> >> >>
> >> >> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear 
> >> >> >> wrote:
> >> >> >> > Now that I think about it, I have a webcam which the last
> >> >> >> > supported
> >> >> >> > windows
> >> >> >> > version was XP. I'm not using it for anything since I have
> another
> >> >> >> > one
> >> >> >> > which
> >> >> >> > is supported in 7 and linux, but I don't know if it's picked up
> in
> >> >> >> > linux
> >> >> >> > either. I could send it your way too tho.
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > Tom
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear <
> speeddy...@gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> I have a USB pedometer that uploads the data to the internet. I
> >> >> >> >> could
> >> >> >> >> get
> >> >> >> >> another one and the driver software for you to play with. You
> >> >> >> >> have
> >> >> >> >> to
> >> >> >> >> be a
> >> >> >> >> registered member for a monthly fee to get one otherwise, but
> my
> >> >> >> >> job
> >> >> >> >> sponsors anyone that wants to get/stay in shape that works for
> >> >> >> >> them,
> >> >> >> >> so
> >> >> >> >> getting an extra pedometer is fine by me. I have been hoping
> for
> >> >> >> >> an
> >> >> >> >> opportunity to mention that it doesn't work, and this seems
> like
> >> >> >> >> as
> >> >> >> >> good as
> >> >> >> >> any. :-)
> >> >> >> >>
> >> >> >> >> Thanks
> >> >> >> >>
> >> >> >> >> Tom
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
> >> >> >> >> 
> >> >> >> >> wrote:
> >> >> >> >>>
> >> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin
> >> >> >> >>> 
> >> >> >> >>> wrote:
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
> >> >> >> >>> > 
> >> >> >> >>> > wrote:
> >> >> >> >>> >>
> >> >> >> >>> >> When last I heard from Alexander Morozov (October 2009), he
> >> >> >> >>> >> wasn't
> >> >> >> >>> >> working on those patches much, and had no interest in
> sending
> >> >> >> >>> >> them
> >> >> >> >>> >> to
> >> >> >> >>> >> wine-patches.
> >> >> >> >>> >>
> >> >> >> >>> >> I did some work on USB since then, and sent some patches
> >> >> >> >>> >> starting
> >> >> >> >>> >> from
> >> >> >> >>> >> around March 2010 (too many attempts to list, search for
> >> >> >> >>> >> them).
> >> >> >> >>> >> Most
> >> >> >> >>> >> were rejected.
> >> >> >> >>> >>
> >> >> >> >>> >> The USB story goes as follows:
> >> >> >> >>> >>
> >> >> >> >>> >> My libusb patch was rejected IIRC because the libusb
> >> >> >> >>> >> situation
> >> >> >> >>> >> was
> >> >> >> >>> >> unclear. There's the old libusb-0.1 and the new more
> powerful
> >> >> >> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific
> >> >> >> >>> >> variation
> >> >> >> >>> >> of
> >> >> >> >>> >> libusb that had to be detected specifically, and some
> *nixes
> >> >> >> >>> >> didn't
> >> >> >> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself
> only
> >> >> >> >>> >> supports
> >> >> >> >>> >> Linux and MacOS when last I checked, and they were doing a
> >> >> >> >>> >> Windows
> >> >> >> >>> >> port).
> >> >> >> >>> >>
> >> >> >> >>> >> The ntoskrnl that Wine currently emulates is total bogus:
> one
> >> >> >> >>> >> process
> >> >> >> >>> >> per driver, drivers all in separate processes from each
> >> >> >> >>> >> other.
> >> >> >> >>> >> On
> >> >> >> >>> >> Windows there's a single address space for all drivers and
> >> >> >> >>> >> they
> >> >> >> >>> >> can
> >> >> >> >>> >> communicate amongst themselves. I don't think inter-driver
> >> >> >> >>> >> communication is that crucial initially, but it will be
> >> >> >> >>> >> eventually
> >> >> >> >>> >> (eg. last I heard, the iPod driver stacks on top of
> >> >> >> >>> >> USBSTOR.SYS,
> >> >> >> >>> >> and
> >> >> >> >>> >> multi-function USB devices can use a different 

Re: USB Device Support

[Damjan Jovanovic]

On Wed, Sep 22, 2010 at 1:52 AM, Tom Spear  wrote:
> On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic 
> wrote:
>>
>> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear  wrote:
>> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic
>> > 
>> > wrote:
>> >>
>> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear 
>> >> wrote:
>> >> > Attached is the lsusb -v output, trimmed to only include the
>> >> > pedometer's
>> >> > info. I have many USB devices, so I didn't want to leave you to sort
>> >> > through
>> >> > a bunch of useless info.
>> >> >
>> >> > I don't have the webcam with me at the moment, but I will see if I
>> >> > can
>> >> > find
>> >> > it when I am at home soon.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Tom
>> >> >
>> >> >
>> >> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> Please send the output of "lsusb -v" first so I can see if it's
>> >> >> useful.
>> >> >>
>> >> >> Thank you for the offer
>> >> >> Damjan
>> >> >>
>> >> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear 
>> >> >> wrote:
>> >> >> > Now that I think about it, I have a webcam which the last
>> >> >> > supported
>> >> >> > windows
>> >> >> > version was XP. I'm not using it for anything since I have another
>> >> >> > one
>> >> >> > which
>> >> >> > is supported in 7 and linux, but I don't know if it's picked up in
>> >> >> > linux
>> >> >> > either. I could send it your way too tho.
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > Tom
>> >> >> >
>> >> >> >
>> >> >> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I have a USB pedometer that uploads the data to the internet. I
>> >> >> >> could
>> >> >> >> get
>> >> >> >> another one and the driver software for you to play with. You
>> >> >> >> have
>> >> >> >> to
>> >> >> >> be a
>> >> >> >> registered member for a monthly fee to get one otherwise, but my
>> >> >> >> job
>> >> >> >> sponsors anyone that wants to get/stay in shape that works for
>> >> >> >> them,
>> >> >> >> so
>> >> >> >> getting an extra pedometer is fine by me. I have been hoping for
>> >> >> >> an
>> >> >> >> opportunity to mention that it doesn't work, and this seems like
>> >> >> >> as
>> >> >> >> good as
>> >> >> >> any. :-)
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >>
>> >> >> >> Tom
>> >> >> >>
>> >> >> >>
>> >> >> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
>> >> >> >> 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin
>> >> >> >>> 
>> >> >> >>> wrote:
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
>> >> >> >>> > 
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> When last I heard from Alexander Morozov (October 2009), he
>> >> >> >>> >> wasn't
>> >> >> >>> >> working on those patches much, and had no interest in sending
>> >> >> >>> >> them
>> >> >> >>> >> to
>> >> >> >>> >> wine-patches.
>> >> >> >>> >>
>> >> >> >>> >> I did some work on USB since then, and sent some patches
>> >> >> >>> >> starting
>> >> >> >>> >> from
>> >> >> >>> >> around March 2010 (too many attempts to list, search for
>> >> >> >>> >> them).
>> >> >> >>> >> Most
>> >> >> >>> >> were rejected.
>> >> >> >>> >>
>> >> >> >>> >> The USB story goes as follows:
>> >> >> >>> >>
>> >> >> >>> >> My libusb patch was rejected IIRC because the libusb
>> >> >> >>> >> situation
>> >> >> >>> >> was
>> >> >> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
>> >> >> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific
>> >> >> >>> >> variation
>> >> >> >>> >> of
>> >> >> >>> >> libusb that had to be detected specifically, and some *nixes
>> >> >> >>> >> didn't
>> >> >> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
>> >> >> >>> >> supports
>> >> >> >>> >> Linux and MacOS when last I checked, and they were doing a
>> >> >> >>> >> Windows
>> >> >> >>> >> port).
>> >> >> >>> >>
>> >> >> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
>> >> >> >>> >> process
>> >> >> >>> >> per driver, drivers all in separate processes from each
>> >> >> >>> >> other.
>> >> >> >>> >> On
>> >> >> >>> >> Windows there's a single address space for all drivers and
>> >> >> >>> >> they
>> >> >> >>> >> can
>> >> >> >>> >> communicate amongst themselves. I don't think inter-driver
>> >> >> >>> >> communication is that crucial initially, but it will be
>> >> >> >>> >> eventually
>> >> >> >>> >> (eg. last I heard, the iPod driver stacks on top of
>> >> >> >>> >> USBSTOR.SYS,
>> >> >> >>> >> and
>> >> >> >>> >> multi-function USB devices can use a different driver for
>> >> >> >>> >> each
>> >> >> >>> >> interface - these may communicate among themselves with
>> >> >> >>> >> private
>> >> >> >>> >> ioctl
>> >> >> >>> >> requests). The big problem with the multi process situation
>> >> >> >>> >> is
>> >> >> >>> >> hardware sharing: how do you set it up so each driver
>> >> >> >>> >> accesses
>> >> >> >>> >> its
>> >> >> >>> >> own
>> >> >> 

Re: USB Device Support

[Tom Spear]

On Tue, Sep 21, 2010 at 1:41 PM, Damjan Jovanovic wrote:

> On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear  wrote:
> > On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic  >
> > wrote:
> >>
> >> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear 
> wrote:
> >> > Attached is the lsusb -v output, trimmed to only include the
> pedometer's
> >> > info. I have many USB devices, so I didn't want to leave you to sort
> >> > through
> >> > a bunch of useless info.
> >> >
> >> > I don't have the webcam with me at the moment, but I will see if I can
> >> > find
> >> > it when I am at home soon.
> >> >
> >> > Thanks
> >> >
> >> > Tom
> >> >
> >> >
> >> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic <
> damjan@gmail.com>
> >> > wrote:
> >> >>
> >> >> Please send the output of "lsusb -v" first so I can see if it's
> useful.
> >> >>
> >> >> Thank you for the offer
> >> >> Damjan
> >> >>
> >> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear 
> >> >> wrote:
> >> >> > Now that I think about it, I have a webcam which the last supported
> >> >> > windows
> >> >> > version was XP. I'm not using it for anything since I have another
> >> >> > one
> >> >> > which
> >> >> > is supported in 7 and linux, but I don't know if it's picked up in
> >> >> > linux
> >> >> > either. I could send it your way too tho.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > Tom
> >> >> >
> >> >> >
> >> >> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear 
> >> >> > wrote:
> >> >> >>
> >> >> >> I have a USB pedometer that uploads the data to the internet. I
> >> >> >> could
> >> >> >> get
> >> >> >> another one and the driver software for you to play with. You have
> >> >> >> to
> >> >> >> be a
> >> >> >> registered member for a monthly fee to get one otherwise, but my
> job
> >> >> >> sponsors anyone that wants to get/stay in shape that works for
> them,
> >> >> >> so
> >> >> >> getting an extra pedometer is fine by me. I have been hoping for
> an
> >> >> >> opportunity to mention that it doesn't work, and this seems like
> as
> >> >> >> good as
> >> >> >> any. :-)
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Tom
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
> >> >> >> 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  >
> >> >> >>> wrote:
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
> >> >> >>> > 
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >> When last I heard from Alexander Morozov (October 2009), he
> >> >> >>> >> wasn't
> >> >> >>> >> working on those patches much, and had no interest in sending
> >> >> >>> >> them
> >> >> >>> >> to
> >> >> >>> >> wine-patches.
> >> >> >>> >>
> >> >> >>> >> I did some work on USB since then, and sent some patches
> >> >> >>> >> starting
> >> >> >>> >> from
> >> >> >>> >> around March 2010 (too many attempts to list, search for
> them).
> >> >> >>> >> Most
> >> >> >>> >> were rejected.
> >> >> >>> >>
> >> >> >>> >> The USB story goes as follows:
> >> >> >>> >>
> >> >> >>> >> My libusb patch was rejected IIRC because the libusb situation
> >> >> >>> >> was
> >> >> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
> >> >> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific
> variation
> >> >> >>> >> of
> >> >> >>> >> libusb that had to be detected specifically, and some *nixes
> >> >> >>> >> didn't
> >> >> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
> >> >> >>> >> supports
> >> >> >>> >> Linux and MacOS when last I checked, and they were doing a
> >> >> >>> >> Windows
> >> >> >>> >> port).
> >> >> >>> >>
> >> >> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
> >> >> >>> >> process
> >> >> >>> >> per driver, drivers all in separate processes from each other.
> >> >> >>> >> On
> >> >> >>> >> Windows there's a single address space for all drivers and
> they
> >> >> >>> >> can
> >> >> >>> >> communicate amongst themselves. I don't think inter-driver
> >> >> >>> >> communication is that crucial initially, but it will be
> >> >> >>> >> eventually
> >> >> >>> >> (eg. last I heard, the iPod driver stacks on top of
> USBSTOR.SYS,
> >> >> >>> >> and
> >> >> >>> >> multi-function USB devices can use a different driver for each
> >> >> >>> >> interface - these may communicate among themselves with
> private
> >> >> >>> >> ioctl
> >> >> >>> >> requests). The big problem with the multi process situation is
> >> >> >>> >> hardware sharing: how do you set it up so each driver accesses
> >> >> >>> >> its
> >> >> >>> >> own
> >> >> >>> >> and only its own hardware?
> >> >> >>> >>
> >> >> >>> >> Drivers either start on system startup (Wine starts those with
> >> >> >>> >> the
> >> >> >>> >> first process that starts), or get loaded on-demand as the
> >> >> >>> >> hardware
> >> >> >>> >> is
> >> >> >>> >> plugged in. Most drivers should install themselves to be
> loaded
> >> >> >>> >> on-demand. Who loads those and how?
> >> >> >>> >>
> >> >> >

Re: USB Device Support

[Damjan Jovanovic]

On Tue, Sep 21, 2010 at 8:07 PM, Tom Spear  wrote:
> On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic 
> wrote:
>>
>> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear  wrote:
>> > Attached is the lsusb -v output, trimmed to only include the pedometer's
>> > info. I have many USB devices, so I didn't want to leave you to sort
>> > through
>> > a bunch of useless info.
>> >
>> > I don't have the webcam with me at the moment, but I will see if I can
>> > find
>> > it when I am at home soon.
>> >
>> > Thanks
>> >
>> > Tom
>> >
>> >
>> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic 
>> > wrote:
>> >>
>> >> Please send the output of "lsusb -v" first so I can see if it's useful.
>> >>
>> >> Thank you for the offer
>> >> Damjan
>> >>
>> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear 
>> >> wrote:
>> >> > Now that I think about it, I have a webcam which the last supported
>> >> > windows
>> >> > version was XP. I'm not using it for anything since I have another
>> >> > one
>> >> > which
>> >> > is supported in 7 and linux, but I don't know if it's picked up in
>> >> > linux
>> >> > either. I could send it your way too tho.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Tom
>> >> >
>> >> >
>> >> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear 
>> >> > wrote:
>> >> >>
>> >> >> I have a USB pedometer that uploads the data to the internet. I
>> >> >> could
>> >> >> get
>> >> >> another one and the driver software for you to play with. You have
>> >> >> to
>> >> >> be a
>> >> >> registered member for a monthly fee to get one otherwise, but my job
>> >> >> sponsors anyone that wants to get/stay in shape that works for them,
>> >> >> so
>> >> >> getting an extra pedometer is fine by me. I have been hoping for an
>> >> >> opportunity to mention that it doesn't work, and this seems like as
>> >> >> good as
>> >> >> any. :-)
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Tom
>> >> >>
>> >> >>
>> >> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin 
>> >> >>> wrote:
>> >> >>> >
>> >> >>> >
>> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> When last I heard from Alexander Morozov (October 2009), he
>> >> >>> >> wasn't
>> >> >>> >> working on those patches much, and had no interest in sending
>> >> >>> >> them
>> >> >>> >> to
>> >> >>> >> wine-patches.
>> >> >>> >>
>> >> >>> >> I did some work on USB since then, and sent some patches
>> >> >>> >> starting
>> >> >>> >> from
>> >> >>> >> around March 2010 (too many attempts to list, search for them).
>> >> >>> >> Most
>> >> >>> >> were rejected.
>> >> >>> >>
>> >> >>> >> The USB story goes as follows:
>> >> >>> >>
>> >> >>> >> My libusb patch was rejected IIRC because the libusb situation
>> >> >>> >> was
>> >> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
>> >> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation
>> >> >>> >> of
>> >> >>> >> libusb that had to be detected specifically, and some *nixes
>> >> >>> >> didn't
>> >> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
>> >> >>> >> supports
>> >> >>> >> Linux and MacOS when last I checked, and they were doing a
>> >> >>> >> Windows
>> >> >>> >> port).
>> >> >>> >>
>> >> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
>> >> >>> >> process
>> >> >>> >> per driver, drivers all in separate processes from each other.
>> >> >>> >> On
>> >> >>> >> Windows there's a single address space for all drivers and they
>> >> >>> >> can
>> >> >>> >> communicate amongst themselves. I don't think inter-driver
>> >> >>> >> communication is that crucial initially, but it will be
>> >> >>> >> eventually
>> >> >>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS,
>> >> >>> >> and
>> >> >>> >> multi-function USB devices can use a different driver for each
>> >> >>> >> interface - these may communicate among themselves with private
>> >> >>> >> ioctl
>> >> >>> >> requests). The big problem with the multi process situation is
>> >> >>> >> hardware sharing: how do you set it up so each driver accesses
>> >> >>> >> its
>> >> >>> >> own
>> >> >>> >> and only its own hardware?
>> >> >>> >>
>> >> >>> >> Drivers either start on system startup (Wine starts those with
>> >> >>> >> the
>> >> >>> >> first process that starts), or get loaded on-demand as the
>> >> >>> >> hardware
>> >> >>> >> is
>> >> >>> >> plugged in. Most drivers should install themselves to be loaded
>> >> >>> >> on-demand. Who loads those and how?
>> >> >>> >>
>> >> >>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on
>> >> >>> >> demand.
>> >> >>> >> Alexandre didn't want that dll because it exports nothing (all
>> >> >>> >> its
>> >> >>> >> features are accessible via internal ioctls), and suggested
>> >> >>> >> adding
>> >> >>> >> the
>> >> >>> >> features to USBD.SYS instead, which we already have and which
>> >> >>> >> has

Re: USB Device Support

[Tom Spear]

On Tue, Sep 21, 2010 at 11:04 AM, Damjan Jovanovic wrote:

> On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear  wrote:
> > Attached is the lsusb -v output, trimmed to only include the pedometer's
> > info. I have many USB devices, so I didn't want to leave you to sort
> through
> > a bunch of useless info.
> >
> > I don't have the webcam with me at the moment, but I will see if I can
> find
> > it when I am at home soon.
> >
> > Thanks
> >
> > Tom
> >
> >
> > On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic 
> > wrote:
> >>
> >> Please send the output of "lsusb -v" first so I can see if it's useful.
> >>
> >> Thank you for the offer
> >> Damjan
> >>
> >> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear 
> wrote:
> >> > Now that I think about it, I have a webcam which the last supported
> >> > windows
> >> > version was XP. I'm not using it for anything since I have another one
> >> > which
> >> > is supported in 7 and linux, but I don't know if it's picked up in
> linux
> >> > either. I could send it your way too tho.
> >> >
> >> > Thanks
> >> >
> >> > Tom
> >> >
> >> >
> >> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear 
> wrote:
> >> >>
> >> >> I have a USB pedometer that uploads the data to the internet. I could
> >> >> get
> >> >> another one and the driver software for you to play with. You have to
> >> >> be a
> >> >> registered member for a monthly fee to get one otherwise, but my job
> >> >> sponsors anyone that wants to get/stay in shape that works for them,
> so
> >> >> getting an extra pedometer is fine by me. I have been hoping for an
> >> >> opportunity to mention that it doesn't work, and this seems like as
> >> >> good as
> >> >> any. :-)
> >> >>
> >> >> Thanks
> >> >>
> >> >> Tom
> >> >>
> >> >>
> >> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
> >> >> 
> >> >> wrote:
> >> >>>
> >> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin 
> >> >>> wrote:
> >> >>> >
> >> >>> >
> >> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
> >> >>> > 
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> When last I heard from Alexander Morozov (October 2009), he
> wasn't
> >> >>> >> working on those patches much, and had no interest in sending
> them
> >> >>> >> to
> >> >>> >> wine-patches.
> >> >>> >>
> >> >>> >> I did some work on USB since then, and sent some patches starting
> >> >>> >> from
> >> >>> >> around March 2010 (too many attempts to list, search for them).
> >> >>> >> Most
> >> >>> >> were rejected.
> >> >>> >>
> >> >>> >> The USB story goes as follows:
> >> >>> >>
> >> >>> >> My libusb patch was rejected IIRC because the libusb situation
> was
> >> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
> >> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation
> of
> >> >>> >> libusb that had to be detected specifically, and some *nixes
> didn't
> >> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
> >> >>> >> supports
> >> >>> >> Linux and MacOS when last I checked, and they were doing a
> Windows
> >> >>> >> port).
> >> >>> >>
> >> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
> >> >>> >> process
> >> >>> >> per driver, drivers all in separate processes from each other. On
> >> >>> >> Windows there's a single address space for all drivers and they
> can
> >> >>> >> communicate amongst themselves. I don't think inter-driver
> >> >>> >> communication is that crucial initially, but it will be
> eventually
> >> >>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS,
> >> >>> >> and
> >> >>> >> multi-function USB devices can use a different driver for each
> >> >>> >> interface - these may communicate among themselves with private
> >> >>> >> ioctl
> >> >>> >> requests). The big problem with the multi process situation is
> >> >>> >> hardware sharing: how do you set it up so each driver accesses
> its
> >> >>> >> own
> >> >>> >> and only its own hardware?
> >> >>> >>
> >> >>> >> Drivers either start on system startup (Wine starts those with
> the
> >> >>> >> first process that starts), or get loaded on-demand as the
> hardware
> >> >>> >> is
> >> >>> >> plugged in. Most drivers should install themselves to be loaded
> >> >>> >> on-demand. Who loads those and how?
> >> >>> >>
> >> >>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on
> >> >>> >> demand.
> >> >>> >> Alexandre didn't want that dll because it exports nothing (all
> its
> >> >>> >> features are accessible via internal ioctls), and suggested
> adding
> >> >>> >> the
> >> >>> >> features to USBD.SYS instead, which we already have and which has
> >> >>> >> exports. Now USBD.SYS is linked to by most (but not all) USB
> >> >>> >> drivers
> >> >>> >> so (most of the time) it automatically gets loaded into each one
> -
> >> >>> >> great right? - but it has no idea which driver it got loaded
> with,
> >> >>> >> nor
> >> >>> >> a straightforward way to determine which device(s!) that driver
> >> >>> >> wants
> >> >>> >> to drive. Also, since most drive

Re: USB Device Support

[Erich Hoover]

On Tue, Sep 21, 2010 at 10:04 AM, Damjan Jovanovic  wrote:
> ...
> I'll get working on the basics of USB first. If the device doesn't
> work on your tests after that, SSH access might be quicker and easier
> than intercontinental shipping.

That's an interesting plan... If you're interested I might be able to
convince the powers that be here to permit you SSH access to a machine
connected to a ZEMAX license key (a SafeNet Sentinel USB key).  It's a
vendor-specific device but all the software is freely download-able.

Erich Hoover
ehoo...@mines.edu

Re: USB Device Support

[Damjan Jovanovic]

On Tue, Sep 21, 2010 at 5:04 PM, Tom Spear  wrote:
> Attached is the lsusb -v output, trimmed to only include the pedometer's
> info. I have many USB devices, so I didn't want to leave you to sort through
> a bunch of useless info.
>
> I don't have the webcam with me at the moment, but I will see if I can find
> it when I am at home soon.
>
> Thanks
>
> Tom
>
>
> On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic 
> wrote:
>>
>> Please send the output of "lsusb -v" first so I can see if it's useful.
>>
>> Thank you for the offer
>> Damjan
>>
>> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear  wrote:
>> > Now that I think about it, I have a webcam which the last supported
>> > windows
>> > version was XP. I'm not using it for anything since I have another one
>> > which
>> > is supported in 7 and linux, but I don't know if it's picked up in linux
>> > either. I could send it your way too tho.
>> >
>> > Thanks
>> >
>> > Tom
>> >
>> >
>> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear  wrote:
>> >>
>> >> I have a USB pedometer that uploads the data to the internet. I could
>> >> get
>> >> another one and the driver software for you to play with. You have to
>> >> be a
>> >> registered member for a monthly fee to get one otherwise, but my job
>> >> sponsors anyone that wants to get/stay in shape that works for them, so
>> >> getting an extra pedometer is fine by me. I have been hoping for an
>> >> opportunity to mention that it doesn't work, and this seems like as
>> >> good as
>> >> any. :-)
>> >>
>> >> Thanks
>> >>
>> >> Tom
>> >>
>> >>
>> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic
>> >> 
>> >> wrote:
>> >>>
>> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin 
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> When last I heard from Alexander Morozov (October 2009), he wasn't
>> >>> >> working on those patches much, and had no interest in sending them
>> >>> >> to
>> >>> >> wine-patches.
>> >>> >>
>> >>> >> I did some work on USB since then, and sent some patches starting
>> >>> >> from
>> >>> >> around March 2010 (too many attempts to list, search for them).
>> >>> >> Most
>> >>> >> were rejected.
>> >>> >>
>> >>> >> The USB story goes as follows:
>> >>> >>
>> >>> >> My libusb patch was rejected IIRC because the libusb situation was
>> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
>> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of
>> >>> >> libusb that had to be detected specifically, and some *nixes didn't
>> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
>> >>> >> supports
>> >>> >> Linux and MacOS when last I checked, and they were doing a Windows
>> >>> >> port).
>> >>> >>
>> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
>> >>> >> process
>> >>> >> per driver, drivers all in separate processes from each other. On
>> >>> >> Windows there's a single address space for all drivers and they can
>> >>> >> communicate amongst themselves. I don't think inter-driver
>> >>> >> communication is that crucial initially, but it will be eventually
>> >>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS,
>> >>> >> and
>> >>> >> multi-function USB devices can use a different driver for each
>> >>> >> interface - these may communicate among themselves with private
>> >>> >> ioctl
>> >>> >> requests). The big problem with the multi process situation is
>> >>> >> hardware sharing: how do you set it up so each driver accesses its
>> >>> >> own
>> >>> >> and only its own hardware?
>> >>> >>
>> >>> >> Drivers either start on system startup (Wine starts those with the
>> >>> >> first process that starts), or get loaded on-demand as the hardware
>> >>> >> is
>> >>> >> plugged in. Most drivers should install themselves to be loaded
>> >>> >> on-demand. Who loads those and how?
>> >>> >>
>> >>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on
>> >>> >> demand.
>> >>> >> Alexandre didn't want that dll because it exports nothing (all its
>> >>> >> features are accessible via internal ioctls), and suggested adding
>> >>> >> the
>> >>> >> features to USBD.SYS instead, which we already have and which has
>> >>> >> exports. Now USBD.SYS is linked to by most (but not all) USB
>> >>> >> drivers
>> >>> >> so (most of the time) it automatically gets loaded into each one -
>> >>> >> great right? - but it has no idea which driver it got loaded with,
>> >>> >> nor
>> >>> >> a straightforward way to determine which device(s!) that driver
>> >>> >> wants
>> >>> >> to drive. Also, since most drivers only load on-demand, the driver
>> >>> >> will never load, and thus this won't work unless we load those
>> >>> >> drivers
>> >>> >> on startup instead. The other approach, which I tried, was to get
>> >>> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them
>> >>> >> to
>> >>> >> a loaded-on-startup instance of USBHUB.SYS

Re: USB Device Support

[Tom Spear]

Attached is the lsusb -v output, trimmed to only include the pedometer's
info. I have many USB devices, so I didn't want to leave you to sort through
a bunch of useless info.

I don't have the webcam with me at the moment, but I will see if I can find
it when I am at home soon.

Thanks

Tom


On Tue, Sep 21, 2010 at 9:32 AM, Damjan Jovanovic wrote:

> Please send the output of "lsusb -v" first so I can see if it's useful.
>
> Thank you for the offer
> Damjan
>
> On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear  wrote:
> > Now that I think about it, I have a webcam which the last supported
> windows
> > version was XP. I'm not using it for anything since I have another one
> which
> > is supported in 7 and linux, but I don't know if it's picked up in linux
> > either. I could send it your way too tho.
> >
> > Thanks
> >
> > Tom
> >
> >
> > On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear  wrote:
> >>
> >> I have a USB pedometer that uploads the data to the internet. I could
> get
> >> another one and the driver software for you to play with. You have to be
> a
> >> registered member for a monthly fee to get one otherwise, but my job
> >> sponsors anyone that wants to get/stay in shape that works for them, so
> >> getting an extra pedometer is fine by me. I have been hoping for an
> >> opportunity to mention that it doesn't work, and this seems like as good
> as
> >> any. :-)
> >>
> >> Thanks
> >>
> >> Tom
> >>
> >>
> >> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic  >
> >> wrote:
> >>>
> >>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin 
> wrote:
> >>> >
> >>> >
> >>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> When last I heard from Alexander Morozov (October 2009), he wasn't
> >>> >> working on those patches much, and had no interest in sending them
> to
> >>> >> wine-patches.
> >>> >>
> >>> >> I did some work on USB since then, and sent some patches starting
> from
> >>> >> around March 2010 (too many attempts to list, search for them). Most
> >>> >> were rejected.
> >>> >>
> >>> >> The USB story goes as follows:
> >>> >>
> >>> >> My libusb patch was rejected IIRC because the libusb situation was
> >>> >> unclear. There's the old libusb-0.1 and the new more powerful
> >>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of
> >>> >> libusb that had to be detected specifically, and some *nixes didn't
> >>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only
> supports
> >>> >> Linux and MacOS when last I checked, and they were doing a Windows
> >>> >> port).
> >>> >>
> >>> >> The ntoskrnl that Wine currently emulates is total bogus: one
> process
> >>> >> per driver, drivers all in separate processes from each other. On
> >>> >> Windows there's a single address space for all drivers and they can
> >>> >> communicate amongst themselves. I don't think inter-driver
> >>> >> communication is that crucial initially, but it will be eventually
> >>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
> >>> >> multi-function USB devices can use a different driver for each
> >>> >> interface - these may communicate among themselves with private
> ioctl
> >>> >> requests). The big problem with the multi process situation is
> >>> >> hardware sharing: how do you set it up so each driver accesses its
> own
> >>> >> and only its own hardware?
> >>> >>
> >>> >> Drivers either start on system startup (Wine starts those with the
> >>> >> first process that starts), or get loaded on-demand as the hardware
> is
> >>> >> plugged in. Most drivers should install themselves to be loaded
> >>> >> on-demand. Who loads those and how?
> >>> >>
> >>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
> >>> >> Alexandre didn't want that dll because it exports nothing (all its
> >>> >> features are accessible via internal ioctls), and suggested adding
> the
> >>> >> features to USBD.SYS instead, which we already have and which has
> >>> >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers
> >>> >> so (most of the time) it automatically gets loaded into each one -
> >>> >> great right? - but it has no idea which driver it got loaded with,
> nor
> >>> >> a straightforward way to determine which device(s!) that driver
> wants
> >>> >> to drive. Also, since most drivers only load on-demand, the driver
> >>> >> will never load, and thus this won't work unless we load those
> drivers
> >>> >> on startup instead. The other approach, which I tried, was to get
> >>> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them
> to
> >>> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private
> ioctl,
> >>> >> which would detect the driver for the device and launch a new
> instance
> >>> >> of itself that would make a device object and load the driver to
> >>> >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment
> >>> >> variables to tell the child which device and driver to 

Re: USB Device Support

[Damjan Jovanovic]

Please send the output of "lsusb -v" first so I can see if it's useful.

Thank you for the offer
Damjan

On Tue, Sep 21, 2010 at 3:58 PM, Tom Spear  wrote:
> Now that I think about it, I have a webcam which the last supported windows
> version was XP. I'm not using it for anything since I have another one which
> is supported in 7 and linux, but I don't know if it's picked up in linux
> either. I could send it your way too tho.
>
> Thanks
>
> Tom
>
>
> On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear  wrote:
>>
>> I have a USB pedometer that uploads the data to the internet. I could get
>> another one and the driver software for you to play with. You have to be a
>> registered member for a monthly fee to get one otherwise, but my job
>> sponsors anyone that wants to get/stay in shape that works for them, so
>> getting an extra pedometer is fine by me. I have been hoping for an
>> opportunity to mention that it doesn't work, and this seems like as good as
>> any. :-)
>>
>> Thanks
>>
>> Tom
>>
>>
>> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic 
>> wrote:
>>>
>>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  wrote:
>>> >
>>> >
>>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic
>>> > 
>>> > wrote:
>>> >>
>>> >> When last I heard from Alexander Morozov (October 2009), he wasn't
>>> >> working on those patches much, and had no interest in sending them to
>>> >> wine-patches.
>>> >>
>>> >> I did some work on USB since then, and sent some patches starting from
>>> >> around March 2010 (too many attempts to list, search for them). Most
>>> >> were rejected.
>>> >>
>>> >> The USB story goes as follows:
>>> >>
>>> >> My libusb patch was rejected IIRC because the libusb situation was
>>> >> unclear. There's the old libusb-0.1 and the new more powerful
>>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of
>>> >> libusb that had to be detected specifically, and some *nixes didn't
>>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only supports
>>> >> Linux and MacOS when last I checked, and they were doing a Windows
>>> >> port).
>>> >>
>>> >> The ntoskrnl that Wine currently emulates is total bogus: one process
>>> >> per driver, drivers all in separate processes from each other. On
>>> >> Windows there's a single address space for all drivers and they can
>>> >> communicate amongst themselves. I don't think inter-driver
>>> >> communication is that crucial initially, but it will be eventually
>>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
>>> >> multi-function USB devices can use a different driver for each
>>> >> interface - these may communicate among themselves with private ioctl
>>> >> requests). The big problem with the multi process situation is
>>> >> hardware sharing: how do you set it up so each driver accesses its own
>>> >> and only its own hardware?
>>> >>
>>> >> Drivers either start on system startup (Wine starts those with the
>>> >> first process that starts), or get loaded on-demand as the hardware is
>>> >> plugged in. Most drivers should install themselves to be loaded
>>> >> on-demand. Who loads those and how?
>>> >>
>>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
>>> >> Alexandre didn't want that dll because it exports nothing (all its
>>> >> features are accessible via internal ioctls), and suggested adding the
>>> >> features to USBD.SYS instead, which we already have and which has
>>> >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers
>>> >> so (most of the time) it automatically gets loaded into each one -
>>> >> great right? - but it has no idea which driver it got loaded with, nor
>>> >> a straightforward way to determine which device(s!) that driver wants
>>> >> to drive. Also, since most drivers only load on-demand, the driver
>>> >> will never load, and thus this won't work unless we load those drivers
>>> >> on startup instead. The other approach, which I tried, was to get
>>> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
>>> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
>>> >> which would detect the driver for the device and launch a new instance
>>> >> of itself that would make a device object and load the driver to
>>> >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment
>>> >> variables to tell the child which device and driver to run) and
>>> >> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
>>> >> patch did things the Windows way: all drivers in one ntoskrnl process
>>> >> - this won't work properly in Wine for years, if ever, since ntoskrnl
>>> >> is so incomplete and one bad driver will crash them all. Another
>>> >> possibility could be to keep drivers in separate processes, but allow
>>> >> inter-process communication, but I see serializing IRPs between
>>> >> processes as being complex and very slow.
>>> >>
>>> >> Driver installation is also quite a mission. Windows d

Re: USB Device Support

[Tom Spear]

Now that I think about it, I have a webcam which the last supported windows
version was XP. I'm not using it for anything since I have another one which
is supported in 7 and linux, but I don't know if it's picked up in linux
either. I could send it your way too tho.

Thanks

Tom


On Tue, Sep 21, 2010 at 8:54 AM, Tom Spear  wrote:

> I have a USB pedometer that uploads the data to the internet. I could get
> another one and the driver software for you to play with. You have to be a
> registered member for a monthly fee to get one otherwise, but my job
> sponsors anyone that wants to get/stay in shape that works for them, so
> getting an extra pedometer is fine by me. I have been hoping for an
> opportunity to mention that it doesn't work, and this seems like as good as
> any. :-)
>
> Thanks
>
> Tom
>
>
>
> On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic wrote:
>
>> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  wrote:
>> >
>> >
>> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic <
>> damjan@gmail.com>
>> > wrote:
>> >>
>> >> When last I heard from Alexander Morozov (October 2009), he wasn't
>> >> working on those patches much, and had no interest in sending them to
>> >> wine-patches.
>> >>
>> >> I did some work on USB since then, and sent some patches starting from
>> >> around March 2010 (too many attempts to list, search for them). Most
>> >> were rejected.
>> >>
>> >> The USB story goes as follows:
>> >>
>> >> My libusb patch was rejected IIRC because the libusb situation was
>> >> unclear. There's the old libusb-0.1 and the new more powerful
>> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of
>> >> libusb that had to be detected specifically, and some *nixes didn't
>> >> support the libusb-1.0 interface yet (libusb-1.0 itself only supports
>> >> Linux and MacOS when last I checked, and they were doing a Windows
>> >> port).
>> >>
>> >> The ntoskrnl that Wine currently emulates is total bogus: one process
>> >> per driver, drivers all in separate processes from each other. On
>> >> Windows there's a single address space for all drivers and they can
>> >> communicate amongst themselves. I don't think inter-driver
>> >> communication is that crucial initially, but it will be eventually
>> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
>> >> multi-function USB devices can use a different driver for each
>> >> interface - these may communicate among themselves with private ioctl
>> >> requests). The big problem with the multi process situation is
>> >> hardware sharing: how do you set it up so each driver accesses its own
>> >> and only its own hardware?
>> >>
>> >> Drivers either start on system startup (Wine starts those with the
>> >> first process that starts), or get loaded on-demand as the hardware is
>> >> plugged in. Most drivers should install themselves to be loaded
>> >> on-demand. Who loads those and how?
>> >>
>> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
>> >> Alexandre didn't want that dll because it exports nothing (all its
>> >> features are accessible via internal ioctls), and suggested adding the
>> >> features to USBD.SYS instead, which we already have and which has
>> >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers
>> >> so (most of the time) it automatically gets loaded into each one -
>> >> great right? - but it has no idea which driver it got loaded with, nor
>> >> a straightforward way to determine which device(s!) that driver wants
>> >> to drive. Also, since most drivers only load on-demand, the driver
>> >> will never load, and thus this won't work unless we load those drivers
>> >> on startup instead. The other approach, which I tried, was to get
>> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
>> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
>> >> which would detect the driver for the device and launch a new instance
>> >> of itself that would make a device object and load the driver to
>> >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment
>> >> variables to tell the child which device and driver to run) and
>> >> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
>> >> patch did things the Windows way: all drivers in one ntoskrnl process
>> >> - this won't work properly in Wine for years, if ever, since ntoskrnl
>> >> is so incomplete and one bad driver will crash them all. Another
>> >> possibility could be to keep drivers in separate processes, but allow
>> >> inter-process communication, but I see serializing IRPs between
>> >> processes as being complex and very slow.
>> >>
>> >> Driver installation is also quite a mission. Windows detects that the
>> >> hardware doesn't have a driver installed, and then generates the
>> >> device ID and compatible IDs and searches .INF files for one that can
>> >> support it. Our setupapi needs to be substantially improved to be able
>

Re: USB Device Support

[Tom Spear]

I have a USB pedometer that uploads the data to the internet. I could get
another one and the driver software for you to play with. You have to be a
registered member for a monthly fee to get one otherwise, but my job
sponsors anyone that wants to get/stay in shape that works for them, so
getting an extra pedometer is fine by me. I have been hoping for an
opportunity to mention that it doesn't work, and this seems like as good as
any. :-)

Thanks

Tom


On Tue, Sep 21, 2010 at 5:03 AM, Damjan Jovanovic wrote:

> On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  wrote:
> >
> >
> > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic  >
> > wrote:
> >>
> >> When last I heard from Alexander Morozov (October 2009), he wasn't
> >> working on those patches much, and had no interest in sending them to
> >> wine-patches.
> >>
> >> I did some work on USB since then, and sent some patches starting from
> >> around March 2010 (too many attempts to list, search for them). Most
> >> were rejected.
> >>
> >> The USB story goes as follows:
> >>
> >> My libusb patch was rejected IIRC because the libusb situation was
> >> unclear. There's the old libusb-0.1 and the new more powerful
> >> libusb-1.0. IIRC each *nix hacked up its own specific variation of
> >> libusb that had to be detected specifically, and some *nixes didn't
> >> support the libusb-1.0 interface yet (libusb-1.0 itself only supports
> >> Linux and MacOS when last I checked, and they were doing a Windows
> >> port).
> >>
> >> The ntoskrnl that Wine currently emulates is total bogus: one process
> >> per driver, drivers all in separate processes from each other. On
> >> Windows there's a single address space for all drivers and they can
> >> communicate amongst themselves. I don't think inter-driver
> >> communication is that crucial initially, but it will be eventually
> >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
> >> multi-function USB devices can use a different driver for each
> >> interface - these may communicate among themselves with private ioctl
> >> requests). The big problem with the multi process situation is
> >> hardware sharing: how do you set it up so each driver accesses its own
> >> and only its own hardware?
> >>
> >> Drivers either start on system startup (Wine starts those with the
> >> first process that starts), or get loaded on-demand as the hardware is
> >> plugged in. Most drivers should install themselves to be loaded
> >> on-demand. Who loads those and how?
> >>
> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
> >> Alexandre didn't want that dll because it exports nothing (all its
> >> features are accessible via internal ioctls), and suggested adding the
> >> features to USBD.SYS instead, which we already have and which has
> >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers
> >> so (most of the time) it automatically gets loaded into each one -
> >> great right? - but it has no idea which driver it got loaded with, nor
> >> a straightforward way to determine which device(s!) that driver wants
> >> to drive. Also, since most drivers only load on-demand, the driver
> >> will never load, and thus this won't work unless we load those drivers
> >> on startup instead. The other approach, which I tried, was to get
> >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
> >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
> >> which would detect the driver for the device and launch a new instance
> >> of itself that would make a device object and load the driver to
> >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment
> >> variables to tell the child which device and driver to run) and
> >> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
> >> patch did things the Windows way: all drivers in one ntoskrnl process
> >> - this won't work properly in Wine for years, if ever, since ntoskrnl
> >> is so incomplete and one bad driver will crash them all. Another
> >> possibility could be to keep drivers in separate processes, but allow
> >> inter-process communication, but I see serializing IRPs between
> >> processes as being complex and very slow.
> >>
> >> Driver installation is also quite a mission. Windows detects that the
> >> hardware doesn't have a driver installed, and then generates the
> >> device ID and compatible IDs and searches .INF files for one that can
> >> support it. Our setupapi needs to be substantially improved to be able
> >> to do the same, and some newdev.dll and manual INF parsing work to
> >> install the driver may also be necessary, and I can already think of
> >> cases where even class installers will be necessary too :-(.
> >>
> >> Wine only sends DeviceIoControl to drivers. For anything non-trivial,
> >> other file-related user-space functions (at least ReadFile, WriteFile)
> >> need to go to the driver too. The infrastructure for this does not
> >> even exist y

Re: USB Device Support

[Damjan Jovanovic]

On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin  wrote:
>
>
> On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic 
> wrote:
>>
>> When last I heard from Alexander Morozov (October 2009), he wasn't
>> working on those patches much, and had no interest in sending them to
>> wine-patches.
>>
>> I did some work on USB since then, and sent some patches starting from
>> around March 2010 (too many attempts to list, search for them). Most
>> were rejected.
>>
>> The USB story goes as follows:
>>
>> My libusb patch was rejected IIRC because the libusb situation was
>> unclear. There's the old libusb-0.1 and the new more powerful
>> libusb-1.0. IIRC each *nix hacked up its own specific variation of
>> libusb that had to be detected specifically, and some *nixes didn't
>> support the libusb-1.0 interface yet (libusb-1.0 itself only supports
>> Linux and MacOS when last I checked, and they were doing a Windows
>> port).
>>
>> The ntoskrnl that Wine currently emulates is total bogus: one process
>> per driver, drivers all in separate processes from each other. On
>> Windows there's a single address space for all drivers and they can
>> communicate amongst themselves. I don't think inter-driver
>> communication is that crucial initially, but it will be eventually
>> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
>> multi-function USB devices can use a different driver for each
>> interface - these may communicate among themselves with private ioctl
>> requests). The big problem with the multi process situation is
>> hardware sharing: how do you set it up so each driver accesses its own
>> and only its own hardware?
>>
>> Drivers either start on system startup (Wine starts those with the
>> first process that starts), or get loaded on-demand as the hardware is
>> plugged in. Most drivers should install themselves to be loaded
>> on-demand. Who loads those and how?
>>
>> Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
>> Alexandre didn't want that dll because it exports nothing (all its
>> features are accessible via internal ioctls), and suggested adding the
>> features to USBD.SYS instead, which we already have and which has
>> exports. Now USBD.SYS is linked to by most (but not all) USB drivers
>> so (most of the time) it automatically gets loaded into each one -
>> great right? - but it has no idea which driver it got loaded with, nor
>> a straightforward way to determine which device(s!) that driver wants
>> to drive. Also, since most drivers only load on-demand, the driver
>> will never load, and thus this won't work unless we load those drivers
>> on startup instead. The other approach, which I tried, was to get
>> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
>> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
>> which would detect the driver for the device and launch a new instance
>> of itself that would make a device object and load the driver to
>> attach to it. This was all a bit a hack (USBHUB.SYS uses environment
>> variables to tell the child which device and driver to run) and
>> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
>> patch did things the Windows way: all drivers in one ntoskrnl process
>> - this won't work properly in Wine for years, if ever, since ntoskrnl
>> is so incomplete and one bad driver will crash them all. Another
>> possibility could be to keep drivers in separate processes, but allow
>> inter-process communication, but I see serializing IRPs between
>> processes as being complex and very slow.
>>
>> Driver installation is also quite a mission. Windows detects that the
>> hardware doesn't have a driver installed, and then generates the
>> device ID and compatible IDs and searches .INF files for one that can
>> support it. Our setupapi needs to be substantially improved to be able
>> to do the same, and some newdev.dll and manual INF parsing work to
>> install the driver may also be necessary, and I can already think of
>> cases where even class installers will be necessary too :-(.
>>
>> Wine only sends DeviceIoControl to drivers. For anything non-trivial,
>> other file-related user-space functions (at least ReadFile, WriteFile)
>> need to go to the driver too. The infrastructure for this does not
>> even exist yet, and would probably affects wineserver as well.
>>
>> Regression tests for ntosnkrl.exe and kernel drivers don't exist, and
>> are difficult to come up with, since we'd have to compile and load
>> drivers on Windows and run tests that don't crash Windows :-).
>>
>> So the architecture for USB support is tricky to say the least. But
>> I'd still like to resume work on my USB patches some time soon, would
>> you like to help?
>
> I'd be willing to help if you want some assistance. I don't know much about
> the subject yet, but I'm reading  programming the wdm atm.

Firstly I'd like to find a cheap simple USB device that we can
actually get working quickly. Earlier 

Re: USB Device Support

[Alexander Morozov]

> Before I go off and try to update your USB device support for the latest
> Wine release, are you continuing to maintain this code current to the Wine
> Development and Wine Stable trunks?
I will update patches.

Thanks,
Alexander

Re: USB Device Support

[Damjan Jovanovic]

When last I heard from Alexander Morozov (October 2009), he wasn't
working on those patches much, and had no interest in sending them to
wine-patches.

I did some work on USB since then, and sent some patches starting from
around March 2010 (too many attempts to list, search for them). Most
were rejected.

The USB story goes as follows:

My libusb patch was rejected IIRC because the libusb situation was
unclear. There's the old libusb-0.1 and the new more powerful
libusb-1.0. IIRC each *nix hacked up its own specific variation of
libusb that had to be detected specifically, and some *nixes didn't
support the libusb-1.0 interface yet (libusb-1.0 itself only supports
Linux and MacOS when last I checked, and they were doing a Windows
port).

The ntoskrnl that Wine currently emulates is total bogus: one process
per driver, drivers all in separate processes from each other. On
Windows there's a single address space for all drivers and they can
communicate amongst themselves. I don't think inter-driver
communication is that crucial initially, but it will be eventually
(eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and
multi-function USB devices can use a different driver for each
interface - these may communicate among themselves with private ioctl
requests). The big problem with the multi process situation is
hardware sharing: how do you set it up so each driver accesses its own
and only its own hardware?

Drivers either start on system startup (Wine starts those with the
first process that starts), or get loaded on-demand as the hardware is
plugged in. Most drivers should install themselves to be loaded
on-demand. Who loads those and how?

Windows uses USBHUB.SYS to do device I/O and load drivers on demand.
Alexandre didn't want that dll because it exports nothing (all its
features are accessible via internal ioctls), and suggested adding the
features to USBD.SYS instead, which we already have and which has
exports. Now USBD.SYS is linked to by most (but not all) USB drivers
so (most of the time) it automatically gets loaded into each one -
great right? - but it has no idea which driver it got loaded with, nor
a straightforward way to determine which device(s!) that driver wants
to drive. Also, since most drivers only load on-demand, the driver
will never load, and thus this won't work unless we load those drivers
on startup instead. The other approach, which I tried, was to get
Wine's mountmgr.sys to detect USB devices using HAL, then pass them to
a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl,
which would detect the driver for the device and launch a new instance
of itself that would make a device object and load the driver to
attach to it. This was all a bit a hack (USBHUB.SYS uses environment
variables to tell the child which device and driver to run) and
Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's
patch did things the Windows way: all drivers in one ntoskrnl process
- this won't work properly in Wine for years, if ever, since ntoskrnl
is so incomplete and one bad driver will crash them all. Another
possibility could be to keep drivers in separate processes, but allow
inter-process communication, but I see serializing IRPs between
processes as being complex and very slow.

Driver installation is also quite a mission. Windows detects that the
hardware doesn't have a driver installed, and then generates the
device ID and compatible IDs and searches .INF files for one that can
support it. Our setupapi needs to be substantially improved to be able
to do the same, and some newdev.dll and manual INF parsing work to
install the driver may also be necessary, and I can already think of
cases where even class installers will be necessary too :-(.

Wine only sends DeviceIoControl to drivers. For anything non-trivial,
other file-related user-space functions (at least ReadFile, WriteFile)
need to go to the driver too. The infrastructure for this does not
even exist yet, and would probably affects wineserver as well.

Regression tests for ntosnkrl.exe and kernel drivers don't exist, and
are difficult to come up with, since we'd have to compile and load
drivers on Windows and run tests that don't crash Windows :-).

So the architecture for USB support is tricky to say the least. But
I'd still like to resume work on my USB patches some time soon, would
you like to help?

Damjan Jovanovic

On Tue, Sep 14, 2010 at 4:33 PM, James Mckenzie
 wrote:
> Alexander:
>
> Before I go off and try to update your USB device support for the latest Wine 
> release, are you continuing to maintain this code current to the Wine 
> Development and Wine Stable trunks?
>
> Also, the USB Device Support in Wine Wiki page needs an update.  The code at 
> snicky.com is no longer available.
>
> Thank you for your efforts to support USB devices in Wine.
>
> James McKenzie
>
>
>
>

USB Device Support

[James Mckenzie]

Alexander:

Before I go off and try to update your USB device support for the latest Wine 
release, are you continuing to maintain this code current to the Wine 
Development and Wine Stable trunks?

Also, the USB Device Support in Wine Wiki page needs an update.  The code at 
snicky.com is no longer available.

Thank you for your efforts to support USB devices in Wine.

James McKenzie

Re: Status of "USB device support in wine"

[Alexander Morozov]

> - The files from ftp://ftp.etersoft.ru/pub/people/amorozov/usb/current/ miss 
>  lines in configure.ac to trigger the Makefile generation for usbd.sys and
> usbhub.sys.

The part which is generated by tools/make_makefiles is not included in these 
patches.

> Both dll/drivers pair (libusb0.dll/libusb0.sys and ftd2xx.dll/ftdibus.sys)
> work an a lot devices and so must scan the bus for matching devices. I
> didn't get wine with the patches to do anything sensible in that case.

As I understand drivers should not scan bus. They are loaded for devices with 
appropriate
VID and PID. On Windows should modify inf-file (see Device Driver Installation 
on
libusb-win32.sourceforge.net). On WINE with USB patches should add appropriate 
registry
entries.

Status of "USB device support in wine"

[Uwe Bonnes]

Hallo,

I tried to run Alexander Morozov's patches against wine-git with libusb and
ftd2x devices.

Two remarks:
- The files from ftp://ftp.etersoft.ru/pub/people/amorozov/usb/current/ miss 
 lines in configure.ac to trigger the Makefile generation for usbd.sys and
usbhub.sys.
- The HardwareID in the registry is the end of the Registry key
http://msdn.microsoft.com/en-us/library/dd568018.aspx You can use the string
itself in the win registry. This helps, if you don't have the devices
installed on a windows machine available.

Both dll/drivers pair (libusb0.dll/libusb0.sys and ftd2xx.dll/ftdibus.sys)
work an a lot devices and so must scan the bus for matching devices. I
didn't get wine with the patches to do anything sensible in that case.

Alexander, could you perhaps have a look (ftd2xx at
http://www.ftdichip.com/Drivers/D2XX.htm and libusb-win32 at sourceforge)

Thanks

-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Status of "USB device support in wine"

[Uwe Bonnes]

Hello,

Alexander Morozov  did a large redesign after
Alexandre's remarks from 07 October 2008. 

What is still needed to include this functionality?

Thanks
-- 
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Re: wine-1.2 release criteria? (USB device support)

[Vitaly Lipatov]

В сообщении от 25 декабря 2008 Pavel Troller написал(a):
...
> > We (Etersoft) are realized USB support in wine via libusb and do many
...
>   Is your work accessible as a patch to the current wine tree, or as a git
> branch somewhere ?
Please check 
http://git.etersoft.ru/people/lav/packages/wine.git
branch eterhack

>   I would like to test it with some of my apps (Nokia software, programmers
> etc...) and give you a feedback, whether it works.
>   Do you know, why Alexandre is not accepting your improvements ?
Some summarize is available on
http://wiki.winehq.org/USB


-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru

Re: USB device support in wine

[Damjan Jovanovic]

On 5/5/07, Jon Burgess <[EMAIL PROTECTED]> wrote:


>
> 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to
> NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably
> through libusb), and modify ntdll to forward the appropriate reads,
> writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file
> can handle them. This is the only way that works with .SYS files
> out-of-the-box, the others all require a rewrite of the .SYS driver's
> functionality. Architecturally, this is the best way, you wouldn't
> need to change any code in wine to add a new driver.
>
> Way 4 is probably the best and I hope it works at some stage, but it's
> still a long way off seeing as how NTOSKRNL.EXE itself still isn't in
> wine.

Correct me if I'm wrong, but you're saying that this approach would enable
wine to work with (almost?) any USB device, which has a vendor specific,
kernel-mode driver, using the vendor's supplied driver out-of-the-box.


Yes.


Sounds like the best approach to me too.

Maybe there are other people out there with the same problem as me, (or
simply a desire to get better USB support in to wine) who would be
interested in working on this too?


But it's a lot of work, and very few people know how to write Windows
drivers. NTOSKRNL.EXE has been around for a year or 2 now, and it
still hasn't been accepted into wine.

On a brighter note, NDISWRAPPER already works with some USB drivers,
so it can't be that hard to do.


Jono


Damjan

Re: USB device support in wine

[Jon Burgess]

4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to
NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably
through libusb), and modify ntdll to forward the appropriate reads,
writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file
can handle them. This is the only way that works with .SYS files
out-of-the-box, the others all require a rewrite of the .SYS driver's
functionality. Architecturally, this is the best way, you wouldn't
need to change any code in wine to add a new driver.

Way 4 is probably the best and I hope it works at some stage, but it's
still a long way off seeing as how NTOSKRNL.EXE itself still isn't in
wine.



Correct me if I'm wrong, but you're saying that this approach would enable
wine to work with (almost?) any USB device, which has a vendor specific,
kernel-mode driver, using the vendor's supplied driver out-of-the-box.
Sounds like the best approach to me too.

Maybe there are other people out there with the same problem as me, (or
simply a desire to get better USB support in to wine) who would be
interested in working on this too?

Jono

Re: USB device support in wine

[Marcus Meissner]

On Fri, May 04, 2007 at 07:43:00AM -0400, Kuba Ober wrote:
> > There is no standard user-mode interface for accessing USB hardware -
> > there is no equivalent of Linux's libusb on Windows
> 
> But there is, just that most vendors don't use it.

Lots of Windows driver vendors use the USBD.SYS (spelling?) driver
abstraction though.

Ciao, Marcus

Re: USB device support in wine

[Damjan Jovanovic]

On 5/4/07, Kuba Ober <[EMAIL PROTECTED]> wrote:

> There is no standard user-mode interface for accessing USB hardware -
> there is no equivalent of Linux's libusb on Windows

But there is, just that most vendors don't use it.


There is libusb-win32, but it uses its own kernel-mode driver.

Vista has a user-space driver framework for some types of hardware. It
supports USB drivers, and I think Microsoft did a backport to Windows
XP as well. Hopefully vendors will start to use it instead of writing
kernel-mode drivers, then we can easily use those drivers from wine
:-).

Damjan

Re: USB device support in wine

[Kuba Ober]

On Friday 04 May 2007, you wrote:
> > There is no standard user-mode interface for accessing USB hardware -
> > there is no equivalent of Linux's libusb on Windows
>
> But there is, just that most vendors don't use it.

http://libusb-win32.sourceforge.net/

It doesn't seem maintained, but it did work in WIN98 era at least (used it 
back then).

> > (there is
> > apparently some user-space USB stuff in mingw's headers, but I
> > couldn't find any official docs on it, and it's not enough to write a
> > user-space driver because there is no bulk/interrupt/isochronous pipe
[...]

Woopty, finger slipped on enter :)

Kuba

Re: USB device support in wine

[Detlef Riekenberg]

On Fr, 2007-05-04 at 10:37 +0800, Jon Burgess wrote:

> (Serato Scratch Live: http://www.rane.com/scratch.html) for which the
> software appears to run ok under wine (not that I am able to test much
> of its functionality on the other hand), but is utterly useless
> without support for its associated USB hardware device. 

The driver is here: http://www.rane.com/sslfix.html

It looks, that you need to use the vendor-driver, and 
Windows Kernel Drivers do not work in wine.

"winedump dump -j import SeratoUsb.sys"

ntoskrnl.exe
hal.dll
wmilib.sys
usbd.sys



-- 
 
By by ... Detlef

Re: USB device support in wine

[Kuba Ober]

> There is no standard user-mode interface for accessing USB hardware -
> there is no equivalent of Linux's libusb on Windows

But there is, just that most vendors don't use it.


> (there is 
> apparently some user-space USB stuff in mingw's headers, but I
> couldn't find any official docs on it, and it's not enough to write a
> user-space driver because there is no bulk/interrupt/isochronous pipe
> support, so I doubt anybody actually uses it). There is only
> kernel-mode interfaces for talking to USB - and different kernel mode
> drivers will export different user-mode interfaces (if any).
>
> So user-space software uses a kernel-mode driver. If that driver is
> documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be
> done in wine, and wine can be connected to USB in a number of ways
> (which I'll discuss later). If that driver is undocumented, either you
> have to document it by reverse-engineering (very hard) and continue
> with the first way, or (the second way:) make wine's not-yet-existing
> NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the
> USB interfaces that Windows has.
>
> CONNECTING WINE TO USB: A HOW-TO GUIDE
>
> There is 4 ways to do it:
>
> 1. Make a kernel module in your OS (eg. a Linux kernel module) that
> exports the same interface that the software expects and works the
> same way as the Windows driver. Using USBSCAN.SYS as an example,
> reading does a USB bulk read, writing does a USB bulk write, and 13 or
> so i/o control codes do various other things, among them USB control
> and interrupt tranfers. Change kernel32's CreateFileW() to open the
> /dev device node used by the kernel module and send it to the wine
> server using wine_server_fd_to_handle(), then reading and writing will
> go to your kernel module, where you can implement them by doing USB
> reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to
> capture i/o control codes used by your device, call
> wine_server_handle_to_fd(), and do an ioctl() on that fd to send that
> i/o control call to the kernel module, which then reacts
> appropriately. This way has been tested by me, it works and it's fast,
> but it's non-portable (eg. Linux-only, and Linux's USB interface keep
> changing so an out-of-tree module will only work on some versions, the
> usual problems...), difficult (kernel-mode code is hard to write), and
> generally a royal PITA.
>
> 2. Like (1) but use a framework like FUSD (the xiph.org version works
> on 2.6 kernels) to write the driver in user-space and then do USB I/O
> using libusb. I'm currently testing this approach, I suspect it's slow
> (how significantly remains to be seen), but at least it's more
> portable between Linux versions and easier to write and maintain.
>
> 3. Integrate your device into wine directly the way eg. serial ports
> have been done. This is hard, and requires introducing a new FD_TYPE,
> changing ntdll's file.c's NtReadFile, NtWriteFile, and
> NtDeviceIoControlFile (and asynchronous versions of those) to use
> special behavior for that FD_TYPE, and managing global device state
> (eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot
> of time, and some changes to both wine and libusb, you could get it to
> work properly. This should IMO only be done for generally useful
> drivers, not drivers for just 1 type of device.
>
> 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to
> NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably
> through libusb), and modify ntdll to forward the appropriate reads,
> writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file
> can handle them. This is the only way that works with .SYS files
> out-of-the-box, the others all require a rewrite of the .SYS driver's
> functionality. Architecturally, this is the best way, you wouldn't
> need to change any code in wine to add a new driver.
>
> Way 4 is probably the best and I hope it works at some stage, but it's
> still a long way off seeing as how NTOSKRNL.EXE itself still isn't in
> wine.
>
> >  In the mean time, looks like I have some reading to do regarding USB
> > spec, dbus and hal :-)
>
> There is only 1 or 2 chapters you need from the USB spec. DBus is just
> an RPC framework, and HAL just lists devices and their properties, so
> they won't help much.
>
> > Thanks for the help so far.
> >
> > Regards,
> > Jono
>
> Damjan

Re: USB device support in wine

[Damjan Jovanovic]

On 5/4/07, Jon Burgess <[EMAIL PROTECTED]> wrote:


> > I have found some talk of implementing USB device support in wine in
this
> > list some time ago (2005), but as far as I know, nothing ever came of
it.
> >
> > I would perhaps be interested in getting this going again, as I have an
> > application (Serato Scratch Live:
> > http://www.rane.com/scratch.html) for which the
software
> > appears to run ok under wine (not that I am able to test much of its
> > functionality on the other hand), but is utterly useless without support
for
> > its associated USB hardware device.
> >
> > Any ideas, or anyone else who would be interested in helping me?
>
> Does the software come with a .SYS file?

yes:  the is a directory .../Serato/Drivers/ containing "MP4Usb.sys" and
"MP4Usb.inf", although I seem to remember reading somewhere that the MP4
driver is for another Serato product (not Scratch live).


It probably doesn't refer to the MP4 music format.


> That website doesn't much, please post lsusb -v output.



Bus 004 Device 002: ID 13e5:0001
Device Descriptor:
   bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass   255 Vendor Specific Subclass
  bDeviceProtocol   255 Vendor Specific Protocol


This there is no "standard" driver for your USB device (like for
example there is just 1 driver for all USB flash disks, because
they're all in the same device class). You have the use the
vendor-supplied .SYS file.

Will it work on wine right now? Not even remotely.
Will it ever? Read on...

There is no standard user-mode interface for accessing USB hardware -
there is no equivalent of Linux's libusb on Windows (there is
apparently some user-space USB stuff in mingw's headers, but I
couldn't find any official docs on it, and it's not enough to write a
user-space driver because there is no bulk/interrupt/isochronous pipe
support, so I doubt anybody actually uses it). There is only
kernel-mode interfaces for talking to USB - and different kernel mode
drivers will export different user-mode interfaces (if any).

So user-space software uses a kernel-mode driver. If that driver is
documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be
done in wine, and wine can be connected to USB in a number of ways
(which I'll discuss later). If that driver is undocumented, either you
have to document it by reverse-engineering (very hard) and continue
with the first way, or (the second way:) make wine's not-yet-existing
NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the
USB interfaces that Windows has.

CONNECTING WINE TO USB: A HOW-TO GUIDE

There is 4 ways to do it:

1. Make a kernel module in your OS (eg. a Linux kernel module) that
exports the same interface that the software expects and works the
same way as the Windows driver. Using USBSCAN.SYS as an example,
reading does a USB bulk read, writing does a USB bulk write, and 13 or
so i/o control codes do various other things, among them USB control
and interrupt tranfers. Change kernel32's CreateFileW() to open the
/dev device node used by the kernel module and send it to the wine
server using wine_server_fd_to_handle(), then reading and writing will
go to your kernel module, where you can implement them by doing USB
reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to
capture i/o control codes used by your device, call
wine_server_handle_to_fd(), and do an ioctl() on that fd to send that
i/o control call to the kernel module, which then reacts
appropriately. This way has been tested by me, it works and it's fast,
but it's non-portable (eg. Linux-only, and Linux's USB interface keep
changing so an out-of-tree module will only work on some versions, the
usual problems...), difficult (kernel-mode code is hard to write), and
generally a royal PITA.

2. Like (1) but use a framework like FUSD (the xiph.org version works
on 2.6 kernels) to write the driver in user-space and then do USB I/O
using libusb. I'm currently testing this approach, I suspect it's slow
(how significantly remains to be seen), but at least it's more
portable between Linux versions and easier to write and maintain.

3. Integrate your device into wine directly the way eg. serial ports
have been done. This is hard, and requires introducing a new FD_TYPE,
changing ntdll's file.c's NtReadFile, NtWriteFile, and
NtDeviceIoControlFile (and asynchronous versions of those) to use
special behavior for that FD_TYPE, and managing global device state
(eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot
of time, and some changes to both wine and libusb, you could get it to
work properly. This should IMO only be done for generally useful
drivers, not dr

Re: USB device support in wine

[Jon Burgess]

> I have found some talk of implementing USB device support in wine in
this
> list some time ago (2005), but as far as I know, nothing ever came of
it.
>
> I would perhaps be interested in getting this going again, as I have an
> application (Serato Scratch Live:
> http://www.rane.com/scratch.html) for which the software
> appears to run ok under wine (not that I am able to test much of its
> functionality on the other hand), but is utterly useless without support
for
> its associated USB hardware device.

One thing is that you need to make sure that the hardware is detected
and usable by Linux prior to trying to implement support for it in
wine.  If linux can't see it, then wine won't be able to, just like if
you dont have the drivers installed in windows, then you wont be able
to use it within the application on windows.



Ok, thanks Tom.

I will investigate that - "/var/log/syslog" and "/proc/bus/usb/devices"
should give me some idea if the USB device is detected, right?

I'll check when I get home, at work atm.

Cheers,
Jono

Re: USB device support in wine

[Damjan Jovanovic]

On 5/4/07, Jon Burgess <[EMAIL PROTECTED]> wrote:

Hi,

I have found some talk of implementing USB device support in wine in this
list some time ago (2005), but as far as I know, nothing ever came of it.

I would perhaps be interested in getting this going again, as I have an
application (Serato Scratch Live:
http://www.rane.com/scratch.html) for which the software
appears to run ok under wine (not that I am able to test much of its
functionality on the other hand), but is utterly useless without support for
its associated USB hardware device.

Any ideas, or anyone else who would be interested in helping me?


Does the software come with a .SYS file?

That website doesn't much, please post lsusb -v output.


Regards,
Jono


Damjan

Re: USB device support in wine

[Tom Spear]

On 5/3/07, Jon Burgess <[EMAIL PROTECTED]> wrote:

Hi,

I have found some talk of implementing USB device support in wine in this
list some time ago (2005), but as far as I know, nothing ever came of it.

I would perhaps be interested in getting this going again, as I have an
application (Serato Scratch Live:
http://www.rane.com/scratch.html) for which the software
appears to run ok under wine (not that I am able to test much of its
functionality on the other hand), but is utterly useless without support for
its associated USB hardware device.


One thing is that you need to make sure that the hardware is detected
and usable by Linux prior to trying to implement support for it in
wine.  If linux can't see it, then wine won't be able to, just like if
you dont have the drivers installed in windows, then you wont be able
to use it within the application on windows.

--
Thanks

Tom

Check out this new 3D Instant Messenger called IMVU.  It's the best I
have seen yet!



http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

USB device support in wine

[Jon Burgess]

Hi,

I have found some talk of implementing USB device support in wine in this
list some time ago (2005), but as far as I know, nothing ever came of it.

I would perhaps be interested in getting this going again, as I have an
application (Serato Scratch Live: http://www.rane.com/scratch.html) for
which the software appears to run ok under wine (not that I am able to test
much of its functionality on the other hand), but is utterly useless without
support for its associated USB hardware device.

Any ideas, or anyone else who would be interested in helping me?

Regards,
Jono