ADB probing

ADB probing

[Tom Rini]

Hello all.

I've run into a wierd problem with ADB stuff, and I wonder if anyone has
an idea on how to work/fix this.  What I'm trying to do right now is fix
up kudzu so it can probe for things on the ADB bus.  Right now it does
what all the other old config tools did, and pokes at /dev/adbmouse.  The
problem is right now this works if there's any adb device present (one of
the machines I checked only has an adb kbd, tho adbmouse suport is
compiled in).  Also, is there any way to see if the machine has an adb
keyboard installed?  Thanks..

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> I've run into a wierd problem with ADB stuff, and I wonder if anyone has
> an idea on how to work/fix this.  What I'm trying to do right now is fix
> up kudzu so it can probe for things on the ADB bus.  Right now it does
> what all the other old config tools did, and pokes at /dev/adbmouse.  The
> problem is right now this works if there's any adb device present (one of

That's right - currently /dev/adbmouse can be opened regardless of a mouse
being present. We'd need a way of checking whether a mouse device is present
on the ADB bus (look for a handler ID of 1,2 or 4 in the registered ADB
devices; all information you need is present in the ADB driver). Or use a
global variable set by the ADB driver when it registers a mouse. 

All this will only work if the ADB bus is automatically rescanned when a new
device is detected (if that's possible; does the ADB driver detect new
devices?). 

> the machines I checked only has an adb kbd, tho adbmouse suport is
> compiled in).  Also, is there any way to see if the machine has an adb
> keyboard installed?  Thanks..

Only by poking /dev/adb and sending talk requests and reading the handler
IDs. That might be the easier way of detecting the mouse, too. Sample code
from adb.c:

	adb_request(&req, NULL, ADBREQ_SYNC | ADBREQ_REPLY, 1,
			(i << 4) | 0xf);
	adb_handler[i].handler_id = req.reply[2];


	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Timothy Wall]

I've been working on a tablet driver, and doing things essentially on the same
level and providing /dev/adbtablet for application-level stuff.  Are there any
docs or samples on what I can do through /dev/adb?

The tablet driver has an ADB scan loop if you're interested.

T.

Michael Schmitz wrote:

> > I've run into a wierd problem with ADB stuff, and I wonder if anyone has
> > an idea on how to work/fix this.  What I'm trying to do right now is fix
> > up kudzu so it can probe for things on the ADB bus.  Right now it does
> > what all the other old config tools did, and pokes at /dev/adbmouse.  The
> > problem is right now this works if there's any adb device present (one of
>
> That's right - currently /dev/adbmouse can be opened regardless of a mouse
> being present. We'd need a way of checking whether a mouse device is present
> on the ADB bus (look for a handler ID of 1,2 or 4 in the registered ADB
> devices; all information you need is present in the ADB driver). Or use a
> global variable set by the ADB driver when it registers a mouse.
>
> All this will only work if the ADB bus is automatically rescanned when a new
> device is detected (if that's possible; does the ADB driver detect new
> devices?).
>
> > the machines I checked only has an adb kbd, tho adbmouse suport is
> > compiled in).  Also, is there any way to see if the machine has an adb
> > keyboard installed?  Thanks..
>
> Only by poking /dev/adb and sending talk requests and reading the handler
> IDs. That might be the easier way of detecting the mouse, too. Sample code
> from adb.c:
>
>         adb_request(&req, NULL, ADBREQ_SYNC | ADBREQ_REPLY, 1,
>                         (i << 4) | 0xf);
>         adb_handler[i].handler_id = req.reply[2];
>
>         Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> I've been working on a tablet driver, and doing things essentially on the same
> level and providing /dev/adbtablet for application-level stuff.  Are there any
> docs or samples on what I can do through /dev/adb?

Numerous apps, such as mousehack or mousemode, the trackpad tool etc. And
the ultimate doc is drivers/macintosh/adb.c ... There's probably more; I
just use a Powerbook and happened to write the original adbmouse driver for
m68k. 
 
> The tablet driver has an ADB scan loop if you're interested.

I'd rather not poll the ADB bus if it can be avoided. How does MacOS detect
a new mouse device? But you could always force a bus reset and rescan via 
/dev/adb. 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Benjamin Herrenschmidt]

On Wed, Oct 6, 1999, Tom Rini <trini@kernel.crashing.org> wrote:

>I've run into a wierd problem with ADB stuff, and I wonder if anyone has
>an idea on how to work/fix this.  What I'm trying to do right now is fix
>up kudzu so it can probe for things on the ADB bus.  Right now it does
>what all the other old config tools did, and pokes at /dev/adbmouse.  The
>problem is right now this works if there's any adb device present (one of
>the machines I checked only has an adb kbd, tho adbmouse suport is
>compiled in).  Also, is there any way to see if the machine has an adb
>keyboard installed?  Thanks..

Look at my trackpad tool source code, you'll find an example of probing
the devices. That's not an ideal way since part of the "device type"
information is the original address of the device before relocation, and
you can't ask the device about this. You should be able to handle most
cases with just the handlerID, but I'll look into adding a couple of
ioctls to /dev/adb so you can also get the original address. (I'll do
this next week end, ping me if I forget, I'm doing too many things at the
same time those last few weeks).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Benjamin Herrenschmidt]

On Thu, Oct 7, 1999, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>I'd rather not poll the ADB bus if it can be avoided. How does MacOS detect
>a new mouse device? But you could always force a bus reset and rescan via 
>/dev/adb. 

Be careful that the bus reset will cause an automatic re-probing and
re-init of the bus and devices by the drivers in mac_keyb.c. (This way,
we could make a userland tool that sends the bus reset and have a real
hot-swap ADB, just reset the bus after the hot swap). This feature is
mainly used by the sleep code for now.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> >I'd rather not poll the ADB bus if it can be avoided. How does MacOS detect
> >a new mouse device? But you could always force a bus reset and rescan via 
> >/dev/adb. 
> 
> Be careful that the bus reset will cause an automatic re-probing and
> re-init of the bus and devices by the drivers in mac_keyb.c. (This way,

?? I found the reset (and implicit rescan) in adb.c, is there a hook from
mac_keyb.c? (I meant 'force a reset via /dev/adb, which will in turn cause a
rescan)

> we could make a userland tool that sends the bus reset and have a real
> hot-swap ADB, just reset the bus after the hot swap). This feature is
> mainly used by the sleep code for now.

Yep, that will work as long as all drivers receiving data from ADB get
notified. Might be problematic for user space apps that open /dev/adb and
talk to a specific device directly. In case of ID collosions, we might have
a different device occupy that ID after a reset. As long as handler IDs and
original IDs (better: address) are unique, there should be no problems. 

BTW: opening /dev/adb to read from a specific device is cumbersome, right?
You can send listen and talk requests to the device but there's no way to
get autopoll data to user space. What about using minor 1-16 for that (now
that bus probing is implemented)? 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[David A. Gatwood]

On Thu, 7 Oct 1999, Michael Schmitz wrote:

> ?? I found the reset (and implicit rescan) in adb.c, is there a hook from
> mac_keyb.c? (I meant 'force a reset via /dev/adb, which will in turn cause a
> rescan)

This is a rather poor way of handling bus probing, IMHO.  See below.


> Yep, that will work as long as all drivers receiving data from ADB get
> notified. Might be problematic for user space apps that open /dev/adb and
> talk to a specific device directly. In case of ID collosions, we might have
> a different device occupy that ID after a reset. As long as handler IDs and
> original IDs (better: address) are unique, there should be no problems.

Danger.  Add a second keyboard.  Bang, you're up in smoke.  If you really
want the code to work, you do _not_ want to do a bus reset.  If I'm
remembering my hardware right, a bus reset blanks the status of the ADB
devices, just like you unplugged everything.  Your mouse acceleration is
reset, your keyboard lights go off, etc.  You'll have to notify every
handler, etc. to save the state, and restore it afterwards.  It's really a
massive pain in the backside.

A reset will also cause all the devices to jump back to their default
positions, complete with ID collisions, etc., and if any device has been
added, odds are your remapping code is going to remap things differently 9
times out of 10.  It's very bad for userland code, as you mention.  It's
also adding unnecessary complication to drivers.  It's one thing for say
the mouse handling code to be told that there's a new mouse for it to
handle at ID 4.  It's another thing entirely to tell it that the mice it
handled have all been remapped in different places, now go find them all.
It's a much bigger performance hit for that reason, and also because the
bus reset isn't exactly fast, IIRC.

There are several possibilities here.  My suggestion would be to take
advantage of the 1 second adb tick.  At each one second tick, move each
device to a free device.  If there's nothing under it, move it back, else
move whatever's under it, then move it back.  Happening once per second
should make this relatively painless performance-wise, so long as you
handle the locking of the adb bus correctly.

The advantages to that method are:

1. there's no long delay while the bus resets.
2. It's completely transparent to the user.
3. devices don't move from the perspective of drivers and userland
   programs

The disadvantages (or at least caveats) to that method are:

1. There is a miniscule delay every 1 second.
2. While the devices are at a temporary location, data may arrive.
   This must be modified to show the correct (permanent) ID number.
3. If a device with the same handler ID happened to appear at the
   same location, it would be hard to determine which one was the
   new one and which one was the old one, I think.  In that case,
   though, odds are you can just notify the handler code to deal
   with one more device.  GPM is one exception, which is a good reason
   to make sure mice always move to a different ID than the default.
   Quick & easy solution.  :-)


Later,
David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> > ?? I found the reset (and implicit rescan) in adb.c, is there a hook from
> > mac_keyb.c? (I meant 'force a reset via /dev/adb, which will in turn cause a
> > rescan)
> 
> This is a rather poor way of handling bus probing, IMHO.  See below.

True, it's just the easiest way with the current implementation. You could
move around devices via /dev/adb as well but that won't lead to changing the
kernel's view of the registered ADB devices. Plus the complications you
mention with data coming in while the bus is being tweaked. 

> > Yep, that will work as long as all drivers receiving data from ADB get
> > notified. Might be problematic for user space apps that open /dev/adb and
> > talk to a specific device directly. In case of ID collosions, we might have
> > a different device occupy that ID after a reset. As long as handler IDs and
> > original IDs (better: address) are unique, there should be no problems.
> 
> Danger.  Add a second keyboard.  Bang, you're up in smoke.  If you really

Why? As long as all devices with a keyboard type hander feed into the
keyboard input, everything should be fine. 

> want the code to work, you do _not_ want to do a bus reset.  If I'm
> remembering my hardware right, a bus reset blanks the status of the ADB
> devices, just like you unplugged everything.  Your mouse acceleration is
> reset, your keyboard lights go off, etc.  You'll have to notify every
> handler, etc. to save the state, and restore it afterwards.  It's really a
> massive pain in the backside.

The device state is lost, right. It can be restored from the handler
specific inits without prior save, provided the handler keeps track of the 
device state (the LEDs being a good example of this). Everything that had
been set up from kernel space can be restored that way. For anything you
changed via /dev/adb, you will have to repeat it. 
 
> also adding unnecessary complication to drivers.  It's one thing for say
> the mouse handling code to be told that there's a new mouse for it to
> handle at ID 4.  It's another thing entirely to tell it that the mice it
> handled have all been remapped in different places, now go find them all.
> It's a much bigger performance hit for that reason, and also because the
> bus reset isn't exactly fast, IIRC.

This is a consequence of using the ID as the only hint to decide where a
packet should go. If we used the handler ID, which is set up correctly after
a bus scan, I can't see a problem. But I'll reread the code on this. 
 
> There are several possibilities here.  My suggestion would be to take
> advantage of the 1 second adb tick.  At each one second tick, move each
> device to a free device.  If there's nothing under it, move it back, else
> move whatever's under it, then move it back.  Happening once per second
> should make this relatively painless performance-wise, so long as you
> handle the locking of the adb bus correctly.

How do you lock the bus? Sending out the requests won't take long and you
won't sit in a loop sending and reading each byte if you can use interrupts
:-) And if that scheme is too much hassle, just move one device on each
tick.

I really don't like polling, but there probably isn't anything else to
detect new devices (two keyboards both at the default ID, or two mice, did
play together perfectly before the bus scan was implemented IIRC). 

The only other thing I can imagine is to keep the default IDs unoccupied,
and watch for packets from these IDs. 
 
> 2. While the devices are at a temporary location, data may arrive.
>    This must be modified to show the correct (permanent) ID number.

Use the handler ID to route the packet. 

> 3. If a device with the same handler ID happened to appear at the
>    same location, it would be hard to determine which one was the
>    new one and which one was the old one, I think.  In that case,

Impossible unless the handler ID or other data you stored about that device
are different. If you sent a config request to the device and can read that
config back, fine. 

One more reason to leave the default IDs empty.

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Benjamin Herrenschmidt]

On Thu, Oct 7, 1999, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>?? I found the reset (and implicit rescan) in adb.c, is there a hook from
>mac_keyb.c? (I meant 'force a reset via /dev/adb, which will in turn cause a
>rescan)

There is a notifier that the devices can attach to the adb core. I added
this when working on the sleep code.

>Yep, that will work as long as all drivers receiving data from ADB get
>notified. Might be problematic for user space apps that open /dev/adb and
>talk to a specific device directly. In case of ID collosions, we might have
>a different device occupy that ID after a reset. As long as handler IDs and
>original IDs (better: address) are unique, there should be no problems. 
>
>BTW: opening /dev/adb to read from a specific device is cumbersome, right?
>You can send listen and talk requests to the device but there's no way to
>get autopoll data to user space. What about using minor 1-16 for that (now
>that bus probing is implemented)? 

That's something I've been thinking about for a long time, I also want
this to send ADB codes directly to mac-on-linux. Basically, it would end
up this way (please comment) :

 - minor 0 is the "control" channel where you can send bus resets, raw
commands, etc... I'll add this new ioctl for querying things like the
original address. It will be backward compatible.

 - each minor >0 correspond to an address. Open is exclusive. When
opened, the original handler (if any) is replaced by a special one that
sends autopoll datas to a ring buffer that can be read(). Optionally, we
can provide a few ioctls to set this buffer's size and to flush it. In
case a bus reset happens, all those opened minor are marked "dead" and
return an error to any read or ioctl call. (The user is then expected to
close the file, use minor 0 to re-probe the device, and reopen an
"autopoll" minor if the device is still there).

I beleive this is enough for anything we might want to do with ADB, and
things like tablet drivers could be 100% userland.



-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> >?? I found the reset (and implicit rescan) in adb.c, is there a hook from
> >mac_keyb.c? (I meant 'force a reset via /dev/adb, which will in turn cause a
> >rescan)
> 
> There is a notifier that the devices can attach to the adb core. I added
> this when working on the sleep code.

Thanks, I forgot that sleeping will power down all ADB devices. That still
doesn't force a bus reset but a bus reset may not be what we want anyway. 

Can we add a SysRQ code for this? Speaking of which, what is the magic sysrq 
key on a Lombard, or the shutdown key combo? I couldn't find that in the
keyboard driver ...

>  - minor 0 is the "control" channel where you can send bus resets, raw
> commands, etc... I'll add this new ioctl for querying things like the
> original address. It will be backward compatible.
> 
>  - each minor >0 correspond to an address. Open is exclusive. When
> opened, the original handler (if any) is replaced by a special one that
> sends autopoll datas to a ring buffer that can be read(). Optionally, we
> can provide a few ioctls to set this buffer's size and to flush it. In
> case a bus reset happens, all those opened minor are marked "dead" and
> return an error to any read or ioctl call. (The user is then expected to
> close the file, use minor 0 to re-probe the device, and reopen an
> "autopoll" minor if the device is still there).
> 
> I beleive this is enough for anything we might want to do with ADB, and
> things like tablet drivers could be 100% userland.

That's about what I've been discussing with some (including Paul and hpa)
about two years ago. We could add adbkeyb (raw keyboard data) and adbmouse
(the busmouse device) and possibly adbtablet for good measure and give up 
that hijacked misc minor 10, finally. 

I can help writing and testing this on a Powerbook, I just don't have a
desktop Mac to connect multiple ADB devices to. 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Benjamin Herrenschmidt]

On Fri, Oct 8, 1999, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>Thanks, I forgot that sleeping will power down all ADB devices. That still
>doesn't force a bus reset but a bus reset may not be what we want anyway. 

Yes, sleep powers down all ADB devices, and that's why the ADB code
contains a sleep notifier which will do a bus reset on wakeup. The adb
code will then re-do the probing and re-adressing and notify it's own
clients (mac_keyb.c drivers) via it's own notifier that the bus was reset
so they get a chance to re-initialize their various devices.
The /dev/adb code will also catch bus reset commands and do the same
thing. I still think that we should try to do something more complex than
a reset+reprobe.

>Can we add a SysRQ code for this? Speaking of which, what is the magic sysrq 
>key on a Lombard, or the shutdown key combo? I couldn't find that in the
>keyboard driver ...

>That's about what I've been discussing with some (including Paul and hpa)
>about two years ago. We could add adbkeyb (raw keyboard data) and adbmouse
>(the busmouse device) and possibly adbtablet for good measure and give up 
>that hijacked misc minor 10, finally. 
>
>I can help writing and testing this on a Powerbook, I just don't have a
>desktop Mac to connect multiple ADB devices to. 

My idea was to work on this this Sunday, but if you want to write it now,
feel free to do so ;) I can test it on various configurations at work.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Brad Midgley]

> I really don't like polling, but there probably isn't anything else to
> 
> The only other thing I can imagine is to keep the default IDs unoccupied,
> and watch for packets from these IDs. 

I like this approach because it effectively disables the hard reset that a
keyboard on the default id can perform and would be able to move keyboards
off the default as soon as it noticed them.

How does all this discussion fit in with the work being done on the input
system which will allow multiple independent keyboards, etc.?

Brad
brad@pht.com | http://www.pht.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> >I can help writing and testing this on a Powerbook, I just don't have a
> >desktop Mac to connect multiple ADB devices to. 
> 
> My idea was to work on this this Sunday, but if you want to write it now,
> feel free to do so ;) I can test it on various configurations at work.

It took a bit longer, but I actually got something to start with. I've only
implemented exclusive access to devices and a simple autopoll data buffering 
so far. I still need to conditionalize the gobs of debug messages but it's
now possible to take over a specific device from user space and get the
autopoll data from it (tested with a hacked version of the trackpad tool that
would take over the trackpad for 10 seconds). 
I haven't implemented poll yet, and there's a few implementation details that 
need discussion. Did you do any work on this yet? I'd send a diff (relative
to 2.2.12) otherwise for you to test. 

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ADB probing

[Michael Schmitz]

> How does all this discussion fit in with the work being done on the input
> system which will allow multiple independent keyboards, etc.?

Huh? What work is being done there? Kernel level or user space? 

To use multiple independent keyboards at kernel level: register different 
handler functions for each. But what would you do with multiple keyboards at
kernel level? Attach one to each virtual console? 
The Linux keyboard driver is currently written for one single keyboard
(last time I checked), and it's going to be hard to change that. 

At user space level: just open the proper ADB minor device and read out the
keycodes. I've only done it with the mouse/trackpad but keyboard should work
the same. I'll send my patch to benh to merge with his work on the driver
first though.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/