Greg KH wrote:
On Fri, Feb 08, 2008 at 03:03:57PM -0800, David Brownell wrote:
On Tuesday 05 February 2008, Alan Nisota wrote:
And as far as getting the vendor to fix the device, I've asked, but
they've been extremely reluctant to support Linux in the past. We'll
see what they say.
Don't pre
On Friday 08 February 2008, David Brownell wrote:
> > If the vendor is using the official USB markings on their device, they
> > would also be in trademark violation with the usb.org working group, a
> > body that takes these things very seriously.
Specifically any of the conformance logos visible
On Friday 08 February 2008, Greg KH wrote:
> On Fri, Feb 08, 2008 at 03:03:57PM -0800, David Brownell wrote:
> > On Tuesday 05 February 2008, Alan Nisota wrote:
> > > And as far as getting the vendor to fix the device, I've asked, but
> > > they've been extremely reluctant to support Linux in the
On Fri, Feb 08, 2008 at 03:03:57PM -0800, David Brownell wrote:
> On Tuesday 05 February 2008, Alan Nisota wrote:
> > And as far as getting the vendor to fix the device, I've asked, but
> > they've been extremely reluctant to support Linux in the past. We'll
> > see what they say.
>
> Don't pre
On Tuesday 05 February 2008, Alan Nisota wrote:
> And as far as getting the vendor to fix the device, I've asked, but
> they've been extremely reluctant to support Linux in the past. We'll
> see what they say.
Don't present it as "supporting Linux".
Present it as: your device is blatantly NON
On Tuesday 05 February 2008, Alan Nisota wrote:
> And as far as getting the vendor to fix the device, I've asked, but
> they've been extremely reluctant to support Linux in the past. We'll
> see what they say.
Don't present it as "supporting Linux".
Present it as: your device is blatantly con
On Tue, 5 Feb 2008, Pete Zaitcev wrote:
> I think a proper patch would be welcome, because this is what
> Alan wrote:
>
> > As far as I can tell, Linux doesn't try to prevent high-speed devices
> > from using illegal maxpacket sizes. ehci-hcd should accept anything up
> > to 2047 without complai
Pete Zaitcev wrote:
On Tue, 05 Feb 2008 18:32:35 -0800, Alan Nisota wrote:
Well, this hack allows me to read without babble on my newer machines,
but the one I really need it to work on has an older motherboard, and
refuses to accept the 1024 byte packets. I'll need to either work iwth
the v
On Tuesday 05 February 2008, Alan Nisota wrote:
> >> Try to patch max_packet(maxp) into it and see if that works.
> >> Use the interrupt case for guidance.
> ...
>
> Well, this hack allows me to read without babble on my newer machines,
> but the one I really need it to work on has an older moth
On Tue, 05 Feb 2008 18:32:35 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> Well, this hack allows me to read without babble on my newer machines,
> but the one I really need it to work on has an older motherboard, and
> refuses to accept the 1024 byte packets. I'll need to either work iwth
>
Alan Nisota wrote:
Pete Zaitcev wrote:
drivers/usb/host/ehci-q.c:
qh_make() {
switch (urb->dev->speed) {
case USB_SPEED_HIGH:/* no TT involved */
info1 |= (2 << 12);/* EPS "high" */
... if (type == PIPE_BULK) {
info1 |= (EHCI_TUNE_RL_HS << 28);
Pete Zaitcev wrote:
On Mon, 04 Feb 2008 14:01:21 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
This implies that endpoint 0x82 is a bulk endpoint. So what type is
it really?
It's identified as bulk.
If would be really nice if you sent us your /proc/bus/usb/devices
to begin with, but if 82
On Mon, 04 Feb 2008 14:01:21 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> > This implies that endpoint 0x82 is a bulk endpoint. So what type is
> > it really?
> It's identified as bulk.
If would be really nice if you sent us your /proc/bus/usb/devices
to begin with, but if 82 is indeed a bu
On Mon, 4 Feb 2008, Alan Nisota wrote:
> Ok, so I examined the data in the transfer_buffer (even though
> actual_length is 0) and it does have the correct data returned from the
> device.
> The question I have now is, what do I do?
You could ask the manufacturer for information. Sometimes that
Alan Nisota wrote:
Alan Stern wrote:
This implies that endpoint 0x82 is a bulk endpoint. So what type is
it really?
It's identified as bulk.
Maybe the device really does try to send packets that are larger than
the maximum allowed limit. That would explain your problems,
especially if Windo
On Mon, 4 Feb 2008, Alan Nisota wrote:
> Alan Stern wrote:
> > On Mon, 4 Feb 2008, Alan Nisota wrote:
> >
> >> I am trying to write a usb device driver for an R5000 modified
> >> set-top-box. This just adds a USB interface to the decoded signal from
> >> a satellite STB so you can save whateve
Pete Zaitcev wrote:
On Mon, 04 Feb 2008 08:30:37 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
[...] If I do
this using blocking reads, the device never sends any data back It
appears to be waiting for multiple bulk request URBS in the queue. This
apparently eliminates my ability to use li
Alan Stern wrote:
On Mon, 4 Feb 2008, Alan Nisota wrote:
I am trying to write a usb device driver for an R5000 modified
set-top-box. This just adds a USB interface to the decoded signal from
a satellite STB so you can save whatever is currently being watched on TV.
I snooped the USB bus in
On Mon, 04 Feb 2008 08:30:37 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> [...] If I do
> this using blocking reads, the device never sends any data back It
> appears to be waiting for multiple bulk request URBS in the queue. This
> apparently eliminates my ability to use libusb, so now I
On Mon, 4 Feb 2008, Alan Nisota wrote:
> I am trying to write a usb device driver for an R5000 modified
> set-top-box. This just adds a USB interface to the decoded signal from
> a satellite STB so you can save whatever is currently being watched on TV.
>
> I snooped the USB bus in Windows, an
20 matches
Mail list logo
