On Monday 11 February 2002 03:41, Pete Zaitcev wrote:
> > From: Lars Doelle <[EMAIL PROTECTED]>
> > Date: Mon, 11 Feb 2002 01:08:29 +0100
> >
> >[...]
> > There is some Linux support for IEEE 1284.4 underway, but until this is
> > working and integrated, i think one should better disable accepting
>...
>
>The obvious intention is to give kind of help for drivers to deal with
>devices which do return request_error (EP0-STALL) for SetInterface request
>on interfaces with single AS - as described in 9.4.10. However, I think
>this implementation has the potential to break USB standard conforma
> > There's no infrastructure for it yet. I'd like to see this added in the
> > 2.5 tree, building on the new device tree stuff (get the latest prepatch).
> >
> > PCI has some special methods to enable remote wakeup. In some
> > configurations, some USB devices can leverage that facility. I thi
> > >Therefore the need to do
> > > a synchronous unlink while an asynchronous unlink is happening
> > > may arise.
> >
> > I think I see what you're suggesting, but I'd basically say what I've
> > said before: drivers which are that confused about how they work
> > are really asking for trou
> > > Maybe ISO is more like a wire that carries a signal. Once the
> > > host sets a configuration which contains ISO endpoints, these wires are
> > > all "hot" and "signal jitter" is up to the functions on either end to
> > > deal with in their own way.
> >
> > I suspect that's closer to th
Well, excuse my slip of the keyboard. This board has a VIA KT133 on it.
Keep in mind that you are dealing with an absent-minded old geezer of a
professor at this end. And thanks for pointing out the mistake so someone
else does not get confused.
Theodore Kilgore
On Mon, 11 Feb 2002, Martin Diehl
> From: Lars Doelle <[EMAIL PROTECTED]>
> Date: Mon, 11 Feb 2002 01:08:29 +0100
>[...]
> There is some Linux support for IEEE 1284.4 underway, but until this is
> working and integrated, i think one should better disable accepting these
> protocols, as it would never work in the moment.
David
On Sun, Feb 10, 2002 at 11:10:07AM +0100, Gunther Mayer wrote:
> Hi,
> the "uhci" module suffers from very bad performance (linux-2.4.17).
>
> Scanning 150dpi A4 (merlin670 for Canon N670U over libusb-0.1.4) gives:
> uhci:135 sec.
> usb-uhci: 43 sec.
> ohci: 35 sec
This should be f
> 1) After having success with the SetInterface request we do
>
> dev->toggle[0] = 0; /* 9.1.1.5 says to do this */
> dev->toggle[1] = 0;
>
> Well, as the comment suggests, according to 9.1.1.5 we have to reset the
> toggles - but only "with endpoints in the affected interfaces". The above
> cod
Find attached a patch to make my printer working with the usb printer driver.
The printer is a HP Laserjet 1200.
The problem fixed with the patch is that the printer offers a IEEE 1284.4
compatible protocol, which is picked by the driver because of the sorting
order of the descriptors. The pr
> In principle, there is a specified behavior for usb devices when the PC goes
> to standby or wakes up. The other way round, as good as i understand, a usb
> device should be able to wake a sleeping PC.
>
> Can anyone please let me know whether we already have the required
> infrastructure in
Folks,
working to make a firmware for a usb device feature complete, i have
especially power management as an open topic.
In principle, there is a specified behavior for usb devices when the PC goes
to standby or wakes up. The other way round, as good as i understand, a usb
device should be a
[CC's trimmed]
On Sun, 10 Feb 2002, Theodore Kilgore wrote:
> I am running usb-uhci on a box with 1G Athlon and SIS chipset (FIC AZ11
^^^
Looks somewhat supsicious to me: all SiS chipsets with USB support I've
ever seen are OHCI. Is this an a
Hi,
two things from usbcore's usb_set_inteface() implementation which I'm
somewhat concerned about:
1) After having success with the SetInterface request we do
dev->toggle[0] = 0; /* 9.1.1.5 says to do this */
dev->toggle[1] = 0;
Well, as the comment suggests, according to
Hello,
I am running usb-uhci on a box with 1G Athlon and SIS chipset (FIC AZ11
board) and kernel 2.4.17. I compiled the usb-uhci support in the kernel
(CONFIG_USB_UHCI_ALT=y),
not a module (not, I suspect, that this makes any difference in time
tests; I just felt like doing it that way).
I have
This provides slightly better documentation on error codes.
- identifies ones that typically indicate bad hardware
- includes one missing code
- more complete/accurate descriptions for several codes
- etc
It also helps me clear out entries in my mailbox saying that
this needs doi
Hi Greg,
The enclosed patch adds support for RTL8150-based USB network adapters
(such as the Linksys USB100M EtherFast 10/100 Compact USB Network Adapter)
to 2.4.18-pre9. It is based on [EMAIL PROTECTED]'s old 2.4.0 driver,
which was in turn based on the pegasus driver.
Please apply.
Cheers
Ma
On Sunday 10 February 2002 06:38 am, Bertrik Sikken wrote:
>Hi,
>
>Gunther Mayer wrote:
>> the "uhci" module suffers from very bad performance
>> (linux-2.4.17).
>>
>> Scanning 150dpi A4 (merlin670 for Canon N670U over
>> libusb-0.1.4) gives: uhci:135 sec.
>> usb-uhci: 43 sec.
>> ohci:
Hi,
Gunther Mayer wrote:
> the "uhci" module suffers from very bad performance (linux-2.4.17).
>
> Scanning 150dpi A4 (merlin670 for Canon N670U over libusb-0.1.4) gives:
> uhci:135 sec.
> usb-uhci: 43 sec.
> ohci: 35 sec
>
> This corresponds to about 50K/sec for 'uhci' (and the s
Hi,
the "uhci" module suffers from very bad performance (linux-2.4.17).
Scanning 150dpi A4 (merlin670 for Canon N670U over libusb-0.1.4) gives:
uhci:135 sec.
usb-uhci: 43 sec.
ohci: 35 sec
This corresponds to about 50K/sec for 'uhci' (and the scanner must stop'n'start) !
Is this a
20 matches
Mail list logo
