[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new input layer



> > Has any of you read this page about the PPC Input layer ?!
> > http://home.munich.netsurf.de/Franz.Sirl/inputppc.html
> 
> Yes, went through the whole thing and still didn't understand this.  For example,
> it says, "For backwards compatibility, the deprecated adb_buttons= kernel argument
> still uses ADB keycodes" but this is clearly failing for everyone.

That's indeed right if you happen to have mouse emulation via the old
/dev/adbmouse device active. Trouble is, with the default 2.2 kernels you
can still set CONFIG_ADBMOUSE but together with CONFIG_INPUT it's
essentially not effective (see drivers/char/adbmouse.c). The patch is easy
(just remove the defined(CONFIG_INPUT) stuff and it should work).

What you see is mouse button emulation via the new input code which
requires Linux keycodes, and is activcated via the /proc filesystem. 
 
> I had thought there were now two mappings: ADB (for compatibility, e.g. in
> .Xmodmap) and "Linux", which is why we use "IMPS/2" as the X mouse mapping...

There could well be two mappings if someone had allowed the two mouse
device drivers to peacefully coexist (which they do just fine in 2.2.17 at
least). The old driver was considered deprecated so badly it apparently
wasn't a concern to change it in 2.2 ('users read linuxppc-dev anyway' :-)
In 2.4 you can't configure old adbmouse support together with the new
driver anymore. 

> So now to deal with an ADB (or other non-PS/2) input system, we need to work with
> three sets of standards: ADB, PS/2, and "Linux"- the last of which is part PS/2 and
> part something completely different?  And such standby tools as showkey are
> broken?  And this in a kernel-image in r2?  Sure, that will be perfectly clear to
> everyone the first time.

It's two sets of keycode translations: raw ADB codes and Linux keycodes.
The mouse protocol (PS/2 or IMPS/2 versus busmouse) is a different issue.
Keycodes and mouse protocols are unrelated except for the problem that
both use different keycode translations. We could just as easily switch
the old adbmouse driver to use Linux keycodes.

Showkey should report the correct keycodes, it depends on your setting of
use_linux_keycodes in /proc/sys/mac_hid or wherever that was. If your
keyboard is set to ADB keycodes, look up the corresponding Linux keycodes
in include/linux/input.h

> With breakage this bad mid-release in stable, and documentation this poor, I expect
> the confused posts will continue for another month or two.  Learn to deal with it,
> or just use the "delete" button.

I agree that breaking this in stable wasn't a good idea. Others gave
priority to phasing out the old mouse driver sooner rather than later
(which is a Good Thing, all things considered).
The documentation might have gotten out of sync with reality in a few
points. I'm sure updates to the install docs are welcome (if that topic
was indeed ever covered in the docs). 

Chalk one up to extensive testing of point releases. 

	Michael



Reply to: