UVC 1.5於linux gadget實作(2)
做了一陣子UVC1.5在Windows 8.1上的開發
感覺Microsoft似乎沒有把UVC1.5真的給實作完成
目前號稱有支援UVC1.5的Logitech connect cam
拿來用Cam Diagnostics來分析
看到的都是support UVC1.0...Orz...
實際上Logitech在Windows 8.1上
在Composite Device與Image Device各加了一個自己的driver
通通移除掉後發現變成只支援YUV&MJPG的裝置
原先的H.264 pin也消失
我猜driver一部分功能就是將configuration分成兩個來設定
UVC 1.5 spec提到的multiple configurations,MS所提供的host軟體並沒有能力可以選擇
Logitech應該是利用driver去解決UVC1.1與UVC1.5兩個streaming interface個數不同的問題
另外,從抓到的USB packet看來
Logitech是真的傳送UVC 1.5的packet格式沒錯
但是Cam Diagostics卻認為Logitech connect是UVC 1.0的裝置
只能猜測driver是否扮演了translator的角色
將device傳過來的UVC 1.5 packet翻譯成UVC 1.0(或是UVC 1.1)的packet格式後
再傳給host端去使用
而host端送過來的UVC 1.1 packet又翻譯成UVC 1.5的格式再送過去給device
這比較能解釋為何Logitech捨棄通用的UVC spec不用,改用自己的driver
所以要自己寫driver做這樣的事嗎??? Orz...
感覺Microsoft似乎沒有把UVC1.5真的給實作完成
目前號稱有支援UVC1.5的Logitech connect cam
拿來用Cam Diagnostics來分析
看到的都是support UVC1.0...Orz...
實際上Logitech在Windows 8.1上
在Composite Device與Image Device各加了一個自己的driver
通通移除掉後發現變成只支援YUV&MJPG的裝置
原先的H.264 pin也消失
我猜driver一部分功能就是將configuration分成兩個來設定
UVC 1.5 spec提到的multiple configurations,MS所提供的host軟體並沒有能力可以選擇
Logitech應該是利用driver去解決UVC1.1與UVC1.5兩個streaming interface個數不同的問題
另外,從抓到的USB packet看來
Logitech是真的傳送UVC 1.5的packet格式沒錯
但是Cam Diagostics卻認為Logitech connect是UVC 1.0的裝置
只能猜測driver是否扮演了translator的角色
將device傳過來的UVC 1.5 packet翻譯成UVC 1.0(或是UVC 1.1)的packet格式後
再傳給host端去使用
而host端送過來的UVC 1.1 packet又翻譯成UVC 1.5的格式再送過去給device
這比較能解釋為何Logitech捨棄通用的UVC spec不用,改用自己的driver
所以要自己寫driver做這樣的事嗎??? Orz...
留言
張貼留言