Hi Greg.
>> At work, I use a USB barcode reader that appears as a serial port to
>> the software that uses it (I know coz I checked). How does that fit
>> into this scheme of things?
> Again, if it's the only usb-serial device in the system, it will
> always show up in the same place.
There's a
On Mon, Dec 24, 2001 at 07:40:12PM +, Riley Williams wrote:
> At work, I use a USB barcode reader that appears as a serial port to the
> software that uses it (I know coz I checked). How does that fit into
> this scheme of things?
Again, if it's the only usb-serial device in the system, it wi
Hi Greg.
>> Keeping that in mind, let's take some scenarios that are already here
>> and need to be dealt with by the USB subsystem:
>>
>> 1. Simon's laptop has no keyboard on the body of the laptop,
>> and is supplied with a separate one with a USB connector
>> with which Simon plug
> > The first three cases must be dealt with like normal hotplugging
> > just deferred to the time we wake up.
>
> That deferring may not always be possible. As an example, take a system
> in use by a friend of mine, basically a laptop with the keyboard not
> part of the main unit, but on the end
Yes, Zip drives have unique serial numbers, so they're properly
re-identified on resume and "reconnected" to their device node. There is
some work to be done here, tho doing a suspend with a mounted fs on the
device could lead to Bad Things(tm).
Of course, windows has the same problem if you
On Mon, Dec 17, 2001 at 07:51:49PM +, Riley Williams wrote:
>
> Keeping that in mind, let's take some scenarios that are already here
> and need to be dealt with by the USB subsystem:
>
> 1. Simon's laptop has no keyboard on the body of the laptop,
> and is supplied with a separate
On Mon, Dec 17, 2001 at 12:02:06PM -0800, Greg KH wrote:
> > That deferring may not always be possible. As an example, take a system
> > in use by a friend of mine, basically a laptop with the keyboard not
> > part of the main unit, but on the end of a USB lead that has to be
> > disconnected to
On Mon, Dec 17, 2001 at 07:30:32PM +, Riley Williams wrote:
> Remember, one of the basic design aims of USB was that the location a
> device is plugged in is irrelevant to the user. The Linux USB drivers
> need to be totally transparent to where a particular device is plugged
> in, otherwise
On Mon, Dec 17, 2001 at 07:30:32PM +, Riley Williams wrote:
>
> That deferring may not always be possible. As an example, take a system
> in use by a friend of mine, basically a laptop with the keyboard not
> part of the main unit, but on the end of a USB lead that has to be
> disconnected to
Hi Oliver.
>> If we're talking USB here (and in some cases even if we're not), we
>> need to deal with more than that. Specifically, we need to be able
>> to deal with the following sequences:
>>
>> => Device plugged in and initialised.
>> Machine suspended.
>> Device unplugged.
>>
> [several sequences to unplug/replug same/different device while suspended]
>
> > The first three sequences means that we can't guarantee that on resume,
> > the devices available will be identical to those on suspend. The last
> > sequence means that even if it is, we may need to do more than j
> If we're talking USB here (and in some cases even if we're not), we need
> to deal with more than that. Specifically, we need to be able to deal
> with the following sequences:
>
> ==> Device plugged in and initialised.
> Machine suspended.
> Device unplugged.
> Machine resum
Hi Oliver, Martin.
>> However, I do believe it is still a good idea to provide firmware
>> images from userland instead of having them compiled into the
>> kernel. Not because of some not-even-hypothetical GPL issue but
>> simply to ease maintenance.
> Absolutely. The firmware should be provided
13 matches
Mail list logo
