userspace button controls

attached is a tar.gz of a few files I've created as a solution to powerbook buttons.

- buttons.patch: brings all 5 adb-buttons to userspace via NIL's events via the keyboard.  New keys added to input.h.  With proper support, the user could see these keypresses, and use them.  This also does not use the pmac_backlight.c file, in exchange for a new framebuffer ioctl, existant in chipsfb, atyfb, and aty128fb.  The only interdependancy is between chipsfb/atyfb and via-pmu for backlight control for lombard and earlier.  The pmu's backlight ioctl was removed.  So sound controls are in the mixer (unchanged), backlight controls are in the fb rather than pmu, and the adbbuttons are simple keys, accessed via /dev/input/event? and, with some help, common console/X keycodes.  syslog logs an error with there is no keycode.  I changed that to a DEBUG message rather than a WARNING message.

- adbhid_sleep.patch: checks before an adbhid is deregistered post sleep.  The existing code causes an open event device to dangle open (safely i think), but the program doesn't notice it.  This checks to see if the device has changed, or no longer exists before it deregisters it.  This works for me, but might be unsafe.  I couldn't find a cleaner solution that still allows for reprobing.

- input_sec.patch: Fix permissions for input devices created via devfs, which are default readable by anyone, including the keyboard's event dev. (submitted to maintainer)

- misc.patch: one fix (missing non-fatal include in checks.c), and a slightly cleaner non-TAU temp coding.  (irrelevant to button operations)

- keyevd.c: a quick daemon that listens to the buttons and acts on them.  Simple compile builds a forking daemon that uses the mute button to switch between muting speaker and line out.  Key repeat is too quick tho.  Mostly a quick hack, not too clean.  This needs input event support.

I've only tested this on my powerbook, which is a aty->pmu based backlight system.  I used BenH's prexisting backlight interfaces.  A better ioctl might be nessesary (still 0x0-0xf range), but pmu, aty, and aty128 now could change to fit a standard ioctl rather than a function API.
When I find the time, I should redo the keyevd so it isn't as messy.

Thanks for your time and consideration.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

At 08:55 24.07.2001, Joseph P. Garcia wrote:

attached is a tar.gz of a few files I've created as a solution to
powerbook buttons.

- buttons.patch: brings all 5 adb-buttons to userspace via NIL's events
via the keyboard.  New keys added to input.h.  With proper support, the
user could see these keypresses, and use them.  This also does not use the
pmac_backlight.c file, in exchange for a new framebuffer ioctl, existant
in chipsfb, atyfb, and aty128fb.  The only interdependancy is between
chipsfb/atyfb and via-pmu for backlight control for lombard and
earlier.  The pmu's backlight ioctl was removed.  So sound controls are in
the mixer (unchanged), backlight controls are in the fb rather than pmu,
and the adbbuttons are simple keys, accessed via /dev/input/event? and,
with some help, common console/X keycodes.  syslog logs an error with
there is no keycode.  I changed that to a DEBUG message rather than a
WARNING message.

- adbhid_sleep.patch: checks before an adbhid is deregistered post
sleep.  The existing code causes an open event device to dangle open
(safely i think), but the program doesn't notice it.  This checks to see
if the device has changed, or no longer exists before it deregisters
it.  This works for me, but might be unsafe.  I couldn't find a cleaner
solution that still allows for reprobing.

- input_sec.patch: Fix permissions for input devices created via devfs,
which are default readable by anyone, including the keyboard's event dev.
(submitted to maintainer)

- misc.patch: one fix (missing non-fatal include in checks.c), and a
slightly cleaner non-TAU temp coding.  (irrelevant to button operations)

- keyevd.c: a quick daemon that listens to the buttons and acts on
them.  Simple compile builds a forking daemon that uses the mute button to
switch between muting speaker and line out.  Key repeat is too quick
tho.  Mostly a quick hack, not too clean.  This needs input event support.

I've only tested this on my powerbook, which is a aty->pmu based backlight
system.  I used BenH's prexisting backlight interfaces.  A better ioctl
might be nessesary (still 0x0-0xf range), but pmu, aty, and aty128 now
could change to fit a standard ioctl rather than a function API.
When I find the time, I should redo the keyevd so it isn't as messy.

Thanks for your time and consideration.

Wow, this looks great! Would you mind sending the input.h part of the patch
to linuxconsole-dev@lists.sourceforge.net as well? Probably you will get a
little bit different official numbers then, but thats no problem. After the
numbers are approved there, they will end up with the next merge in the
official kernel quite soon. Then we can merge your stuff into linuxppc_2_4*
and I'll do the merge into the input/console CVS for 2.5. Hmm, maybe I
should add your keyevd source to the input/console CVS as well.
I'll try to take a more detailed look during the next days, but overall I'm
very happy with this stuff :-).

Franz.


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

On Tue, 24 Jul 2001, Joseph P. Garcia wrote:

attached is a tar.gz of a few files I've created as a solution to powerbook buttons.

- buttons.patch: brings all 5 adb-buttons to userspace via NIL's
events via the keyboard.  New keys added to input.h.  With proper
support, the user could see these keypresses, and use them.  This also
does not use the pmac_backlight.c file, in exchange for a new
framebuffer ioctl, existant in chipsfb, atyfb, and aty128fb.  The only
interdependancy is between chipsfb/atyfb and via-pmu for backlight
control for lombard and earlier.  The pmu's backlight ioctl was
removed.  So sound controls are in the mixer (unchanged), backlight
controls are in the fb rather than pmu, and the adbbuttons are simple

You're talking about PMU_IOC_SET/GET_BACKLIGHT? Thanks for breaking pmud
:-) Please make that a config option, or get Stephan Leemburg to change
pmud before this leaks into kernels built for the unsuspecting user.

Please don't get me wrong: I'm all for changing this long term, I'd just
rather not see a repeat of the inputdev compatibility fiasco ...

	Michael


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

On Tue, 24 Jul 2001 17:36:55 +0200 (CEST)
Michael Schmitz [off-list ref] wrote:

You're talking about PMU_IOC_SET/GET_BACKLIGHT? Thanks for breaking pmud
:-) Please make that a config option, or get Stephan Leemburg to change
pmud before this leaks into kernels built for the unsuspecting user.

Oh yeah.  That's right. ^_^;  When I get the time, I'll see what I can do.  The patches are for testing purposes.  As Franz pointed out, there are a few things that need to be done before anything can be fully merged.  I presume that since the fbdev ioctl can be used by others, whomever is in charge of that might prefer a slightly different name or parameter.  (still need to contact them)  So it will probably be a bit.. maybe.  I'd rather that the api propagates finality in the kernel before it even hits general user userspace.  that involves finalizing the new keys and the fb.h's ioctl afaik.

In the meantime, kernel space coexistance of the two would be nasty.  I coded this thinking i need cleaner code over maintaining the older code links in the kernel.

fblevel command also uses pmu.

For testing, a 'if(ioctl(pmu,...)<0) ioctl(fb,...);' should work for compatibility, taking with the -EINVAL ioctl failure my patch would generate.  Probably put the fb's ioctl in an #ifdef (IOCTL NAME) so it still compiles elsewhere.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Hi,

Joseph P. Garcia wrote:

attached is a tar.gz of a few files I've created as a solution to powerbook buttons.

- buttons.patch: brings all 5 adb-buttons to userspace via NIL's events via the keyboard.  New keys added to input.h.  With proper support, the user could see these keypresses, and use them.  This also does not use the pmac_backlight.c file, in exchange for a new framebuffer ioctl, existant in chipsfb, atyfb, and aty128fb.  The only interdependancy is between chipsfb/atyfb and via-pmu for backlight control for lombard and earlier.  The pmu's backlight ioctl was removed.  So sound controls are in the mixer (unchanged), backlight controls are in the fb rather than pmu, and the adbbuttons are simple keys, accessed via /dev/input/event? and, with some help, common console/X keycodes.  syslog logs an error with there is no keycode.  I changed that to a DEBUG message rather than a WARNING message.

- adbhid_sleep.patch: checks before an adbhid is deregistered post sleep.  The existing code causes an open event device to dangle open (safely i think), but the program doesn't notice it.  This checks to see if the device has changed, or no longer exists before it deregisters it.  This works for me, but might be unsafe.  I couldn't find a cleaner solution that still allows for reprobing.

- input_sec.patch: Fix permissions for input devices created via devfs, which are default readable by anyone, including the keyboard's event dev. (submitted to maintainer)

- misc.patch: one fix (missing non-fatal include in checks.c), and a slightly cleaner non-TAU temp coding.  (irrelevant to button operations)

- keyevd.c: a quick daemon that listens to the buttons and acts on them.  Simple compile builds a forking daemon that uses the mute button to switch between muting speaker and line out.  Key repeat is too quick tho.  Mostly a quick hack, not too clean.  This needs input event support.

Done a new version of it:

- uses glib
- uses popt
- room for alsa compat
- broke it
- not tested
- really not tested, developed on a x86
- I should be working now

Cheers

--
/Bastien Nocera
http://hadess.net

Michael Schmitz [off-list ref] wrote:

quoted

You're talking about PMU_IOC_SET/GET_BACKLIGHT? Thanks for breaking pmud
:-) Please make that a config option, or get Stephan Leemburg to change
pmud before this leaks into kernels built for the unsuspecting user.

Oh yeah.  That's right. ^_^;  When I get the time, I'll see what I can
do.  The patches are for testing purposes.  As Franz pointed out,
there are a few things that need to be done before anything can be

With the 2.4 development kernels being used by many (for good reason), I'm
sure we'll see bug reports on this within weeks of including this feature
in, say, BenH's kernel tree.

In the meantime, kernel space coexistance of the two would be nasty.
I coded this thinking i need cleaner code over maintaining the older
code links in the kernel.

:-) While this is a Good Thing, introducing it somewhere along 2.4 will
cause trouble. But I see I won't convince anyone here. I'll forward bug
reports related to such breakage here.

For testing, a 'if(ioctl(pmu,...)<0) ioctl(fb,...);' should work for
compatibility, taking with the -EINVAL ioctl failure my patch would
generate.  Probably put the fb's ioctl in an #ifdef (IOCTL NAME) so it
still compiles elsewhere.

I don't doubt it can be taken care of in future pmud releases. That just
won't help J. Random User who just wants to try that cool new kernel with
userspace gizmo button support. Users Don't Read Documentation.

	Michael


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

On Tue, 24 Jul 2001 19:40:13 +0200 (CEST)
Michael Schmitz [off-list ref] wrote:

:-) While this is a Good Thing, introducing it somewhere along 2.4 will
cause trouble. But I see I won't convince anyone here. I'll forward bug
reports related to such breakage here.

Understandable.  But I'd rather not munge up devel with that sort of thing.  I'm on the user list anyway.  Just need to make sure some binary rpms exist to accomodate.

I don't doubt it can be taken care of in future pmud releases. That just
won't help J. Random User who just wants to try that cool new kernel with
userspace gizmo button support. Users Don't Read Documentation.

We can't save users from themselves.  One of the reasons to support gun control.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Hi Joseph,

Well, the buttons_patch doesn't work on the ibook2:
brightness down: "keyboard: unknown scancode e0 3a"
for the following, same message, different scancode:
brightness up:  e0 39
mute: e0 26
volume down: e0 25
volume up: e0 1e
power: e0 5e

and for the eject button:
eject: Unhandled button code 0b

I hope you can help me make the modifications to make it work on this
ibook, I'll be on IRC tomorrow.

Cheers

Joseph P. Garcia wrote:

attached is a tar.gz of a few files I've created as a solution to powerbook buttons.

- buttons.patch: brings all 5 adb-buttons to userspace via NIL's events via the keyboard.  New keys added to input.h.  With proper support, the user could see these keypresses, and use them.  This also does not use the pmac_backlight.c file, in exchange for a new framebuffer ioctl, existant in chipsfb, atyfb, and aty128fb.  The only interdependancy is between chipsfb/atyfb and via-pmu for backlight control for lombard and earlier.  The pmu's backlight ioctl was removed.  So sound controls are in the mixer (unchanged), backlight controls are in the fb rather than pmu, and the adbbuttons are simple keys, accessed via /dev/input/event? and, with some help, common console/X keycodes.  syslog logs an error with there is no keycode.  I changed that to a DEBUG message rather than a WARNING message.

- adbhid_sleep.patch: checks before an adbhid is deregistered post sleep.  The existing code causes an open event device to dangle open (safely i think), but the program doesn't notice it.  This checks to see if the device has changed, or no longer exists before it deregisters it.  This works for me, but might be unsafe.  I couldn't find a cleaner solution that still allows for reprobing.

- input_sec.patch: Fix permissions for input devices created via devfs, which are default readable by anyone, including the keyboard's event dev. (submitted to maintainer)

- misc.patch: one fix (missing non-fatal include in checks.c), and a slightly cleaner non-TAU temp coding.  (irrelevant to button operations)

- keyevd.c: a quick daemon that listens to the buttons and acts on them.  Simple compile builds a forking daemon that uses the mute button to switch between muting speaker and line out.  Key repeat is too quick tho.  Mostly a quick hack, not too clean.  This needs input event support.

I've only tested this on my powerbook, which is a aty->pmu based backlight system.  I used BenH's prexisting backlight interfaces.  A better ioctl might be nessesary (still 0x0-0xf range), but pmu, aty, and aty128 now could change to fit a standard ioctl rather than a function API.
When I find the time, I should redo the keyevd so it isn't as messy.

Thanks for your time and consideration.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Greetings.

On Sun, 29 Jul 2001 04:48:14 +0100
Bastien Nocera [off-list ref] wrote:

Well, the buttons_patch doesn't work on the ibook2:

[...]

eject: Unhandled button code 0b

Perfect!  This is what I was looking for.  Attached is a patch to make things work... maybe.  I don't know what to expect with the power key.  The eject key on the iBook2 is apparantly still an adb-button... neato.. i think.

You will probably get an 'unknown scancode' for the eject key, but you can get the idea how to fix that from the patch.  change the cooresponding 0 to a KEY_EJECTCD, recompile, and it should work.  I don't know what exactly to expect from it.

BTW, I contacted James Simmons, a developer in linuxconsole and framebuffer.  He mentioned that this sort of thing (fb-backlight, new input keys) are planned for 2.5.x.  Which makes sense, as volume/eject keys are no big diff at the moment, but, as Michael Schmitz pointed out, the backlight-related changes should not be introduced under the table.

So volume keys and eject key (power too?) should be merge-able after completion and some testing.

Thanks for your help.

--
Joseph P. Garcia
http://www.lycestra.com/ (that's lie-kes-tra)

Hi,

Joseph P. Garcia wrote:

Greetings.

On Sun, 29 Jul 2001 04:48:14 +0100
Bastien Nocera [off-list ref] wrote:

quoted

Well, the buttons_patch doesn't work on the ibook2:

[...]

quoted

eject: Unhandled button code 0b

Perfect!  This is what I was looking for.  Attached is a patch to make things work... maybe.  I don't know what to expect with the power key.  The eject key on the iBook2 is apparantly still an adb-button... neato.. i think.

You will probably get an 'unknown scancode' for the eject key, but you can get the idea how to fix that from the patch.  change the cooresponding 0 to a KEY_EJECTCD, recompile, and it should work.  I don't know what exactly to expect from it.

BTW, I contacted James Simmons, a developer in linuxconsole and framebuffer.  He mentioned that this sort of thing (fb-backlight, new input keys) are planned for 2.5.x.  Which makes sense, as volume/eject keys are no big diff at the moment, but, as Michael Schmitz pointed out, the backlight-related changes should not be introduced under the table.

So volume keys and eject key (power too?) should be merge-able after completion and some testing.

Apparently the power key is already merged, as it shows up just fine in
evtest, the only problem (to make it handled by keyevd) is that it is on
another input device (ADB Keyboard instead of ADB Buttons). Moving it to
the ADB buttons would make it handlable.

With your patch (and the eject button added in the mac_hid.c table), the
eject button doesn't show up either in evtest or in keyevd. And the
brightness controls are of no effect, although the events are caught
correctly...

Cheers


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

Woop,

So after a session of IRC, and some nasty clock problems, Joseph and I
(especially Joseph in fact ;) managed to get this working alright on an
iBook2. I attach a newer working version of keyevd that Joseph fixed
after my previous post, and to which I added eject (uses the eject
utility somewhere in your PATH).

buttons2.patch installs on top of Jospeh's buttons.patch
keyevd2.c: compiles with:
gcc -I/usr/src/linux/include/ -o keyevd2 `glib-config --cflags`
`glib-config --libs` -lpopt keyevd2.c

keyevd2.c is still a abominable hack, it needs some major cleaning up

Have fun

Joseph P. Garcia wrote:

Greetings.

On Sun, 29 Jul 2001 04:48:14 +0100
Bastien Nocera [off-list ref] wrote:

quoted

Well, the buttons_patch doesn't work on the ibook2:

[...]

quoted

eject: Unhandled button code 0b

Perfect!  This is what I was looking for.  Attached is a patch to make things work... maybe.  I don't know what to expect with the power key.  The eject key on the iBook2 is apparantly still an adb-button... neato.. i think.

You will probably get an 'unknown scancode' for the eject key, but you can get the idea how to fix that from the patch.  change the cooresponding 0 to a KEY_EJECTCD, recompile, and it should work.  I don't know what exactly to expect from it.

BTW, I contacted James Simmons, a developer in linuxconsole and framebuffer.  He mentioned that this sort of thing (fb-backlight, new input keys) are planned for 2.5.x.  Which makes sense, as volume/eject keys are no big diff at the moment, but, as Michael Schmitz pointed out, the backlight-related changes should not be introduced under the table.

So volume keys and eject key (power too?) should be merge-able after completion and some testing.

Thanks for your help.

eject.patch

Content-Type:

application/octet-stream
Content-Encoding:

base64