> >>> If you assume a Linux-USB system that's fully set up with the
> >>> hotplugging tools, what functionality is missing?
>
> >> The words "If you assume" in the above state the problem quite
> >> clearly. No such assumption can be made, and when you take that
> >> assumption out of the equatio
Hi David.
Basically, we need to guarantee that on resume, all CURRENTLY
PLUGGED IN hardware gets initialised to a known state, and anything
short of that is just plain buggy. This includes the case where on
resume, devices are found plugged into different ports than on
su
> >> Basically, we need to guarantee that on resume, all CURRENTLY
> >> PLUGGED IN hardware gets initialised to a known state, and anything
> >> short of that is just plain buggy. This includes the case where on
> >> resume, devices are found plugged into different ports than on
> >> suspend.
>
>
Hi David.
>> Basically, we need to guarantee that on resume, all CURRENTLY
>> PLUGGED IN hardware gets initialised to a known state, and anything
>> short of that is just plain buggy. This includes the case where on
>> resume, devices are found plugged into different ports than on
>> suspend.
>
Hi Vojtech.
>> USB printer drivers on Windows for some manufacturers use the device
>> serial number to keep track of where the user plugged in a specific
>> printer, to keep that printer's settings correct. Lots of printers
>> do not have serial numbers, so those driver authors have to use the
On Tue, Dec 18, 2001 at 09:58:48AM +0100, [EMAIL PROTECTED] wrote:
> > - USB modem:
> > - Simon only has 1 modem, so no matter where he plugges it in on
> > the USB topology, it will always be referenced as the same
> > modem: /dev/ttyACM0
>
> But will any settings he has made to
> - USB modem:
> - Simon only has 1 modem, so no matter where he plugges it in on
> the USB topology, it will always be referenced as the same
> modem: /dev/ttyACM0
But will any settings he has made to his modem be restored ?
If he presses suspend while his terminal program is
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
Hi Martin.
>> 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:
> [several sequences to unplug/replug same/different device while
> suspended]
>> The first three sequ
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
> Basically, we need to guarantee that on resume, all CURRENTLY PLUGGED IN
> hardware gets initialised to a known state, and anything short of that
> is just plain buggy. This includes the case where on resume, devices are
> found plugged into different ports than on suspend.
If you assume a Linu
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
> [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
On Sun, 16 Dec 2001, Riley Williams wrote:
> 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:
>
[several sequences to unplug/replug same/different device while suspended
16 matches
Mail list logo
