Damjan Jovanovic damjan.jov@gmail.com writes:
Changelog:
- usbhub.sys: add stubbed usbhub.sys
What is this going to be useful for?
On Wed, Mar 24, 2010 at 8:30 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
Changelog:
- usbhub.sys: add stubbed usbhub.sys
What is this going to be useful for?
-- Alexandre Julliard julliard@winehq.org
The same as Etersoft's USB patches: for doing USB I/O to USB devices.
Damjan
Damjan Jovanovic damjan.jov@gmail.com writes:
The same as Etersoft's USB patches: for doing USB I/O to USB devices.
Obviously, but why do you specifically need usbhub.sys given that it doesn't export anything? What is there that depends on having it?
On Wed, Mar 24, 2010 at 9:24 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
The same as Etersoft's USB patches: for doing USB I/O to USB devices.
Obviously, but why do you specifically need usbhub.sys given that it doesn't export anything? What is there that depends on having it?
-- Alexandre Julliard julliard@winehq.org
usbhub.sys isn't accessed via exports and I don't think anything depends on usbhub.sys specifically - but on Windows it builds device objects for USB devices and does I/O to these, so it seems like the best place to do those in Wine too.
Damjan Jovanovic
Damjan Jovanovic damjan.jov@gmail.com writes:
usbhub.sys isn't accessed via exports and I don't think anything depends on usbhub.sys specifically - but on Windows it builds device objects for USB devices and does I/O to these, so it seems like the best place to do those in Wine too.
I'm not convinced that splitting this stuff across modules is a good idea. There isn't much reason to replicate the Windows I/O stack layout because our devices work quite differently.
On Wed, Mar 24, 2010 at 9:51 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
usbhub.sys isn't accessed via exports and I don't think anything depends on usbhub.sys specifically - but on Windows it builds device objects for USB devices and does I/O to these, so it seems like the best place to do those in Wine too.
I'm not convinced that splitting this stuff across modules is a good idea. There isn't much reason to replicate the Windows I/O stack layout because our devices work quite differently.
-- Alexandre Julliard julliard@winehq.org
So should I do everything in usbd.sys then?
Damjan Jovanovic
Damjan Jovanovic damjan.jov@gmail.com writes:
On Wed, Mar 24, 2010 at 9:51 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
usbhub.sys isn't accessed via exports and I don't think anything depends on usbhub.sys specifically - but on Windows it builds device objects for USB devices and does I/O to these, so it seems like the best place to do those in Wine too.
I'm not convinced that splitting this stuff across modules is a good idea. There isn't much reason to replicate the Windows I/O stack layout because our devices work quite differently.
-- Alexandre Julliard julliard@winehq.org
So should I do everything in usbd.sys then?
I expect that will be a lot easier. I'm happy to be proven wrong, if you find that usbhub.sys works better that's fine, I just don't want to add modules now to find out later that they can't be made to work.
On Wed, Mar 24, 2010 at 10:04 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
On Wed, Mar 24, 2010 at 9:51 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
usbhub.sys isn't accessed via exports and I don't think anything depends on usbhub.sys specifically - but on Windows it builds device objects for USB devices and does I/O to these, so it seems like the best place to do those in Wine too.
I'm not convinced that splitting this stuff across modules is a good idea. There isn't much reason to replicate the Windows I/O stack layout because our devices work quite differently.
-- Alexandre Julliard julliard@winehq.org
So should I do everything in usbd.sys then?
I expect that will be a lot easier. I'm happy to be proven wrong, if you find that usbhub.sys works better that's fine, I just don't want to add modules now to find out later that they can't be made to work.
-- Alexandre Julliard julliard@winehq.org
I don't know enough about writing kernel drivers yet to decide this (and several other things), so I think it's best I hack at it until I have it working, then I'll start submitting patches again.
In the meanwhile, is the use of libusb-1.0 in Wine ok? Or should I use libusb-0.1 or some other library?
Thank you Damjan Jovanovic
Damjan Jovanovic damjan.jov@gmail.com writes:
I don't know enough about writing kernel drivers yet to decide this (and several other things), so I think it's best I hack at it until I have it working, then I'll start submitting patches again.
In the meanwhile, is the use of libusb-1.0 in Wine ok? Or should I use libusb-0.1 or some other library?
I think 1.0 is fine, but I'd like to see some code using it first.
On Thu, Mar 25, 2010 at 9:06 PM, Alexandre Julliard julliard@winehq.org wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
I don't know enough about writing kernel drivers yet to decide this (and several other things), so I think it's best I hack at it until I have it working, then I'll start submitting patches again.
In the meanwhile, is the use of libusb-1.0 in Wine ok? Or should I use libusb-0.1 or some other library?
I think 1.0 is fine, but I'd like to see some code using it first.
-- Alexandre Julliard julliard@winehq.org
I've hacked at this enough to get some basic USB I/O working, so now I have a better idea of what's necessary.
I like usbhub.sys separate from usbd.sys because: * The service is called Usbhub in the registry, drivers might depend on the service, and having the service load usbd.sys instead of usbhub.sys is confusing. * usbd.sys isn't part of the device stack in any way, it's just a utility library used to do miscellaneous things like parse USB descriptors. Putting I/O code in there would be confusing. * Windows from 2000 onwards uses usbhub.sys for device stack management and I/O. No Windows version uses usbd.sys like that. * If we don't want dlls that export nothing, mountmgr.sys also exports nothing, so it should be part of ntoskrnl.exe by the same logic. * There will no more usbXXX.sys files for basic USB after usbhub.sys. We might eventually want higher-level device class drivers (usbstor.sys, usbprint.sys) and Microsoft-provided generic drivers (usbscan.sys) though. * The driver doesn't load first and load usbd.sys via an import which creates a device stack, usbhub.sys loads first and then loads drivers (into the same process) on-demand, as their USB devices are plugged in.
A *very hacked* patch is attached, if you want to see how libusb-1.0 is used. It only works just enough for the driver to read descriptors from the device and send a few basic I/O requests.
I'd like to start sending real patches soon, so can I add a separate usbhub.sys or do I have to stick with usbd.sys? And is libusb-1.0 ok?
Thank you Damjan Jovanovic
Damjan Jovanovic damjan.jov@gmail.com writes:
I've hacked at this enough to get some basic USB I/O working, so now I have a better idea of what's necessary.
I like usbhub.sys separate from usbd.sys because:
- The service is called Usbhub in the registry, drivers might depend
on the service, and having the service load usbd.sys instead of usbhub.sys is confusing.
- usbd.sys isn't part of the device stack in any way, it's just a
utility library used to do miscellaneous things like parse USB descriptors. Putting I/O code in there would be confusing.
- Windows from 2000 onwards uses usbhub.sys for device stack
management and I/O. No Windows version uses usbd.sys like that.
- If we don't want dlls that export nothing, mountmgr.sys also exports
nothing, so it should be part of ntoskrnl.exe by the same logic.
- There will no more usbXXX.sys files for basic USB after usbhub.sys.
We might eventually want higher-level device class drivers (usbstor.sys, usbprint.sys) and Microsoft-provided generic drivers (usbscan.sys) though.
- The driver doesn't load first and load usbd.sys via an import which
creates a device stack, usbhub.sys loads first and then loads drivers (into the same process) on-demand, as their USB devices are plugged in.
A *very hacked* patch is attached, if you want to see how libusb-1.0 is used. It only works just enough for the driver to read descriptors from the device and send a few basic I/O requests.
I'd like to start sending real patches soon, so can I add a separate usbhub.sys or do I have to stick with usbd.sys? And is libusb-1.0 ok?
It seems to me that the device detection needs to be handled by mountmgr, you don't want a libusb polling loop. Also I don't think you want to load all of usb inside the same process, native drivers will crash, and that shouldn't take down the whole usb support. I'd say you should have one process per device or something along those lines.
Am Mittwoch, 24. März 2010 19:49:46 schrieb Damjan Jovanovic:
On Wed, Mar 24, 2010 at 8:30 PM, Alexandre Julliard julliard@winehq.org
wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
Changelog:
- usbhub.sys: add stubbed usbhub.sys
What is this going to be useful for?
-- Alexandre Julliard julliard@winehq.org
The same as Etersoft's USB patches: for doing USB I/O to USB devices.
Damjan
Without having looked into the code: is it possible to simulate virtual USB devices plugged or removed at the USB bus?
-- Heiko Nardmann
On Wed, Apr 14, 2010 at 8:35 PM, frechdachs69 frechdachs69@sofortsurf.de wrote:
Am Mittwoch, 24. März 2010 19:49:46 schrieb Damjan Jovanovic:
On Wed, Mar 24, 2010 at 8:30 PM, Alexandre Julliard julliard@winehq.org
wrote:
Damjan Jovanovic damjan.jov@gmail.com writes:
Changelog:
- usbhub.sys: add stubbed usbhub.sys
What is this going to be useful for?
-- Alexandre Julliard julliard@winehq.org
The same as Etersoft's USB patches: for doing USB I/O to USB devices.
Damjan
Without having looked into the code: is it possible to simulate virtual USB devices plugged or removed at the USB bus?
-- Heiko Nardmann
I am not sure where you're going with this. User-space software only interacts with a device using a driver, and only interacts with that driver, at the lowest level, using I/O operations like ReadFile, WriteFile, DeviceIoControl, etc. You could write a driver to simulate a device but you don't need any USB functions for that.
Damjan
-
Alexandre Julliard -
Damjan Jovanovic -
frechdachs69