Prev: Contiguous Memory allocation
Next: A KeQuerySystemTime alternate function under x64 ?
From: Tim Roberts on 22 Dec 2009 22:46
Jake <Jake(a)discussions.microsoft.com> wrote:
>
>"Tim Roberts" wrote:
>>
>> What kind of devices are these?
>
>(annoyed that I'm not getting automatic emails when responses are posted)

Hmmm; I use the newsgroup interface. It's hard for me to imagine a worse
interface for technical exchanges than a web forum.

>I guess I don't see why any of the details of the implementation
>requirements really matters here.

You're right, of course. It's just that we often find people asking
specific implementation questions trying to solve problems in an out of
ordinary way, when in fact there is a well-supported mechanism to reach the
same end. This leads me to ask seemingly annoying questions.

>I'm just trying to iterate serial numbers while a device is already "open"
>within WinUSB. This should certainly be possible and, if not, I think it
>represents a bug somewhere, or at least a deficiency.

It's not a bug, it's a feature. WinUSB creates its device object as
"exclusive", so each instance can only be opened by one app at a time. This
is certainly documented. You will never be able to read the serial number
USING WINUSB while another app has the device open.

Did you do as I suggested, and dump the device path filenames during your
iteration? Did you not find the serial numbers embedded in the device
filename in an easy-to-parse way? That doesn't require opening the device
at all.

>I know that it is possible using a different driver implementation that I've
>used in the past, so it may simply be a known deficiency in WinUSB, but it
>would be nice to see that written somewhere. And it would be nice to have
>that deficiency resolved.

It is documented.

>How do we elevate something like this using one of our "MSDN incidents" ?
>I've never used one, but this seems like the right time since no one from MS
>is chiming in here.

Well, a support incident isn't going to help, because WinUSB is working as
designed. If you need a capability that WinUSB does not provide, then your
fallback situation is to write your own driver. WinUSB, after all, is just
a convenience for applications where its model fits the problem space.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Jake on 23 Dec 2009 22:04
Tim--

Well, I was hoping to avoid a full-on explanation because it really is
irrelevant to the problem at hand. But I'm not hiding anything. First, a
few other things to address:

1. I was not able to see the serial number in the device path names. Just
the PID, VID, and a GUID which isn't the GUID from the INF file. Perhaps
something associated with WinUSB.

2. Regarding the incident, yes, I was afraid of that. Most of the forms for
incidents seem to indicate we're posting bugs with something. I'm really
looking for a solution that may or may not be documented somewhere.

3. You're right that OPENING a device should be exclusive. However, I'm not
trying to open the device. I just want to query the serial numbers of all
attached devices. This should not require opening a device with WinUSB. The
serial number query can occur without a bound interface.

Now... the irrelevant details.

This is an API for a very custom, very niche device. It can be used in any
number of applications from industrial control to image capture. It's not
your typical keyboard, mouse, webcam, etc.

It isn't uncommon to have multiple of these devices attached to different
machinery. The device allows storage of a user-managed ID. For the camera
example, let's say those IDs are "Camera 1", "Camera 2", and "Camera 3".
Query of the device ID requires communication with the device outside the
simple USB queries like interfaces, serial numbers, PID/VID, etc.

Therefore, I accept that query of the device ID will require WinUSB to bind
a handle. Fair enough. I encourage this behavior! It prevents two apps (or
even the same app) from trying to communicate with the device. This can
really muck with the state of the device.

But the end user should be able to iterate all attached devices of this
PID/VID pair and get their serial number even if a device is "open".

In fact, this driver was migrated from the (horrible) Cypress API for their
USB devices. But even that API allowed serial number query for devices that
are active.

I recognize that a simple solution is to just require the end-user to
iterate devices before establishing any communication. But since this is an
update to an existing API, it should support the legacy operation. Both in
terms of customer support and in terms of my understanding of the "theory"
behind it. It was done before (my thinking goes...) it simply MUST be
possible.

Even if I need to do this external to the WinUSB stuff, I'm happy to do so.
It might require a few more lines of code, but it should be possible, right?

....I used to use the newsgroup interfaces to all this stuff to. I suppose
I've just drifted with the tides. Haven't used a newsgroup interface for
several years now. Funny, it was my migration to Windows that changed all
that. And now I'm getting grief for it on a Windows newsgroup. :) ...




"Tim Roberts" wrote:

> Jake <Jake(a)discussions.microsoft.com> wrote:
> >
> >"Tim Roberts" wrote:
> >>
> >> What kind of devices are these?
> >
> >(annoyed that I'm not getting automatic emails when responses are posted)
>
> Hmmm; I use the newsgroup interface. It's hard for me to imagine a worse
> interface for technical exchanges than a web forum.
>
> >I guess I don't see why any of the details of the implementation
> >requirements really matters here.
>
> You're right, of course. It's just that we often find people asking
> specific implementation questions trying to solve problems in an out of
> ordinary way, when in fact there is a well-supported mechanism to reach the
> same end. This leads me to ask seemingly annoying questions.
>
> >I'm just trying to iterate serial numbers while a device is already "open"
> >within WinUSB. This should certainly be possible and, if not, I think it
> >represents a bug somewhere, or at least a deficiency.
>
> It's not a bug, it's a feature. WinUSB creates its device object as
> "exclusive", so each instance can only be opened by one app at a time. This
> is certainly documented. You will never be able to read the serial number
> USING WINUSB while another app has the device open.
>
> Did you do as I suggested, and dump the device path filenames during your
> iteration? Did you not find the serial numbers embedded in the device
> filename in an easy-to-parse way? That doesn't require opening the device
> at all.
>
> >I know that it is possible using a different driver implementation that I've
> >used in the past, so it may simply be a known deficiency in WinUSB, but it
> >would be nice to see that written somewhere. And it would be nice to have
> >that deficiency resolved.
>
> It is documented.
>
> >How do we elevate something like this using one of our "MSDN incidents" ?
> >I've never used one, but this seems like the right time since no one from MS
> >is chiming in here.
>
> Well, a support incident isn't going to help, because WinUSB is working as
> designed. If you need a capability that WinUSB does not provide, then your
> fallback situation is to write your own driver. WinUSB, after all, is just
> a convenience for applications where its model fits the problem space.
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.
> .
>
From: David Craig on 23 Dec 2009 22:43
I am sure you know this, but:

1. Any query requires that some device driver have a device object exposing
a physical device, maybe just one function if multiple ones exist.

2. Some stacks expose some functionality via IoCtls and/or WMI. In these
cases a driver, frequently from Microsoft, does all the stuff in 1.

You can get a rather nice WMI query utility in source form to see what is
available. It was/is called WmiTest and it may require some changes to work
properly and Visual Studio to compile.

You may have to do a lot of research and reverse engineering to see what the
USB stack will expose to you. I am certain that it will query the device
for that descriptor if it exists.


"Jake" <Jake(a)discussions.microsoft.com> wrote in message
news:E5B33D3A-CE41-459E-BAC2-3B21572B178E(a)microsoft.com...
> Tim--
>
> Well, I was hoping to avoid a full-on explanation because it really is
> irrelevant to the problem at hand. But I'm not hiding anything. First, a
> few other things to address:
>
> 1. I was not able to see the serial number in the device path names. Just
> the PID, VID, and a GUID which isn't the GUID from the INF file. Perhaps
> something associated with WinUSB.
>
> 2. Regarding the incident, yes, I was afraid of that. Most of the forms
> for
> incidents seem to indicate we're posting bugs with something. I'm really
> looking for a solution that may or may not be documented somewhere.
>
> 3. You're right that OPENING a device should be exclusive. However, I'm
> not
> trying to open the device. I just want to query the serial numbers of all
> attached devices. This should not require opening a device with WinUSB.
> The
> serial number query can occur without a bound interface.
>
> Now... the irrelevant details.
>
> This is an API for a very custom, very niche device. It can be used in
> any
> number of applications from industrial control to image capture. It's not
> your typical keyboard, mouse, webcam, etc.
>
> It isn't uncommon to have multiple of these devices attached to different
> machinery. The device allows storage of a user-managed ID. For the
> camera
> example, let's say those IDs are "Camera 1", "Camera 2", and "Camera 3".
> Query of the device ID requires communication with the device outside the
> simple USB queries like interfaces, serial numbers, PID/VID, etc.
>
> Therefore, I accept that query of the device ID will require WinUSB to
> bind
> a handle. Fair enough. I encourage this behavior! It prevents two apps
> (or
> even the same app) from trying to communicate with the device. This can
> really muck with the state of the device.
>
> But the end user should be able to iterate all attached devices of this
> PID/VID pair and get their serial number even if a device is "open".
>
> In fact, this driver was migrated from the (horrible) Cypress API for
> their
> USB devices. But even that API allowed serial number query for devices
> that
> are active.
>
> I recognize that a simple solution is to just require the end-user to
> iterate devices before establishing any communication. But since this is
> an
> update to an existing API, it should support the legacy operation. Both
> in
> terms of customer support and in terms of my understanding of the "theory"
> behind it. It was done before (my thinking goes...) it simply MUST be
> possible.
>
> Even if I need to do this external to the WinUSB stuff, I'm happy to do
> so.
> It might require a few more lines of code, but it should be possible,
> right?
>
> ...I used to use the newsgroup interfaces to all this stuff to. I suppose
> I've just drifted with the tides. Haven't used a newsgroup interface for
> several years now. Funny, it was my migration to Windows that changed all
> that. And now I'm getting grief for it on a Windows newsgroup. :) ...
>
>
>
>
> "Tim Roberts" wrote:
>
>> Jake <Jake(a)discussions.microsoft.com> wrote:
>> >
>> >"Tim Roberts" wrote:
>> >>
>> >> What kind of devices are these?
>> >
>> >(annoyed that I'm not getting automatic emails when responses are
>> >posted)
>>
>> Hmmm; I use the newsgroup interface. It's hard for me to imagine a worse
>> interface for technical exchanges than a web forum.
>>
>> >I guess I don't see why any of the details of the implementation
>> >requirements really matters here.
>>
>> You're right, of course. It's just that we often find people asking
>> specific implementation questions trying to solve problems in an out of
>> ordinary way, when in fact there is a well-supported mechanism to reach
>> the
>> same end. This leads me to ask seemingly annoying questions.
>>
>> >I'm just trying to iterate serial numbers while a device is already
>> >"open"
>> >within WinUSB. This should certainly be possible and, if not, I think
>> >it
>> >represents a bug somewhere, or at least a deficiency.
>>
>> It's not a bug, it's a feature. WinUSB creates its device object as
>> "exclusive", so each instance can only be opened by one app at a time.
>> This
>> is certainly documented. You will never be able to read the serial
>> number
>> USING WINUSB while another app has the device open.
>>
>> Did you do as I suggested, and dump the device path filenames during your
>> iteration? Did you not find the serial numbers embedded in the device
>> filename in an easy-to-parse way? That doesn't require opening the
>> device
>> at all.
>>
>> >I know that it is possible using a different driver implementation that
>> >I've
>> >used in the past, so it may simply be a known deficiency in WinUSB, but
>> >it
>> >would be nice to see that written somewhere. And it would be nice to
>> >have
>> >that deficiency resolved.
>>
>> It is documented.
>>
>> >How do we elevate something like this using one of our "MSDN incidents"
>> >?
>> >I've never used one, but this seems like the right time since no one
>> >from MS
>> >is chiming in here.
>>
>> Well, a support incident isn't going to help, because WinUSB is working
>> as
>> designed. If you need a capability that WinUSB does not provide, then
>> your
>> fallback situation is to write your own driver. WinUSB, after all, is
>> just
>> a convenience for applications where its model fits the problem space.
>> --
>> Tim Roberts, timr(a)probo.com
>> Providenza & Boekelheide, Inc.
>> .
>>


From: Maxim S. Shatskih on 23 Dec 2009 22:49
> It isn't uncommon to have multiple of these devices attached to different
> machinery. The device allows storage of a user-managed ID. For the camera
> example, let's say those IDs are "Camera 1", "Camera 2", and "Camera 3".

I think you can use SetupDi APIs instead of WinUSB to query such strings.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Pavel A. on 23 Dec 2009 23:16
"Jake" <Jake(a)discussions.microsoft.com> wrote in message
news:E5B33D3A-CE41-459E-BAC2-3B21572B178E(a)microsoft.com...

...................
> 1. I was not able to see the serial number in the device path names. Just
> the PID, VID, and a GUID which isn't the GUID from the INF file. Perhaps
> something associated with WinUSB.
>
....................
> It isn't uncommon to have multiple of these devices attached to different
> machinery. The device allows storage of a user-managed ID. For the
> camera
> example, let's say those IDs are "Camera 1", "Camera 2", and "Camera 3".
> Query of the device ID requires communication with the device outside the
> simple USB queries like interfaces, serial numbers, PID/VID, etc.

It looks that there IDs have nothing to do with the so called "USB serial
numbers".
They sit in some other string descriptors, or maybe not in string
descriptors at all.
If these devices have no unique "USB serial numbers", there is no obvious
solution.

Regards,
--pa


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Contiguous Memory allocation
Next: A KeQuerySystemTime alternate function under x64 ?