Discussion:
[linux-uvc-devel] [PATCH] uvcvideo: do not use usb_set_interface on bulk EP
Oleksij Rempel
2014-02-16 09:59:32 UTC
Permalink
Current uvcvideo driver do not correctly disables stream on
Bulk VideoStream EP. This couse problems on a webcam buildin
to Asus Zenbook UX302LA. For example it will be not disabled
and can't be strated after usb port was suspended.

Since usb_set_interface can be used only on Iso EP. We need some
way to handle Bulk VS EP.
Widnwos (xp - 8) uvcvideo driver use usb_clear_halt
in this case. It seems to be correct way to hadle Bulk and Int EPs.
And it solves this problem on UX302LA ultrabook.

CC: ***@vger.kernel.org
Signed-off-by: Oleksij Rempel <***@rempel-privat.de>
---
drivers/media/usb/uvc/uvc_video.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)

if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
+ }
+
uvc_queue_enable(&stream->queue, 0);
uvc_video_clock_cleanup(stream);
return 0;
--
1.9.rc1
Laurent Pinchart
2014-02-17 00:26:38 UTC
Permalink
Hi Oleksij,

Thank you for the patch.
Post by Oleksij Rempel
Current uvcvideo driver do not correctly disables stream on
Bulk VideoStream EP. This couse problems on a webcam buildin
to Asus Zenbook UX302LA. For example it will be not disabled
and can't be strated after usb port was suspended.
s/srated/started/
Post by Oleksij Rempel
Since usb_set_interface can be used only on Iso EP. We need some
way to handle Bulk VS EP.
Widnwos (xp - 8) uvcvideo driver use usb_clear_halt
s/Widnwos/Windows/
Post by Oleksij Rempel
in this case. It seems to be correct way to hadle Bulk and Int EPs.
s/hadle/handle/

Do you mind if I fix the typos and grammar when applying the patch to my tree
?
Post by Oleksij Rempel
And it solves this problem on UX302LA ultrabook.
---
drivers/media/usb/uvc/uvc_video.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
I've copied the content of your other e-mail below to keep all discussions in
one place.
Post by Oleksij Rempel
Hello all,
i have Asus UX302LA with buildin uvc webcam: 1bcf:2987 Sunplus
Innovation Technology Inc.
Could you please send me the lsusb -v output for that camera ?
Post by Oleksij Rempel
This cam uses bulk stream and has some troubles with current linux uvc
driver. It is driver bug since it works on plain uvcvideo windows driver
(even XP SP2 :)).
- the cam will work first time with all linux apps
- after stream off it will take about 4 seconds untill webcam LED will
go off too. The time is equal to usbautosuspend settings.
- it will be impossible to start webcam second time. Even no reboot to
windows will help. Only complete power off will restore functionality.
- if i disable asbautosuspend, webcam will work, but LED will never go
off even if it is not used.
It looks like VS interface is not turned off on Linux and in combination
with usb autosuspend, webcam or usb link will go to nirvana.
I agree with your analysis. Your camera seems to never stop the stream and to
crash when suspended while the stream is active.
Post by Oleksij Rempel
After comparing usb log from windows and linux i found that this webcam
need CLEAR HALT of VideoStreaming interface. Linux driver will do only
SET INTERFACE command. Suddenly i don't have other bulk webcams to see
if windows do it with all of them.
Here is comparison of different webcams and operations which do windows8
Asus UX302LA (UVC 1.00; Bulk) - 1bcf:2987 Sunplus Innovation Technology Inc.
• CLEAR HALT (Interface=0x1) VS interface
The UVC specification doesn't mention clearing the streaming interface control
endpoint halt status. The specification actually doesn't state how the host
should control stream start/stop for devices that use bulk endpoints. That's a
shortcoming of UVC in my opinion

I don't know whether Microsoft has decided to address this issue in their own
way by sending a CLEAR_FEATURE(HALT) request when stopping the video stream,
or if that's a standard procedure in their UVC driver that hasn't been added
specifically for bulk endpoints. Neither the UVC specification nor the USB
specification forbid sending a CLEAR_FEATURE(HALT) request to the streaming
interface bulk endpoint in this case.

It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate setting
(section 9.4.10). In that case the Linux USB core sends a CLEAR_FEATURE(HALT)
request to every endpoint of that interface.
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces. I
suppose you mean endpoint 0x87 here (EP 7 IN) ? Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and not
doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Post by Oleksij Rempel
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)
if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
usb_rcvctrlpipe() expects an endpoint number as its second argument, not an
interface number. The following call should do.

usb_clear_halt(stream->dev->udev, stream->header.bEndpointAddress);

We probably need to validate the streaming header bEndpointAddress field when
probing the device to ensure that we won't call usb_clear_halt() on an
unrelated endpoint.
Post by Oleksij Rempel
+ }
+
This might cause a regression with other bulk devices that expect a
SET_INTERFACE(0), or don't expect a CLEAR_FEATURE(HALT), although I suppose
those devices wouldn't work with Windows then. I've tested you patch (with the
above modification) with the only bulk device I own and it doesn't seem to
cause any regression.
Post by Oleksij Rempel
uvc_queue_enable(&stream->queue, 0);
uvc_video_clock_cleanup(stream);
return 0;
--
Regards,

Laurent Pinchart
Oleksij Rempel
2014-02-17 09:15:26 UTC
Permalink
Can be interesting:

Webcam Pressure Security Test
http://msdn.microsoft.com/en-us/library/windows/hardware/jj124566.aspx

Webcam BasicPerf base
http://msdn.microsoft.com/en-us/library/windows/hardware/jj124090.aspx


http://msdn.microsoft.com/en-us/library/windows/hardware/ff568649%28v=vs.85%29.aspx
--
Regards,
Oleksij
Laurent Pinchart
2014-02-17 09:28:18 UTC
Permalink
Hi Oleksij,
Post by Laurent Pinchart
Post by Oleksij Rempel
Current uvcvideo driver do not correctly disables stream on
Bulk VideoStream EP. This couse problems on a webcam buildin
to Asus Zenbook UX302LA. For example it will be not disabled
and can't be strated after usb port was suspended.
s/srated/started/
Post by Oleksij Rempel
Since usb_set_interface can be used only on Iso EP. We need some
way to handle Bulk VS EP.
Widnwos (xp - 8) uvcvideo driver use usb_clear_halt
s/Widnwos/Windows/
Post by Oleksij Rempel
in this case. It seems to be correct way to hadle Bulk and Int EPs.
s/hadle/handle/
Do you mind if I fix the typos and grammar when applying the patch to my
tree ?
It will be great! Thank you :)
Post by Laurent Pinchart
Post by Oleksij Rempel
And it solves this problem on UX302LA ultrabook.
---
drivers/media/usb/uvc/uvc_video.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
I've copied the content of your other e-mail below to keep all discussions
in one place.
Post by Oleksij Rempel
Hello all,
i have Asus UX302LA with buildin uvc webcam: 1bcf:2987 Sunplus
Innovation Technology Inc.
Could you please send me the lsusb -v output for that camera ?
Suddenly lsusb can't completely decode this descriptor.
The UVC-specific interface descriptors should come before the endpoint
descriptor. The uvcvideo driver supports both orders, lsusb doesn't seem to.
Patches will be appreciated :-)
Post by Laurent Pinchart
Post by Oleksij Rempel
This cam uses bulk stream and has some troubles with current linux uvc
driver. It is driver bug since it works on plain uvcvideo windows driver
(even XP SP2 :)).
- the cam will work first time with all linux apps
- after stream off it will take about 4 seconds untill webcam LED will
go off too. The time is equal to usbautosuspend settings.
- it will be impossible to start webcam second time. Even no reboot to
windows will help. Only complete power off will restore functionality.
- if i disable asbautosuspend, webcam will work, but LED will never go
off even if it is not used.
It looks like VS interface is not turned off on Linux and in combination
with usb autosuspend, webcam or usb link will go to nirvana.
I agree with your analysis. Your camera seems to never stop the stream and
to crash when suspended while the stream is active.
Post by Oleksij Rempel
After comparing usb log from windows and linux i found that this webcam
need CLEAR HALT of VideoStreaming interface. Linux driver will do only
SET INTERFACE command. Suddenly i don't have other bulk webcams to see
if windows do it with all of them.
Here is comparison of different webcams and operations which do windows8
Asus UX302LA (UVC 1.00; Bulk) - 1bcf:2987 Sunplus Innovation Technology
Inc. • CLEAR HALT (Interface=0x1) VS interface
The UVC specification doesn't mention clearing the streaming interface
control endpoint halt status. The specification actually doesn't state
how the host should control stream start/stop for devices that use bulk
endpoints. That's a shortcoming of UVC in my opinion
Are there any thing it specification uvc 1.0? I found only 1.1 and 1.5.
There's a UVC 1.0a.
Another documentation from Cypress, "AN75779 How to Implement an Image
Sensor Interface Using EZ-USB ® FX3TM in a USB Video Class (UVC)
"When the application closes, it issues a clear feature request on a
Windows platform or a Set Interface with alternate setting = 0 request
on a Mac platform."
It confirms your assumption that there is no clear way to handle bulk
stream.
So I assume your camera won't work on Mac OS.
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in their
own way by sending a CLEAR_FEATURE(HALT) request when stopping the video
stream, or if that's a standard procedure in their UVC driver that hasn't
been added specifically for bulk endpoints. Neither the UVC specification
nor the USB specification forbid sending a CLEAR_FEATURE(HALT) request to
the streaming interface bulk endpoint in this case.
It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate
setting (section 9.4.10). In that case the Linux USB core sends a
CLEAR_FEATURE(HALT) request to every endpoint of that interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip Windows
7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and
not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be welcome
:-)
Post by Laurent Pinchart
Post by Oleksij Rempel
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)
if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
usb_rcvctrlpipe() expects an endpoint number as its second argument, not
an interface number. The following call should do.
usb_clear_halt(stream->dev->udev,
stream->header.bEndpointAddress);
We probably need to validate the streaming header bEndpointAddress field
when probing the device to ensure that we won't call usb_clear_halt() on
an unrelated endpoint.
Post by Oleksij Rempel
+ }
+
This might cause a regression with other bulk devices that expect a
SET_INTERFACE(0), or don't expect a CLEAR_FEATURE(HALT), although I
suppose those devices wouldn't work with Windows then. I've tested you
patch (with the above modification) with the only bulk device I own and it
doesn't seem to cause any regression.
I assume, my cam was produced after XP uvc driver. So it should be
default behaviour.
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like

- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
--
Regards,

Laurent Pinchart
Oleksij Rempel
2014-02-17 09:40:35 UTC
Permalink
Post by Laurent Pinchart
Hi Oleksij,
Post by Laurent Pinchart
Post by Oleksij Rempel
Current uvcvideo driver do not correctly disables stream on
Bulk VideoStream EP. This couse problems on a webcam buildin
to Asus Zenbook UX302LA. For example it will be not disabled
and can't be strated after usb port was suspended.
s/srated/started/
Post by Oleksij Rempel
Since usb_set_interface can be used only on Iso EP. We need some
way to handle Bulk VS EP.
Widnwos (xp - 8) uvcvideo driver use usb_clear_halt
s/Widnwos/Windows/
Post by Oleksij Rempel
in this case. It seems to be correct way to hadle Bulk and Int EPs.
s/hadle/handle/
Do you mind if I fix the typos and grammar when applying the patch to my
tree ?
It will be great! Thank you :)
Post by Laurent Pinchart
Post by Oleksij Rempel
And it solves this problem on UX302LA ultrabook.
---
drivers/media/usb/uvc/uvc_video.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
I've copied the content of your other e-mail below to keep all discussions
in one place.
Post by Oleksij Rempel
Hello all,
i have Asus UX302LA with buildin uvc webcam: 1bcf:2987 Sunplus
Innovation Technology Inc.
Could you please send me the lsusb -v output for that camera ?
Suddenly lsusb can't completely decode this descriptor.
The UVC-specific interface descriptors should come before the endpoint
descriptor. The uvcvideo driver supports both orders, lsusb doesn't seem to.
Patches will be appreciated :-)
Post by Laurent Pinchart
Post by Oleksij Rempel
This cam uses bulk stream and has some troubles with current linux uvc
driver. It is driver bug since it works on plain uvcvideo windows driver
(even XP SP2 :)).
- the cam will work first time with all linux apps
- after stream off it will take about 4 seconds untill webcam LED will
go off too. The time is equal to usbautosuspend settings.
- it will be impossible to start webcam second time. Even no reboot to
windows will help. Only complete power off will restore functionality.
- if i disable asbautosuspend, webcam will work, but LED will never go
off even if it is not used.
It looks like VS interface is not turned off on Linux and in combination
with usb autosuspend, webcam or usb link will go to nirvana.
I agree with your analysis. Your camera seems to never stop the stream and
to crash when suspended while the stream is active.
Post by Oleksij Rempel
After comparing usb log from windows and linux i found that this webcam
need CLEAR HALT of VideoStreaming interface. Linux driver will do only
SET INTERFACE command. Suddenly i don't have other bulk webcams to see
if windows do it with all of them.
Here is comparison of different webcams and operations which do windows8
Asus UX302LA (UVC 1.00; Bulk) - 1bcf:2987 Sunplus Innovation Technology
Inc. • CLEAR HALT (Interface=0x1) VS interface
The UVC specification doesn't mention clearing the streaming interface
control endpoint halt status. The specification actually doesn't state
how the host should control stream start/stop for devices that use bulk
endpoints. That's a shortcoming of UVC in my opinion
Are there any thing it specification uvc 1.0? I found only 1.1 and 1.5.
There's a UVC 1.0a.
Do you have it? can you please send it me?
Post by Laurent Pinchart
Another documentation from Cypress, "AN75779 How to Implement an Image
Sensor Interface Using EZ-USB ® FX3TM in a USB Video Class (UVC)
"When the application closes, it issues a clear feature request on a
Windows platform or a Set Interface with alternate setting = 0 request
on a Mac platform."
It confirms your assumption that there is no clear way to handle bulk
stream.
So I assume your camera won't work on Mac OS.
I think Apple don't care about it :)
Post by Laurent Pinchart
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in their
own way by sending a CLEAR_FEATURE(HALT) request when stopping the video
stream, or if that's a standard procedure in their UVC driver that hasn't
been added specifically for bulk endpoints. Neither the UVC specification
nor the USB specification forbid sending a CLEAR_FEATURE(HALT) request to
the streaming interface bulk endpoint in this case.
It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate
setting (section 9.4.10). In that case the Linux USB core sends a
CLEAR_FEATURE(HALT) request to every endpoint of that interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip Windows
7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and
not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be welcome
:-)
That was easy:
https://wikidevi.com/wiki/82066163-7050-ab49-b8cc-b3855e8d2252
See attachment with a testprogram.
Post by Laurent Pinchart
Post by Laurent Pinchart
Post by Oleksij Rempel
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)
if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
usb_rcvctrlpipe() expects an endpoint number as its second argument, not
an interface number. The following call should do.
usb_clear_halt(stream->dev->udev,
stream->header.bEndpointAddress);
We probably need to validate the streaming header bEndpointAddress field
when probing the device to ensure that we won't call usb_clear_halt() on
an unrelated endpoint.
Post by Oleksij Rempel
+ }
+
This might cause a regression with other bulk devices that expect a
SET_INTERFACE(0), or don't expect a CLEAR_FEATURE(HALT), although I
suppose those devices wouldn't work with Windows then. I've tested you
patch (with the above modification) with the only bulk device I own and it
doesn't seem to cause any regression.
I assume, my cam was produced after XP uvc driver. So it should be
default behaviour.
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
It works too. I was just afraid to be too different form MS
implementation. Manufactures usually test it against MS driver so it
sort of dictate specification.
--
Regards,
Oleksij
Laurent Pinchart
2014-02-20 00:36:00 UTC
Permalink
Hi Oleksij,
[snip]
Post by Oleksij Rempel
Post by Laurent Pinchart
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in
their own way by sending a CLEAR_FEATURE(HALT) request when stopping the
video stream, or if that's a standard procedure in their UVC driver that
hasn't been added specifically for bulk endpoints. Neither the UVC
specification nor the USB specification forbid sending a
CLEAR_FEATURE(HALT) request to the streaming interface bulk endpoint in
this case.
It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate
setting (section 9.4.10). In that case the Linux USB core sends a
CLEAR_FEATURE(HALT) request to every endpoint of that interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip
Windows 7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7
and not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be
welcome :-)
https://wikidevi.com/wiki/82066163-7050-ab49-b8cc-b3855e8d2252
See attachment with a testprogram.
That's really interesting. Do you think we could integrate that in libv4l ?
Post by Oleksij Rempel
Post by Laurent Pinchart
Post by Laurent Pinchart
Post by Oleksij Rempel
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming
*stream, int enable)
if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
usb_rcvctrlpipe() expects an endpoint number as its second argument, not
an interface number. The following call should do.
usb_clear_halt(stream->dev->udev,
stream->header.bEndpointAddress);
We probably need to validate the streaming header bEndpointAddress field
when probing the device to ensure that we won't call usb_clear_halt() on
an unrelated endpoint.
Post by Oleksij Rempel
+ }
+
This might cause a regression with other bulk devices that expect a
SET_INTERFACE(0), or don't expect a CLEAR_FEATURE(HALT), although I
suppose those devices wouldn't work with Windows then. I've tested you
patch (with the above modification) with the only bulk device I own and
it doesn't seem to cause any regression.
I assume, my cam was produced after XP uvc driver. So it should be
default behaviour.
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
It works too. I was just afraid to be too different form MS implementation.
Manufactures usually test it against MS driver so it sort of dictate
specification.
I think I agree with you. Could you please test the following patch ?

From 04f3b43ba80ef5f3fbc26f81b8309dc166226b75 Mon Sep 17 00:00:00 2001
From: Oleksij Rempel <***@rempel-privat.de>
Date: Sun, 16 Feb 2014 10:59:32 +0100
Subject: [PATCH] uvcvideo: Do not use usb_set_interface on bulk EP

The UVC specification uses alternate setting selection to notify devices
of stream start/stop. This breaks when using bulk-based devices, as the
video streaming interface has a single alternate setting in that case,
making video stream start and video stream stop events to appear
identical to the device. Bulk-based devices are thus not well supported
by UVC.

The webcam built in the Asus Zenbook UX302LA ignores the set interface
request and will keep the video stream enabled when the driver tries to
stop it. If USB autosuspend is enabled the device will then be suspended
and will crash, requiring a cold reboot.

USB trace capture showed that Windows sends a CLEAR_FEATURE(HALT)
request to the bulk endpoint when stopping the stream instead of
selecting alternate setting 0. The camera then behaves correctly, and
thus seems to require that behaviour.

Replace selection of alternate setting 0 with clearing of the endpoint
halt feature at video stream stop for bulk-based devices. Let's refrain
from blaming Microsoft this time, as it's not clear whether this
Windows-specific but USB-compliant behaviour was specifically developed
to handle bulkd-based UVC devices, or if the camera just took advantage
of it.

CC: ***@vger.kernel.org
Signed-off-by: Oleksij Rempel <***@rempel-privat.de>
Signed-off-by: Laurent Pinchart <***@ideasonboard.com>
---
drivers/media/usb/uvc/uvc_video.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
index 103cd4e..29147fd 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1850,7 +1850,19 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)

if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ /* UVC doesn't specify how to inform a bulk-based device
+ * when the video stream is stopped. Windows sends a
+ * CLEAR_FEATURE(HALT) request to the video streaming
+ * bulk endpoint, mimic the same behaviour.
+ */
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
+ }
+
uvc_queue_enable(&stream->queue, 0);
uvc_video_clock_cleanup(stream);
return 0;
--
1.8.3.2
--
Regards,

Laurent Pinchart
Oleksij Rempel
2014-02-20 07:25:31 UTC
Permalink
Post by Laurent Pinchart
Hi Oleksij,
[snip]
Post by Oleksij Rempel
Post by Laurent Pinchart
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in
their own way by sending a CLEAR_FEATURE(HALT) request when stopping the
video stream, or if that's a standard procedure in their UVC driver that
hasn't been added specifically for bulk endpoints. Neither the UVC
specification nor the USB specification forbid sending a
CLEAR_FEATURE(HALT) request to the streaming interface bulk endpoint in
this case.
It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate
setting (section 9.4.10). In that case the Linux USB core sends a
CLEAR_FEATURE(HALT) request to every endpoint of that interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip
Windows 7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7
and not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be
welcome :-)
https://wikidevi.com/wiki/82066163-7050-ab49-b8cc-b3855e8d2252
See attachment with a testprogram.
That's really interesting. Do you think we could integrate that in libv4l ?
May be, we should retest if we really can get better exposure. What was
your experience with it?

I'll collect more information about other XUs used by win driver. Right
now i have fallowing information:
- on stream start and stream end windows set LED in automatic mode.
- clear_halt is probably workaround for some bug which i get if i stop
the stream from virtual machine.
Post by Laurent Pinchart
Post by Oleksij Rempel
Post by Laurent Pinchart
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
It works too. I was just afraid to be too different form MS implementation.
Manufactures usually test it against MS driver so it sort of dictate
specification.
I think I agree with you. Could you please test the following patch ?
It is not working. Your patch is setting Interface to 0x80, but it
should set it to 0x81.
Laurent Pinchart
2014-02-25 23:00:48 UTC
Permalink
Hi Oleksij,
Post by Oleksij Rempel
Post by Laurent Pinchart
[snip]
Post by Oleksij Rempel
Post by Laurent Pinchart
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in
their own way by sending a CLEAR_FEATURE(HALT) request when stopping
the video stream, or if that's a standard procedure in their UVC
driver that hasn't been added specifically for bulk endpoints. Neither
the UVC specification nor the USB specification forbid sending a
CLEAR_FEATURE(HALT) request to the streaming interface bulk endpoint
in this case.
It should be noted that the USB specification allows devices to stall
a SET_INTERFACE(0) request for an interface that has a single
alternate setting (section 9.4.10). In that case the Linux USB core
sends a CLEAR_FEATURE(HALT) request to every endpoint of that
interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip
Windows 7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7
and not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be
welcome :-)
https://wikidevi.com/wiki/82066163-7050-ab49-b8cc-b3855e8d2252
See attachment with a testprogram.
That's really interesting. Do you think we could integrate that in libv4l ?
May be, we should retest if we really can get better exposure. What was
your experience with it?
None :-) I've never tested it.
Post by Oleksij Rempel
I'll collect more information about other XUs used by win driver. Right
- on stream start and stream end windows set LED in automatic mode.
- clear_halt is probably workaround for some bug which i get if i stop
the stream from virtual machine.
Post by Laurent Pinchart
Post by Oleksij Rempel
Post by Laurent Pinchart
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
It works too. I was just afraid to be too different form MS
implementation. Manufactures usually test it against MS driver so it sort
of dictate specification.
I think I agree with you. Could you please test the following patch ?
It is not working. Your patch is setting Interface to 0x80, but it
should set it to 0x81.
OK, next try :-) Please see below.
Laurent Pinchart
2014-02-26 00:07:07 UTC
Permalink
(As a side note, usb_clear_halt() should really take an endpoint address
as argument, not a pipe, the code would become much simpler...)
Patches are always welcome :)
Would that be accepted ? The pipe concept originates from a long long time
ago, I was worried touching it now would awake some old demons long asleep in
the depths of the kernel.
--
Regards,

Laurent Pinchart
Oleksij Rempel
2014-02-26 08:21:56 UTC
Permalink
Post by Laurent Pinchart
Hi Oleksij,
Post by Oleksij Rempel
Post by Laurent Pinchart
[snip]
Post by Oleksij Rempel
Post by Laurent Pinchart
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in
their own way by sending a CLEAR_FEATURE(HALT) request when stopping
the video stream, or if that's a standard procedure in their UVC
driver that hasn't been added specifically for bulk endpoints. Neither
the UVC specification nor the USB specification forbid sending a
CLEAR_FEATURE(HALT) request to the streaming interface bulk endpoint
in this case.
It should be noted that the USB specification allows devices to stall
a SET_INTERFACE(0) request for an interface that has a single
alternate setting (section 9.4.10). In that case the Linux USB core
sends a CLEAR_FEATURE(HALT) request to every endpoint of that
interface.
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
If Windows XP and Windows 8 behave the same way I suppose we can skip
Windows 7.
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7
and not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Nice... If you've reversed-engineered RightLight information would be
welcome :-)
https://wikidevi.com/wiki/82066163-7050-ab49-b8cc-b3855e8d2252
See attachment with a testprogram.
That's really interesting. Do you think we could integrate that in libv4l ?
May be, we should retest if we really can get better exposure. What was
your experience with it?
None :-) I've never tested it.
Post by Oleksij Rempel
I'll collect more information about other XUs used by win driver. Right
- on stream start and stream end windows set LED in automatic mode.
- clear_halt is probably workaround for some bug which i get if i stop
the stream from virtual machine.
Post by Laurent Pinchart
Post by Oleksij Rempel
Post by Laurent Pinchart
What would you think about calling both usb_set_interface() and
usb_clear_halt() for bulk-based devices ? Something like
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting == 1)
+ usb_clear_halt(stream->dev->udev,
+ stream->header.bEndpointAddress);
It works too. I was just afraid to be too different form MS
implementation. Manufactures usually test it against MS driver so it sort
of dictate specification.
I think I agree with you. Could you please test the following patch ?
It is not working. Your patch is setting Interface to 0x80, but it
should set it to 0x81.
OK, next try :-) Please see below.
Oleksij Rempel
2014-02-17 09:05:41 UTC
Permalink
Post by Laurent Pinchart
Hi Oleksij,
Thank you for the patch.
Post by Oleksij Rempel
Current uvcvideo driver do not correctly disables stream on
Bulk VideoStream EP. This couse problems on a webcam buildin
to Asus Zenbook UX302LA. For example it will be not disabled
and can't be strated after usb port was suspended.
s/srated/started/
Post by Oleksij Rempel
Since usb_set_interface can be used only on Iso EP. We need some
way to handle Bulk VS EP.
Widnwos (xp - 8) uvcvideo driver use usb_clear_halt
s/Widnwos/Windows/
Post by Oleksij Rempel
in this case. It seems to be correct way to hadle Bulk and Int EPs.
s/hadle/handle/
Do you mind if I fix the typos and grammar when applying the patch to my tree
?
It will be great! Thank you :)
Post by Laurent Pinchart
Post by Oleksij Rempel
And it solves this problem on UX302LA ultrabook.
---
drivers/media/usb/uvc/uvc_video.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
I've copied the content of your other e-mail below to keep all discussions in
one place.
Post by Oleksij Rempel
Hello all,
i have Asus UX302LA with buildin uvc webcam: 1bcf:2987 Sunplus
Innovation Technology Inc.
Could you please send me the lsusb -v output for that camera ?
Suddenly lsusb can't completely decode this descriptor.
Post by Laurent Pinchart
Post by Oleksij Rempel
This cam uses bulk stream and has some troubles with current linux uvc
driver. It is driver bug since it works on plain uvcvideo windows driver
(even XP SP2 :)).
- the cam will work first time with all linux apps
- after stream off it will take about 4 seconds untill webcam LED will
go off too. The time is equal to usbautosuspend settings.
- it will be impossible to start webcam second time. Even no reboot to
windows will help. Only complete power off will restore functionality.
- if i disable asbautosuspend, webcam will work, but LED will never go
off even if it is not used.
It looks like VS interface is not turned off on Linux and in combination
with usb autosuspend, webcam or usb link will go to nirvana.
I agree with your analysis. Your camera seems to never stop the stream and to
crash when suspended while the stream is active.
Post by Oleksij Rempel
After comparing usb log from windows and linux i found that this webcam
need CLEAR HALT of VideoStreaming interface. Linux driver will do only
SET INTERFACE command. Suddenly i don't have other bulk webcams to see
if windows do it with all of them.
Here is comparison of different webcams and operations which do windows8
Asus UX302LA (UVC 1.00; Bulk) - 1bcf:2987 Sunplus Innovation Technology Inc.
• CLEAR HALT (Interface=0x1) VS interface
The UVC specification doesn't mention clearing the streaming interface control
endpoint halt status. The specification actually doesn't state how the host
should control stream start/stop for devices that use bulk endpoints. That's a
shortcoming of UVC in my opinion
Are there any thing it specification uvc 1.0? I found only 1.1 and 1.5.
Another documentation from Cypress, "AN75779 How to Implement an Image
Sensor Interface Using EZ-USB ® FX3TM in a USB Video Class (UVC)
Framework", paragraph "5.9 Terminating the Video Streaming":

"When the application closes, it issues a clear feature request on a
Windows platform or a Set Interface with alternate setting = 0 request
on a Mac platform."

It confirms your assumption that there is no clear way to handle bulk
stream.
Post by Laurent Pinchart
I don't know whether Microsoft has decided to address this issue in their own
way by sending a CLEAR_FEATURE(HALT) request when stopping the video stream,
or if that's a standard procedure in their UVC driver that hasn't been added
specifically for bulk endpoints. Neither the UVC specification nor the USB
specification forbid sending a CLEAR_FEATURE(HALT) request to the streaming
interface bulk endpoint in this case.
It should be noted that the USB specification allows devices to stall a
SET_INTERFACE(0) request for an interface that has a single alternate setting
(section 9.4.10). In that case the Linux USB core sends a CLEAR_FEATURE(HALT)
request to every endpoint of that interface.
I tested this webcam with Windows Xp and 8. It was handled in same way:
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces. I
suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and not
doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
Post by Laurent Pinchart
Post by Oleksij Rempel
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c index 898c208..9d335c0 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1847,7 +1847,15 @@ int uvc_video_enable(struct uvc_streaming *stream, int enable)
if (!enable) {
uvc_uninit_video(stream, 1);
- usb_set_interface(stream->dev->udev, stream->intfnum, 0);
+ if (stream->intf->num_altsetting > 1) {
+ usb_set_interface(stream->dev->udev,
+ stream->intfnum, 0);
+ } else {
+ usb_clear_halt(stream->dev->udev,
+ usb_rcvctrlpipe(stream->dev->udev,
+ stream->intfnum));
usb_rcvctrlpipe() expects an endpoint number as its second argument, not an
interface number. The following call should do.
usb_clear_halt(stream->dev->udev, stream->header.bEndpointAddress);
We probably need to validate the streaming header bEndpointAddress field when
probing the device to ensure that we won't call usb_clear_halt() on an
unrelated endpoint.
Post by Oleksij Rempel
+ }
+
This might cause a regression with other bulk devices that expect a
SET_INTERFACE(0), or don't expect a CLEAR_FEATURE(HALT), although I suppose
those devices wouldn't work with Windows then. I've tested you patch (with the
above modification) with the only bulk device I own and it doesn't seem to
cause any regression.
I assume, my cam was produced after XP uvc driver. So it should be
default behaviour.
--
Regards,
Oleksij
Laurent Pinchart
2014-03-04 10:45:06 UTC
Permalink
Hi Oleksij,
[snip]
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and
not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
I've had a contact with someone at Logitech, and they're as surprised as I am.
Could you tell me how to reproduce this ? Which exact version of Windows does
access the Logitech XUs without installing any Logitech-specific software ?
Does it do so out of the box after a fresh install ? What camera should be
used to reproduce that ?
--
Regards,

Laurent Pinchart
Oleksij Rempel
2014-03-04 11:05:26 UTC
Permalink
Post by Laurent Pinchart
Hi Oleksij,
[snip]
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7 and
not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
I've had a contact with someone at Logitech, and they're as surprised as I am.
Could you tell me how to reproduce this ? Which exact version of Windows does
access the Logitech XUs without installing any Logitech-specific software ?
Does it do so out of the box after a fresh install ? What camera should be
used to reproduce that ?
Windows 8.0. Just plug&play.
No extra software was installed. I was able to reproduce it with default
ASUS install and fresh install in VirtualBox.
To reproduce it i used some default Widnows8 Camera App. Not VLC or
Logitech software was installed.

On C920, C905, C600, E3500. Not all of them have RightLite, but all have
LED. I can provide wiresharks caps if you need.
--
Regards,
Oleksij
Laurent Pinchart
2014-03-04 11:15:01 UTC
Permalink
Hi Oleksij,
Post by Oleksij Rempel
Post by Laurent Pinchart
[snip]
only CLEAR_FEATURE(HALT) was send.
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C905: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
The CLEAR_FEATURE(HALT) request is targeted at endpoints, not interfaces.
I suppose you mean endpoint 0x87 here (EP 7 IN) ?
yes
Post by Laurent Pinchart
Similarly, with your bulk
webcam, to which endpoint is the CLEAR_FEATURE(HALT) request sent ?
EP 1 IN (0x81)
Post by Laurent Pinchart
Post by Oleksij Rempel
Logitech C600: (UVC - 1.00; ISO)
• SET INTERFACE (Interface=1)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
Logitech E3500: (UVC - 1.00; ISO)
• CLEAR HALT (Interface=0x7) Halt interrupt EP
• SET INTERFACE (Interface=1) (different order then in c600 and c905 )
Logitech C920: (UVC 1.00; ISO)
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
Asus UX31A (UVC - 1.00; ISO) - 04f2:b330 Chicony Electronics Co., Ltd
Asus 720p CMOS webcam
• SET INTERFACE (Interface=1)
• Interrupt is EP 3, why it is not halted?
So far it looks like Windows8 use CLEAR HALT for Bulk and SET INTERFACE
for Iso.
What about Windows XP and Windows 7 ? Do they use the same scheme ?
Windows XP uses only SET INTERFACE on this webcam. Windows 7 not tested
for now - should i?
Post by Laurent Pinchart
Post by Oleksij Rempel
But i don't understand why Windows8 trying to halt Interrupt if EP=7
and not doing that if EP=3?
No idea... I wonder if the Windows UVC driver includes device quirks.
Yes, Windows 8 knows more about this webcam's then i would like to. For
example it uses intensively Logitech specific XUs (without installing
Logitech software): Right Light registers; some think what looks like
watch dog. May be it knows how to disable LED :) NSA friendly system...
I've had a contact with someone at Logitech, and they're as surprised as I
am. Could you tell me how to reproduce this ? Which exact version of
Windows does access the Logitech XUs without installing any
Logitech-specific software ? Does it do so out of the box after a fresh
install ? What camera should be used to reproduce that ?
Windows 8.0. Just plug&play.
No extra software was installed. I was able to reproduce it with default
ASUS install and fresh install in VirtualBox.
To reproduce it i used some default Widnows8 Camera App. Not VLC or
Logitech software was installed.
On C920, C905, C600, E3500. Not all of them have RightLite, but all have
LED. I can provide wiresharks caps if you need.
One wireshark capture trace showing Windows accessing a Logitech-specific XU
would be great, thanks.
--
Regards,

Laurent Pinchart
Loading...