On Wed, 20 Mar 2002, Greg KH wrote:
>Oh, didn't realize that, sorry. Does anyone use it today?
Yes.
--
Dan Streetman
[EMAIL PROTECTED]
--
186,282 miles per second:
It isn't just a good idea, it's the law!
Greg KH wrote:
> Oh, didn't realize that, sorry. Does anyone use it today?
Yes, extensively.
eg. usbstress on usb.in.tum.de,
baycomusb (www.baycom.org)
Tom
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.n
> > However, the /sbin/hotplug interface can be used... But that's an
> > argument for a later time, after some more design work is done :)
>
> No, it cannot. It's event based. We need a simple and robust way
> to get that information.
I was going to make a similar point.
The "original" /sbin/h
> > Without any planing or forethought. It's procfs all over again.
>
> ???
> pcihpfs is well planned. So are all of the different filesystems
> that are now present. They do one thing, and one thing only. Much
> unlike procfs. That's why driverfs was not implemented within procfs.
All the f
On Thu, Mar 21, 2002 at 12:55:19AM +0100, Oliver Neukum wrote:
> On Thursday 21 March 2002 00:22, Greg KH wrote:
> > On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
> > > > What ones? I can't think of any right off the top of my head.
> > >
> > > ioctls for getting complex informat
ioctl has fundamentally different semantics to read/write.
An ioctl does something and returns a result, its synchronous in its
action/reply.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinf
On Thursday 21 March 2002 00:22, Greg KH wrote:
> On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
> > > What ones? I can't think of any right off the top of my head.
> >
> > ioctls for getting complex information.
>
> read() works fine for getting complex information too :)
One ki
On Wed, Mar 20, 2002 at 06:21:54PM -0500, Johannes Erdfelt wrote:
> I don't know if you have to implement it to find out. How about a rough
> design?
Will do.
> > What do you mean, "real virtual driver filesystem"?
>
> Something people will accept. /proc has been abused too much for this
> kind
On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
>
> > What ones? I can't think of any right off the top of my head.
>
> ioctls for getting complex information.
read() works fine for getting complex information too :)
> > > Folk would benefit from being able to bind/unbind drive
On Wed, Mar 20, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 20, 2002 at 05:11:13PM -0500, Johannes Erdfelt wrote:
> >
> > For those things which don't map easily, perhaps we can do some stuff
> > still as ioctl's, resetting endpoints and clearing halts for instance.
>
> Hm, have to tr
On Wed, Mar 20, 2002 at 05:11:13PM -0500, Johannes Erdfelt wrote:
>
> For those things which don't map easily, perhaps we can do some stuff
> still as ioctl's, resetting endpoints and clearing halts for instance.
Hm, have to try to implement it to see if that's really necessary.
> I'm not again
> What ones? I can't think of any right off the top of my head.
ioctls for getting complex information.
> > Folk would benefit from being able to bind/unbind drivers from
> > interfaces (viz that recent VMWare note, and there are other cases
> > too).
>
> Agreed. The pencam userspace program
On Wed, Mar 20, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 20, 2002 at 12:55:34PM -0800, David Brownell wrote:
> > > > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > > > /proc/ interface like CPiA.
> > > >
> > > > Ok, sorry for jumping in late here, but no i
On Wed, Mar 20, 2002 at 12:55:34PM -0800, David Brownell wrote:
> > > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > > /proc/ interface like CPiA.
> > >
> > > Ok, sorry for jumping in late here, but no ioctl(). I hate the current
> > > usbfs ioctl interface and do not
> > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > /proc/ interface like CPiA.
> >
> > Ok, sorry for jumping in late here, but no ioctl(). I hate the current
> > usbfs ioctl interface and do not want to see that spread at all. usbfs
> > could (and will) change to be r
On Tue, 19 Mar 2002, Nemosoft Unv. wrote:
>> > As to the /devfs name... Could be done, but I would like to put the
>> > amount of logic that is needed ina user program to a minimum, so 'old'
>> > style /dev should be listed as well.
>>
>> Major/minor is all that is really needed. If you're usin
Hi,
On Tue, Mar 19, 2002 at 10:02:22PM +0100, Nemosoft Unv. wrote:
> On Tuesday 19 March 2002 07:31, Greg KH wrote:
> > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > /proc/ interface like CPiA.
> >
> > Ok, sorry for jumping in late here, but no ioctl(). I hate the cu
Hello,
On Tuesday 19 March 2002 01:30, David Brownell wrote:
> USB standardizes two models for this kind of thing:
>
> - "compound device" such as "hub and keyboard", which is
> one physical device that appears as two USB device, each
> normally having one interface (that's not re
Greetings,
On Tuesday 19 March 2002 07:31, Greg KH wrote:
> > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > /proc/ interface like CPiA.
>
> Ok, sorry for jumping in late here, but no ioctl(). I hate the current
> usbfs ioctl interface and do not want to see that spread a
On Tue, Mar 19, 2002 at 12:32:56AM +0100, Nemosoft Unv. wrote:
> Hello,
>
> On Monday 18 March 2002 04:12, David Brownell wrote:
> > > thus no ioctl().
> >
> > There's this thing called JNI, which solves that. If they're doing stuff
> > like memory mapping the video memory, it's being used alrea
On Mon, Mar 18, 2002 at 12:48:34PM +0100, Sebastian Linz wrote:
> Don't you have an advice how I can solve the problem on my own? Until the
> end of this week I've to get my web cam-grabber work. I can't wait till
> somebody wrote necessary kernel updates. In my case I'm using the
> pwc-driver
> > For example,
> > each interface that was bound might have a "U:" line, which could
> > have "char 180/32" (and if devfs were in use, the name it uses)
>
> Remember there could be multiple U: lines (does anybody know offhand of a
> USB device that has multiple physical devices on one USB inte
Here are two whacks at this same problem.
- One from Allen Barnett for printer support. It only works
for devices published through device nodes, can't be applied
to devices, and doesn't try to do anything smart with /devfs
when it's available.
- Something I whacked up really quickly, a b
Quoting Nemosoft Unv. <[EMAIL PROTECTED]>:
> On Monday 18 March 2002 04:12, David Brownell wrote:
> > > thus no ioctl().
> >
> > There's this thing called JNI, which solves that. If they're doing stuff
> > like memory mapping the video memory, it's being used already.
> > If not, no big deal si
Hello,
On Monday 18 March 2002 04:12, David Brownell wrote:
> > thus no ioctl().
>
> There's this thing called JNI, which solves that. If they're doing stuff
> like memory mapping the video memory, it's being used already.
> If not, no big deal since the code is Linux-specific in the first place
Hi,
On Monday 18 March 2002 12:48, Sebastian Linz wrote:
>
> > Short version of the story: some simple kernel updates will solve your
> > particular issue, but someone has to write and interface and submit
> > patches for the webcams you're using. One model to follow (in the
> > kernel) is how
Hi,
> Hey, I'm the guy who did the original Java USB API (on Linux), so I'm
> not going to worry about that! (http://jusb.sourceforge.net :)
You really impress me.
> Of course I've not done a lot with it beyond still image camera support,
but that's
> because the Right Way to do webcams is lik
> > It can be solved for any particular driver just by adding usb(dev)fs ioctl
> > support to that driver.
>
> :o)
>
> > Define a structure, say FOO, that ...
>
> :o/ urgh, could you please be more concrete. As a java developer I don't
> want to spam your mailing list.
Hey, I'm the guy who d
Hi,
> It can be solved for any particular driver just by adding usb(dev)fs ioctl
> support to that driver.
:o)
> Define a structure, say FOO, that encapsulates the
> relevant device ID info ... for /dev files, major/minor and whether it's
> character or block; for network devices, something els
On Mon, 18 Mar 2002 08:49, David Brownell wrote:
> > Unfortunately, your problem cannot be solved right now. There is
> > currently no way to register the device info with a USB device, so that
> > it appears somewhere in /proc/bus/usb. There are all sorts of problems
> > with this (driver having
Greetings,
On Sunday 17 March 2002 22:49, David Brownell wrote:
> > Unfortunately, your problem cannot be solved right now. There is
> > currently no way to register the device info with a USB device, so that
> > it appears somewhere in /proc/bus/usb. There are all sorts of problems
> > with this
> Unfortunately, your problem cannot be solved right now. There is currently
> no way to register the device info with a USB device, so that it appears
> somewhere in /proc/bus/usb. There are all sorts of problems with this
> (driver having multiple configurations, multiple devices per USB devi
32 matches
Mail list logo
