ADB Reset

ADB Reset

[Hubert Figuiere]

Can anybody tell me how to reset the ADB bus. Just because when I
snooze the PowerBook, the mouse become really slow....

How can I ask to redect all the ADB peripherals. I want to be able
to plug and unplug my kensington mouse.

The goal is to make a small set of utilities for this :-)

Hub
-- 
World Wide Wait: the real meaning for WWW.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Christian Jaeger]

> 
> Can anybody tell me how to reset the ADB bus. Just because when I
> snooze the PowerBook, the mouse become really slow....
>
> How can I ask to redect all the ADB peripherals. I want to be able
> to plug and unplug my kensington mouse.
>
> The goal is to make a small set of utilities for this :-)
>
> Hub
While you are at it:
Consider a reinit for SCSI, ext. Screen, Network as well since that's
changing with locations. Maybe even hot-swapping the disk/cdrom/zip-drive in
expansion bay.loading the appropriate modules on the fly.
;)


--
Chris Jaeger
Germany

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Benjamin Herrenschmidt]

On Fri, Mar 5, 1999, Hubert Figuiere <hub@point-barre.fr> wrote:

>Can anybody tell me how to reset the ADB bus. Just because when I
>snooze the PowerBook, the mouse become really slow....
>
>How can I ask to redect all the ADB peripherals. I want to be able
>to plug and unplug my kensington mouse.
>
>The goal is to make a small set of utilities for this :-)

For the reset on snooze, the adb.c code should register a sleep queue
element to be notified of snooze, and do a reset from it. (For infos
about sleep notifications, look at other drivers like the chipsfb).

The reset is currently done thru a function pointer filled by the
low-level driver (be careful, it could be NULL). You should find it by
looking at adb.c code.

As far as plug/unplug is concerned, this could be done by adding a ioctl
to the ADB driver.

I have already done part of those in experimental hacks here, if you can
wait one or two weeks, I'll clean all this up and make patches. If you
can't then implement them yourself, it's not very complicated. I'm too
busy to finish that stuff now.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Hubert Figuiere]

According to Christian Jaeger <cj@plusline.de>:
> While you are at it:
> Consider a reinit for SCSI,

Look at the SCSI-Programming HOWTO. It explain how to 
force a new SCSI device to be recognized.

> ext. Screen, Network as well since that's
> changing with locations.

For network, everything can be done with shell script

> Maybe even hot-swapping the disk/cdrom/zip-drive in
> expansion bay.loading the appropriate modules on the fly.
> ;)

kerneld will do this. Just fill the modules.conf in.


Hotswapping CD and floppy on my PB 3400 works like a charm
(thanks to the people that made it).


Hub
-- 
World Wide Wait: the real meaning for WWW.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Hubert Figuiere]

According to Benjamin Herrenschmidt <bh40@calva.net>:

> >Can anybody tell me how to reset the ADB bus. Just because when I
> >snooze the PowerBook, the mouse become really slow....
> >
> >How can I ask to redect all the ADB peripherals. I want to be able
> >to plug and unplug my kensington mouse.
> >
> >The goal is to make a small set of utilities for this :-)
> 
> For the reset on snooze, the adb.c code should register a sleep queue
> element to be notified of snooze, and do a reset from it. (For infos
> about sleep notifications, look at other drivers like the chipsfb).
> 
> The reset is currently done thru a function pointer filled by the
> low-level driver (be careful, it could be NULL). You should find it by
> looking at adb.c code.
> 
> As far as plug/unplug is concerned, this could be done by adding a ioctl
> to the ADB driver.

I could reset the adb bus with adb_reset_bus(), but it did
nothing in my case. Mouse was still SLOW, etc.
I called adb_scan_bus() instead. But this happen to not work and
make my mouse no longer be recognized.

Any idea on what to do ?

Hub
-- 
World Wide Wait: the real meaning for WWW.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Benjamin Herrenschmidt]

On Wed, Mar 10, 1999, Hubert Figuiere <hub@point-barre.fr> wrote:

>I could reset the adb bus with adb_reset_bus(), but it did
>nothing in my case. Mouse was still SLOW, etc.
>I called adb_scan_bus() instead. But this happen to not work and
>make my mouse no longer be recognized.
>
>Any idea on what to do ?

After the bus reset, the mouse must be re-initialised to handler 4. In
fact, the whole device probing and init must be redone (mac_keyb.c). I'm
working on a simple design that allow ADB peripherial drivers to register
to the ADB core in order to be notified of bus resets. Stay tuned.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[David A. Gatwood]

On Wed, 10 Mar 1999, Hubert Figuiere wrote:

> I could reset the adb bus with adb_reset_bus(), but it did
> nothing in my case. Mouse was still SLOW, etc.
> I called adb_scan_bus() instead. But this happen to not work and
> make my mouse no longer be recognized.
> 
> Any idea on what to do ?

If I were to venture a guess, I'd probably guess that the ADB power is
getting cut in sleep mode and the mouse is forgetting its acceleration
settings.  Have you tried changing the aceleration settings to see if that
resets it?  If not, the mouse's initialization routine might need to be
redone, if it isn't already....  Dunno.


David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Hubert Figuiere]

According to Benjamin Herrenschmidt <bh40@calva.net>:

> After the bus reset, the mouse must be re-initialised to handler 4. In
> fact, the whole device probing and init must be redone (mac_keyb.c). I'm
> working on a simple design that allow ADB peripherial drivers to register
> to the ADB core in order to be notified of bus resets. Stay tuned.

That would be cool if we can get the "adb_mouse_kinds" array (or
at least the current mouse kind) within the adbmouse.c driver.
This would allow to make the driver works at the right speed with
Kensington mice....
I have made such patch that seems to be on the right way (I could
not validate it completely).

BTW, while I'm at it, it looks like extended ADB protocol provide
"high bits" for dx and dy, but they seems to be unused in
adbmouse.c. Any ideas for this ?


Hub
-- 
World Wide Wait: the real meaning for WWW.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Paul Mackerras]

Benjamin Herrenschmidt <bh40@calva.net> wrote:

> After the bus reset, the mouse must be re-initialised to handler 4. In
> fact, the whole device probing and init must be redone (mac_keyb.c). I'm
> working on a simple design that allow ADB peripherial drivers to register
> to the ADB core in order to be notified of bus resets. Stay tuned.

If we have two devices with the same default ID, they may get assigned
different IDs after re-probing.  Any ideas how to cope with that?

On my 3400, after a snooze, sometimes the adb bus has been reset and
sometimes it hasn't.  I haven't been able to discern any pattern,
e.g. it doesn't seem to depend on how long the machine is asleep for.
I believe that the power to the adb bus is supposed to stay on during
sleep, so I don't see why it's getting reset.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Hubert Figuiere]

According to Benjamin Herrenschmidt <bh40@calva.net>:
> 
> After the bus reset, the mouse must be re-initialised to handler 4. In
> fact, the whole device probing and init must be redone (mac_keyb.c). I'm
> working on a simple design that allow ADB peripherial drivers to register
> to the ADB core in order to be notified of bus resets. Stay tuned.

This is really ugly. Why the hell is mouse related code in the keyboard
driver ? I may understand that since it is ADB they are related, but
I find this not really clean.
I'll look at this...


Hub
-- 
World Wide Wait: the real meaning for WWW.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Benjamin Herrenschmidt]

On Thu, Mar 11, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>If we have two devices with the same default ID, they may get assigned
>different IDs after re-probing.  Any ideas how to cope with that?
>
>On my 3400, after a snooze, sometimes the adb bus has been reset and
>sometimes it hasn't.  I haven't been able to discern any pattern,
>e.g. it doesn't seem to depend on how long the machine is asleep for.
>I believe that the power to the adb bus is supposed to stay on during
>sleep, so I don't see why it's getting reset.

I plan to re-do the entire bus reset, probing and intialisation after the
sleep. Actually, anyone (and so ADB device handlers) will be able to
register a notification proc with the ADB core. Messages will be sent to
devices before and after a bus reset, at initialisation time, and
eventually in other circumstances.
Sleep will cause a reset (but with an additional parameter indicating
that it's coming from a sleep, so that the device knows that the power on
the bus may be turned off. This may be useful for some devices).

Under MacOS, the bus is reset after sleep and devices are notified via a
low-memory hook just before and after the bus reset.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Benjamin Herrenschmidt]

On Thu, Mar 11, 1999, Hubert Figuiere <hub@point-barre.fr> wrote:

>This is really ugly. Why the hell is mouse related code in the keyboard
>driver ? I may understand that since it is ADB they are related, but
>I find this not really clean.
>I'll look at this...

Historical reasons, I beleive. Anyway, I'm working on an overall rework
of the adb code (I finally have a little more time this week and for one
or two more weeks) that will allow ADB controller drivers and device
drivers to be in modules, and everything to be in different locations.

There is one advantage of having the mouse and kbd code mixed the way
they are currently which is to handle the mouse simulation via the kdb
without exporting all sorts of globals.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[Geert Uytterhoeven]

On Thu, 11 Mar 1999, Benjamin Herrenschmidt wrote:
> There is one advantage of having the mouse and kbd code mixed the way
> they are currently which is to handle the mouse simulation via the kdb
> without exporting all sorts of globals.

Even that can be done cleanly in separate modules: you need to export only one
function in the mouse code to feed button events into the system from the
keyboard code.

Or should the mouse simulation be done in the X server, as is currently already
done to emulate the 3rd button on 2-button mice on PeeCee? A disadvantage of
that is that it has to be done in gpm then, too.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ADB Reset

[David A. Gatwood]

On Thu, 11 Mar 1999, Hubert Figuiere wrote:

> According to Benjamin Herrenschmidt <bh40@calva.net>:
> > 
> > After the bus reset, the mouse must be re-initialised to handler 4. In
> > fact, the whole device probing and init must be redone (mac_keyb.c). I'm
> > working on a simple design that allow ADB peripherial drivers to register
> > to the ADB core in order to be notified of bus resets. Stay tuned.
> 
> This is really ugly. Why the hell is mouse related code in the keyboard
> driver ? I may understand that since it is ADB they are related, but
> I find this not really clean.

They're more than related.  With ADB, most mice (anything with more than
one button) act as both a mouse and keyboard.  That was presumably the
only way they could send the extra button information.  Because of this,
the only way to get all of the mouse code out of the keyboard driver would
be to literally have two keyboard drivers, one for real keyboards and one
for the fake mouse-keyboards.  The best you could do would be to have the
keyboard code only contain the code for detecting the fake keyboards and
then switch their handler, but that would basically result in two complete
keyboard drivers with little or no difference between them....

On the other hand, basic device probing and initialization should probably
be in a separate file, since it's not specific to any given device flavor,
maybe adb.c or something, if it isn't already.  Just MHO.  With the added
note that my experience with LinuxPPC's adb drivers is limited to using it
to try to find some bugs in MkLinux's pmu driver.  ;-)


Later,
David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]