>> = ???
> = David Brownell
>> Would it be possible (or reasonable) to add an ioctl to usbdevfs which
>> can ask for this information via the /proc/bus/usb/###/### interface? Or
>> should the printer.o module execute a user-space helper app to do this
>> configuration itself?
>IMHO, either of t
= Adam Richter
>>> = Oliver Neukum
>> = Adam Richter
>= Oliver Neukum
[...] move all Human Input Device USB drivers to user land. [...]
>>>At least keyboard has to remain in kernel, else no sysreq nor sak nor
>>>scrollback during boot.
>> That is already the situation whe
Brad Hards wrote:
>
> Miles Lane wrote:
> > Thanks, Johannes. I am trying to keep momentum up
> > to move us towards having only one UHCI driver.
> A long and torturous journey, methinks.
>
> > BTW: I am really looking forward to hearing what came out
> > of your Linux hotplug session at the K
Miles Lane wrote:
> Thanks, Johannes. I am trying to keep momentum up
> to move us towards having only one UHCI driver.
A long and torturous journey, methinks.
> BTW: I am really looking forward to hearing what came out
> of your Linux hotplug session at the Kernel Workshop
> yesterday. I wish
Hello:
many users complain (and file bugs) about a flood of
the following message:
interrupt, status 3 frame# NNN
These come about 10 times a second. Some say, they correspond
to a specific device, such as mouse; others observe those
if a ZIP drive is connected but disk is not inserted.
I saw o
Johannes Erdfelt wrote:
>
> On Fri, Mar 30, 2001, Miles Lane <[EMAIL PROTECTED]> wrote:
> > Johannes, perhaps you could hack up a test script to trigger
> > this error condition with your latest uhci code and then
> > come up with a patch to work around it, as Goerg is doing
> > for usb-uhci.
>
On Fri, Mar 30, 2001, Miles Lane <[EMAIL PROTECTED]> wrote:
> Johannes, perhaps you could hack up a test script to trigger
> this error condition with your latest uhci code and then
> come up with a patch to work around it, as Goerg is doing
> for usb-uhci.
I'm not exactly sure what a possible wo
> >
> > Please think of things like forcefeedback.
>
> Also, what about making it possible to use USB mice with gpm during
> boot?
Or even about typing in your password if an fsck is needed.
This scheme is IMHO unworkable.
Regards
Oliver
Am Samstag 31 März 2001 14:24 schrieb Adam J. Richter:
> >> = Adam Richter
> >
> > = Oliver Neukum
> >
> >>I am currently interested in the USB user level drivers because
> >> I think it may be better to move all Human Input Device USB drivers
> >> to user land. The HID "report" descriptors
Hey all. I was wondering if anyone has played w/ makeing the usb-uhci
driver big-endian happy. Right now I get:
Mar 31 10:38:13 Milo kernel: usb-uhci.c: $Revision: 1.259 $ time 10:34:09 Mar 31 2001
Mar 31 10:38:13 Milo kernel: usb-uhci.c: High bandwidth mode enabled
Mar 31 10:38:13 Milo kernel:
Hi,
just an extension to my last mail:
Under 2.4.2 with an original Intel UHCI, the babble is properly detected by
usb-uhci (URB state -32). So it is 99.9%% a problem in VIA's view of UHCI...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh
Oliver Neukum wrote:
>
> > I am currently interested in the USB user level drivers because
> > I think it may be better to move all Human Input Device USB drivers
> > to user land. The HID "report" descriptors are fairly complex, so
>
> No !
>
> At least keyboard has to remain in kernel,
Hmm. This work that you are doing sounds like it might
have value beyond the USB domain. Perhaps you should
be CCing [EMAIL PROTECTED]?
It's important that everyone doing hotplug related work
keep linux-hotplug-devel in the loop.
Cheers,
Miles
Tim Jansen wrote:
>
> On Fri, Mar 30, 20
> From: "Tim Jansen" <[EMAIL PROTECTED]>
> Sent: Saturday, March 31, 2001 12:40 AM
>
> I'm working on the device registry patch (www.tjansen.de/devreg) that allows
> you to retrieve the DevFS filename of a physical device. The next release
> will be in a couple of days and adds a DEVICEID environ
> Would it be possible (or reasonable) to add an ioctl to usbdevfs which
> can ask for this information via the /proc/bus/usb/###/### interface? Or
> should the printer.o module execute a user-space helper app to do this
> configuration itself?
IMHO, either of those would be reasonable 2.4 soluti
>> = Adam Richter
> = Oliver Neukum
>> I am currently interested in the USB user level drivers because
>> I think it may be better to move all Human Input Device USB drivers
>> to user land. The HID "report" descriptors are fairly complex, so
>No !
>At least keyboard has to remain in ker
> I am currently interested in the USB user level drivers because
> I think it may be better to move all Human Input Device USB drivers
> to user land. The HID "report" descriptors are fairly complex, so
No !
At least keyboard has to remain in kernel, else no sysreq nor sak nor
scrollbac
I guess it has been a few releases since I last thought
about the /proc/bus/usb facilities, and it looks like
linux-2.4.3/drivers/usb/devio.c contains some handy new ioctl's,
like USBDEVFS_{SUBMIT,DISCARD,REAP}URB. It looks like it is now
possible to write a user level USB driver that can
On Fri, Mar 30, 2001 at 03:26:54PM -0500, Allen Barnett wrote:
> after printer.o is loaded, however, there doesn't seem to be enough
> information passed in from the hotplug invocation to extract the minor
> device number of the newly plugged in device. (The user-space daemons
> want to access /de
hi,
I tried to unsubscribe, but the list complains that I gave the wrong
password, since I thought it would be sufficient to give my source-forge-
password (this list is hosted on sourceforge, isn't it?). The help-file
I got from the list doesn't have an entry like: "I've forgot my password,
ple
20 matches
Mail list logo
