Jiri Kosina ha scritto:
>> My USB mouse recently started giving me phantom scrolls (movements of
>> the mouse wheel, even I made sure the wheel was in a resting position)
>> in recently kernels. It happened too infrequently for me to care.
> Did this also start in 2.6.24, as in Mark's case?
It
Sarah Sharp ha scritto:
> On Wed, Dec 19, 2007 at 05:21:29PM +, ashish mahamuni wrote:
> But why do you want the remote machine handle communication? What underlying
> problem are you trying to solve?
Seems the old "USB over Ethernet" thread keeps popping up :-)
BYtE,
Diego.
-
To unsubscrib
Hello all.
Is there some hardcoded limit to the number of FTDI devices that can be
connected to a single system (except the maximum of 127 devices dictated
by USB spec)?
I'd need to attach quite a lot of devices (up to 60) to a single host
port, but if there's some low limit (like 16 or 32) on /d
Hello all.
I'd need to handle many USB devices (the more the best). So, to reduce
hubs number I'm going to use 7-port ones. I've found those, so far:
- USB2507 (SMSC)
- ISB1521 (Philips)
- μPD720113 (NEC)
The host is a Linux box. Does some1 know of possible problems with any
of these? Or have use
Karl Hiramoto ha scritto:
> I've had this problem with the philips ISP1521 when using full speed
> devices and USB 2.0
> http://www.themssforum.com/Drivers/Problem-when-70696/
Wow! Exactly the one I suggested (seemed the best!) :-(
But your report is about problems with Win drivers. Does it happen
Karl Hiramoto ha scritto:
But your report is about problems with Win drivers. Does it happen in
Linux too? If not, then it's not an issue, since the host is running
Linux (kernel 2.6.8 at least).
I don't think so, but i haven't tried that hub chip in quite a while.
Anyone else have had exper
David Newall ha scritto:
This does, of course,
disadvantage Linux with respect to many classes of devices, for example
GSM transceivers when used in those parts of the world^ where regulatory
requirements prohibit modification of power or frequency settings, which
effectively prohibits open-sour
Christer Weinigel ha scritto:
It isn't that easy. The "Tamper-Proof Torx" screws on a vacuum cleaner
or a toaster won't stop anybody from opening up the thing, I mean every
little hardware store stocks those Torx bits. But by using a slightly
odd screw, the company can say "look, we'we done
Christer Weinigel ha scritto:
I think it is perfectly within their rights to do so. I think it's
kind of silly to try to hide it, if someone wants to boost the maximum
transmit power, they're going to hack the firmware anyway. But if it
makes Intel happy, well... :-)
And break the HW :-) Actua
David Newall ha scritto:
"Of course", because in many parts of the world, a device who's
manufacturer fails to take reasonable steps to prevent it from being
used outside regulatory limits is illegal. Providing source code not
only is a failure to take those reasonable steps, but is quite the
David Newall ha scritto:
That's naive, since requirements differ in different jurisdictions, as
I'm sure you are perfectly aware.
Naive? Who thinks a limit can be enforced by sw is naive!
He's missing a little detail: Internet. :-)
Precisely: One purpose of the driver is to enforce local comp
Lee Mathers ha scritto:
Now we have hardware ASIC that depend on the most part a (dll in
windows) or .ko .o file under linux to provide the entire instruction
set. Think Winmodems, Winprinters etc
Well, winmodem case is the only I could *almost* understand
closed-source drivers: the al
David Newall ha scritto:
Precisely: One purpose of the driver is to enforce local compliance.
It can't *enforce* it anyway, at least if the users are all around the
world.
Yes it can. You're confusing the software with different or modified
software. Different things. And by the way, if you
13 matches
Mail list logo
