On Mon, 12 Sep 2005, Robert Marquardt wrote:
> Alan Stern wrote:
>
> >>Simply by testing with a clean device which presents a high power
> >>configuration followed by a low power configuration.
> >
> > You made a long speech here, but you didn't answer my question. How do
> > you know which s
Alan Stern wrote:
Simply by testing with a clean device which presents a high power
configuration followed by a low power configuration.
You made a long speech here, but you didn't answer my question. How do
you know which strategy Windows uses? Did somebody at Microsoft tell you?
Which w
On Fri, 9 Sep 2005, Robert Marquardt wrote:
> Alan Stern wrote:
>
> > That doesn't sound like a very good strategy in general. Configurations
> > don't have to be listed in any particular order; why should the first one
> > be treated specially?
>
> There are only two ways possible for prefer
Alan Stern wrote:
That doesn't sound like a very good strategy in general. Configurations
don't have to be listed in any particular order; why should the first one
be treated specially?
There are only two ways possible for preferencing a configuration.
Ordering of the configurations or the c
On Thu, 8 Sep 2005, Robert Marquardt wrote:
> I proposed a strategy using a list of known bad devices so it is
> solvable. The HID blacklist is a sample for such a list already.
Blacklists are a bad idea in general and are better avoided. For example,
what happens when you plug in a new device
On Wed, 7 Sep 2005, Robert Marquardt wrote:
> Alan Stern wrote:
> > Robert:
> >
> > Take a look at this posting:
> >
> > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112569555202368&w=2
> >
> > (together with the earlier messages in that thread, if you like). It
> > contains some discuss
Robert:
Take a look at this posting:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=112569555202368&w=2
(together with the earlier messages in that thread, if you like). It
contains some discussion and a patch to address the problem you raised,
about choosing configurations that violate po
On Fri, 19 Aug 2005, Robert Marquardt wrote:
> This is completely devastating.
> There *must* be a match of the power requirements of the configuration
> and the port. Currently the device gets configured with a high power
> configuration on a low power port.
> This can trigger the overcurrent p
On Fri, 19 Aug 2005, Robert Marquardt wrote:
> Alan Stern wrote:
>
> > The current strategy is to avoid vendor-specific interface classes and
> > Microsoft RNDIS, and to use the first otherwise available configuration.
> > (The numbering is ignored totally.) That's why you end up with the
>
Alan Stern wrote:
The current strategy is to avoid vendor-specific interface classes and
Microsoft RNDIS, and to use the first otherwise available configuration.
(The numbering is ignored totally.) That's why you end up with the
high-power config.
This is completely devastating.
There *mus
On Thu, 18 Aug 2005, Robert Marquardt wrote:
> I hope this is the correct group for this message.
>
> I have a (HID) device which has a descriptor with two configurations.
> The first configuration is high power wheras the second one is low
> power. The rest of the configurations are identical a
I hope this is the correct group for this message.
I have a (HID) device which has a descriptor with two configurations.
The first configuration is high power wheras the second one is low
power. The rest of the configurations are identical and form a valid HID
device.
The configurations are num
12 matches
Mail list logo
