On Tue, Jun 19, 2007 at 10:28:24AM -0400, Alan Stern wrote:
> On Mon, 18 Jun 2007, Greg KH wrote:
>
> > > I believe usbfs does a little->native endian conversion on a couple of
> > > the
> > > 2-byte device descriptor fields (the vendour and product ids, if my
> > > memory is
> > > working corr
On Mon, 18 Jun 2007, Greg KH wrote:
> > I believe usbfs does a little->native endian conversion on a couple of the
> > 2-byte device descriptor fields (the vendour and product ids, if my memory
> > is
> > working correctly today). It'd be okay with me if that weren't done,
> > although
> > it'd
On Mon, Jun 18, 2007 at 10:34:03PM -0400, Dave Mielke wrote:
> [quoted lines by Greg KH on 2007/06/18 at 18:55 -0700]
>
> >What specific data do you want to see be being returned here?
>
> Every USB device has a piece of top-level static data known as a device
> descriptor. It's cached by the ker
[quoted lines by Greg KH on 2007/06/18 at 18:55 -0700]
>What specific data do you want to see be being returned here?
Every USB device has a piece of top-level static data known as a device
descriptor. It's cached by the kernel when the device is connected, and is
returned as the first 18 bytes r
On Mon, Jun 18, 2007 at 05:19:46PM -0400, Dave Mielke wrote:
> [quoted lines by Greg KH on 2007/06/18 at 13:36 -0700]
>
> >No, we DO NOT PUT DEVICE NODES IN SYSFS!
> >
> >Sorry for yelling, but this comes up every 3-4 months or so for the past
> >4-5 years and it's getting a bit annoying :)
> >
>
On Mon, Jun 18, 2007 at 05:24:12PM -0400, Alan Stern wrote:
> On Mon, 18 Jun 2007, Greg KH wrote:
>
> > > Greg, what do you think? Is it reasonable to add a binary sysfs
> > > attribute file containing the device descriptor? (And perhaps also one
> > > containing the current configuration descr
On Mon, 18 Jun 2007, Greg KH wrote:
> > Greg, what do you think? Is it reasonable to add a binary sysfs
> > attribute file containing the device descriptor? (And perhaps also one
> > containing the current configuration descriptor, and the interface
> > descriptors in their individual subdirec
[quoted lines by Greg KH on 2007/06/18 at 13:36 -0700]
>No, we DO NOT PUT DEVICE NODES IN SYSFS!
>
>Sorry for yelling, but this comes up every 3-4 months or so for the past
>4-5 years and it's getting a bit annoying :)
>
>Device nodes go in /dev/ That's what the LSB specifies and to do
>something
On Mon, Jun 18, 2007 at 01:00:01PM -0400, Alan Stern wrote:
> On Mon, 18 Jun 2007, Dave Mielke wrote:
>
> > [quoted lines by Alan Stern on 2007/06/18 at 12:03 -0400]
> >
> > >I shouldn't think it would be too much harder to read several sysfs
> > >files than a single usbfs file.
> >
> > Except
On Mon, 18 Jun 2007, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2007/06/18 at 12:03 -0400]
>
> >I shouldn't think it would be too much harder to read several sysfs
> >files than a single usbfs file.
>
> Except that it starts to get messy if each system call is protected with error
> c
[quoted lines by Alan Stern on 2007/06/18 at 12:03 -0400]
>I shouldn't think it would be too much harder to read several sysfs
>files than a single usbfs file.
Except that it starts to get messy if each system call is protected with error
checking and each piece of data read in as text is teste
On Mon, 18 Jun 2007, Dave Mielke wrote:
> What about having another sysfs device file called "descriptor" which one
> could
> read and which would return the same data as an opened usbfs file?
Well, all the information in the device and current config descriptors
is already available in sysfs, j
[quoted lines by Alan Stern on 2007/06/18 at 10:25 -0400]
>> Yes, except that the setting would be just for the close of the file
>> descriptor.
>
>You mean sort of "remember the previous setting, store a 0, then when
>the file is closed reinstate the old setting"? Sounds cumbersome and
>prone
On Sun, 17 Jun 2007, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2007/06/17 at 17:07 -0400]
>
> >I'm not sure what you're asking. Do you want a usbfs interface which
> >provides the same capability as the sysfs interface?
>
> Yes, except that the setting would be just for the close o
A few more qeustions, if I may:
Right now we search for the device by going through /proc/bus/usb/, one device
at a time, opening it, reading the device descriptor, and then either using or
closing it. Does htis mean that we're needlessly resuming/suspending all the
devices? How does lsusb do it?
[quoted lines by Rogier Wolff on 2007/06/18 at 00:14 +0200]
>I understand. FYI, I HAVE had to "recover" machines without a
>monitor available. From the sounds of the harddisk checking that
>I had succesfully logged in as root, and such.
While you or I may be able to pull off those sorts of thing
On Sun, Jun 17, 2007 at 04:33:01PM -0400, Dave Mielke wrote:
> [quoted lines by Rogier Wolff on 2007/06/17 at 20:59 +0200]
>
> >Where a friend just reported she had to reboot some device to get
> >it to work again after interrupting a command or trying somethign
> >that didn't work, I told her th
[quoted lines by Alan Stern on 2007/06/17 at 17:07 -0400]
>I'm not sure what you're asking. Do you want a usbfs interface which
>provides the same capability as the sysfs interface?
Yes, except that the setting would be just for the close of the file
descriptor.
>I doubt that the USB maintai
On Sun, 17 Jun 2007, Dave Mielke wrote:
> One of the complications with this particular model is that it supports three
> modes of operation, i.e. it supports it's own vendour's protocol and is also
> able to emulate the protocols of two other vendours. What brltty needs to do,
> therefore, is to
[quoted lines by Alan Stern on 2007/06/17 at 16:30 -0400]
>Ideally you'd like to find a way to tell when that delay is needed and
>when it isn't, or better yet, when the device has fully recovered.
>Maybe some test command that won't succeed until the device is ready to
>operate, which you cou
[quoted lines by Rogier Wolff on 2007/06/17 at 20:59 +0200]
>Where a friend just reported she had to reboot some device to get
>it to work again after interrupting a command or trying somethign
>that didn't work, I told her that I managed to revive my devices
>by removing the low level driver and
On Sun, 17 Jun 2007, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2007/06/17 at 10:48 -0400]
>
> >> >You can tell whether you have the right entry by reading
> >> >/sys/bus/usb/devices/.../devnum, which contains the usbfs device number
> >> >without leading zeros.
> >>
> >> Is it guarante
On Sat, Jun 16, 2007 at 06:04:27PM -0400, Alan Stern wrote:
> What about unplugging the device, turning its power off, then turning
> its power on and replugging it?
>
> For that matter, have you ever tried running brltty immediately after
> turning the device on? Perhaps the device needs tim
[quoted lines by Alan Stern on 2007/06/17 at 10:48 -0400]
>> >You can tell whether you have the right entry by reading
>> >/sys/bus/usb/devices/.../devnum, which contains the usbfs device number
>> >without leading zeros.
>>
>> Is it guaranteed that two busses can't have a device with the same nu
On Sun, 17 Jun 2007, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2007/06/16 at 18:04 -0400]
>
> >You can tell whether you have the right entry by reading
> >/sys/bus/usb/devices/.../devnum, which contains the usbfs device number
> >without leading zeros.
>
> Is it guaranteed that two bus
[quoted lines by Alan Stern on 2007/06/16 at 18:04 -0400]
>You can tell whether you have the right entry by reading
>/sys/bus/usb/devices/.../devnum, which contains the usbfs device number
>without leading zeros.
Is it guaranteed that two busses can't have a device with the same number. In
other
On Sat, 16 Jun 2007, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2007/06/11 at 10:55 -0400]
>
> >Do you really need a reboot, or is it enough to unplug and then replug
> >the device?
>
> It seems that it's really some kind of timing issue. Unplugging/replugging the
> device doesn't seem
[quoted lines by Alan Stern on 2007/06/11 at 10:55 -0400]
>Do you really need a reboot, or is it enough to unplug and then replug
>the device?
It seems that it's really some kind of timing issue. Unplugging/replugging the
device doesn't seem to help, but, after a reboot, the device eventually do
On Mon, 11 Jun 2007, Dave Mielke wrote:
> I'm the maintainer of BRLTTY [http://mielke.cc/brltty/]. Users of a certain
> model of braille display in conjunction with the 2.6.21 Debian kernel are
> reporting that stopping and restarting brltty causes the device to be reset in
> a way which makes it
29 matches
Mail list logo
