userspace button controls

userspace button controls

[Joseph P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

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

[-- Attachment #2: jpgpatches.tar.gz --]
[-- Type: application/octet-stream, Size: 10037 bytes --]

Re: userspace button controls

[Franz Sirl]

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/

Re: userspace button controls

[Michael Schmitz]

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/

Re: userspace button controls

[Joseph P. Garcia]

On Tue, 24 Jul 2001 17:36:55 +0200 (CEST)
Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> 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/

Re: userspace button controls

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

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

[-- Attachment #2: keyevd2.c --]
[-- Type: text/plain, Size: 5342 bytes --]

#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <glib.h>
#include <popt.h>
#include <linux/version.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <syslog.h>
#include <linux/input.h>
#include <linux/soundcard.h>
#include <linux/fb.h>
#include <linux/types.h>

gchar *mixername = NULL;
gchar *fbname = NULL;
gboolean use_alsa = FALSE;

enum actions {
	VOLUME_UP,
	VOLUME_DOWN,
	VOLUME_MUTE,
	BACKLIGHT_UP,
	BACKLIGHT_DOWN
};

struct poptOption options[] = {
	{
		"alsa",
		'a',
		POPT_ARG_NONE,
		&use_alsa,
		0,
		"Use ALSA mixer instead of OSS mixer",
		NULL
	},
	{
		"mixer",
		'm',
		POPT_ARG_STRING,
		&mixername,
		0,
		"Use a device other than /dev/mixer for the volume control",
		"MIXER"
	},
	{
		"fb",
		'f',
		POPT_ARG_STRING,
		&fbname,
		0,
		"Use a device other than /dev/fb0 for the backlight control",
		"FB"
	},
	{ NULL, 0, 0, NULL, 0 }
};

static void quit(gint i, gchar *msg)
{
  g_print("%s\n",msg);
  exit(i);
}

static void do_signal(gint signum)
{
	gchar *msg;

	/* There's a leak here, but we don't care since we're
	 * quitting the app */
	g_strdup_printf("Caught signal %d", signum);
	quit(signum == SIGTERM ? 0 : -1, msg);
}

static int open_action_dev(gchar *device)
{
	int fd;

	fd = open(device, O_RDONLY);
	return fd;
}

static void volume_actions_oss(int action)
{
	int actionfd;
	int vol;
#define CHANNELS 2
	int channel[CHANNELS]={SOUND_MIXER_VOLUME,SOUND_MIXER_SPEAKER};
	int channelidx=0;
#define CHANNEL channel[channelidx]
	int mute=0;
	int parm;

	actionfd = open_action_dev(mixername);
	switch (action)
	{
#ifdef SINGLE_CHANNEL
	case VOLUME_UP:
		ioctl(actionfd,MIXER_READ(CHANNEL),&vol);
		mute=1;
		vol=(vol&0xff)+8;
		if(vol>100)
			vol=100;
		vol|=vol<<8;
		parm=vol;
		break;
	case VOLUME_DOWN:
		ioctl(actionfd,MIXER_READ(CHANNEL),&parm);
		if(parm||mute){
			mute=0;
			if(parm)
				vol=parm;
			vol=(vol&0xff)-8;
			if(vol<0)
				vol=0;
			vol|=vol<<8;
		} else {
			mute=1;
		}
		parm=vol;
		break;
		case VOLUME_MUTE:
			if(!mute){
				parm=0;
				mute=1;
			} else {
				parm=vol;
				mute=0;
			}
			break;
#else
		case VOLUME_UP:
			vol=(vol&0xff)+8;
			if(vol>100)
				vol=100;
			vol|=vol<<8;
			break;
		case VOLUME_DOWN:
			vol=(vol&0xff)-8;
			if(vol<0)
				vol=0;
			vol|=vol<<8;
			break;
		case VOLUME_MUTE:
			parm=0;
			ioctl(actionfd,MIXER_WRITE(CHANNEL),&parm);
			parm=0;
			ioctl(actionfd,MIXER_WRITE(CHANNEL),&parm);
			channelidx = (channelidx+1)%CHANNELS;
#endif
	}
	ioctl(actionfd,MIXER_WRITE(CHANNEL),&parm);
	close(actionfd);
}

static void backlight_actions(int action)
{
	int actionfd;
	__u32 bklight;

	actionfd = open_action_dev(fbname);
	ioctl(actionfd,FBIOGET_BACKLIGHT,&bklight);
	switch(action)
	{
	case BACKLIGHT_UP:
		bklight++;
		if(bklight>FBBACKLIGHT_MAX)
			bklight=FBBACKLIGHT_MAX;
		break;
	case BACKLIGHT_DOWN:
		if(bklight>FBBACKLIGHT_OFF)
			bklight--;
		break;
	}
	ioctl(actionfd,FBIOSET_BACKLIGHT,&bklight);
	close(actionfd);
}

int main(int argc, const char **argv)
{
  poptContext pctx;
  const char **args;
  int eventfd; //,actionfd;
  struct input_event inp;
  struct sigaction sigpipe = { {SIG_IGN}, {{0}}, SA_RESTART, 0 };
  struct sigaction sigterm = {{do_signal}, {{0}}, SA_RESTART , 0 };
  short ids[4];
  char *filename; //[50];
//  int vol;
#define CHANNELS 2
  int channel[CHANNELS]={SOUND_MIXER_VOLUME,SOUND_MIXER_SPEAKER};
  int channelidx=0;
#define CHANNEL channel[channelidx]
//  int mute=0;
  int parm;
//  __u32 bklight;

  int i;

  pctx = poptGetContext(NULL, argc, argv, options, 0);
  args = poptGetArgs(pctx);
  if (mixername == NULL)
  {
	  if (use_alsa == FALSE)
		  mixername = g_strdup("/dev/mixer");
	  else
		  g_print("somebody please fix this ;)\n");
  }
  if (fbname == NULL)
	  fbname = g_strdup("/dev/fb0");

  if(sigaction(SIGTERM, &sigterm, 0))
	quit(-1, "could not install SIGTERM handler");

  if(sigaction(SIGPIPE, &sigpipe, 0))
	quit(-1, "could not install SIGPIPE handler");

  for(i=0;i<32;i++){
	filename = g_strdup_printf("/dev/input/event%i",i);
	eventfd = open(filename, O_RDONLY);
	if(eventfd>=0){
	  ioctl(eventfd, EVIOCGID, ids);
	  if((ids[2]&0xfff)==0x71f){
		syslog(LOG_INFO, "Powerbook Button device found at event%i.\n",i);
		break;
	  }
#ifdef DEBUG
	  fprintf(stderr,"[%x] ids - %x %x %x %x\n",i,ids[0],ids[1],ids[2],ids[3]);
#endif
	  close(eventfd);
	  eventfd=-1;
	}
#ifdef DEBUG
	else{
	  fprintf(stderr,"[%x] nil\n",i);
	}
#endif
  }
  if(eventfd<0){
	syslog(LOG_INFO, "Powerbook Button device not found.\n");
	exit(-1);
  }
#if 1
  {
	int pid = fork();

	if(pid < 0){
	  printf("Couldn't fork\n");
	  exit(-1);
	}
	if (pid > 0)
	  quit(0, "parent exiting [note PID]");

	chdir("/");
	setsid();
	close(0);
	close(1);
	close(2);
  }
#endif
  while(read(eventfd,&inp,sizeof(inp))){
	if(inp.value)
	  switch(inp.code){
	  case KEY_MUTE:
		if(inp.value==2)
		  continue;
		if (!use_alsa)
			volume_actions_oss(VOLUME_MUTE);
		else
			g_print("fixme\n");
		break;
	  case KEY_VOLUMEDOWN:
		if (!use_alsa)
			volume_actions_oss(VOLUME_DOWN);
		else
			g_print("fixme\n");
		break;
	  case KEY_VOLUMEUP:
		if (!use_alsa)
			volume_actions_oss(VOLUME_UP);
		else
			g_print("fixme\n");
		break;
	  case KEY_BRIGHTNESSDOWN:
		backlight_actions(BACKLIGHT_UP);
		break;
	  case KEY_BRIGHTNESSUP:
		backlight_actions(BACKLIGHT_DOWN);
		break;
	  }
  }
  close(eventfd);
}

Re: userspace button controls

[Michael Schmitz]

> Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> 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

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/

Re: userspace button controls

[Joseph P. Garcia]

On Tue, 24 Jul 2001 19:40:13 +0200 (CEST)
Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de> 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/

Re: userspace button controls

[Bastien Nocera]

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/

Re: userspace button controls

[Joseph P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Greetings.

On Sun, 29 Jul 2001 04:48:14 +0100
Bastien Nocera <hadess@hadess.net> 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)

[-- Attachment #2: eject.patch --]
[-- Type: application/octet-stream, Size: 2258 bytes --]

diff -ruP -X ../ignorediff linux-2.4.7-pre7-benh20010722-volume/drivers/macintosh/adbhid.c linux-2.4.7-pre7-benh20010722-volume2/drivers/macintosh/adbhid.c
--- linux-2.4.7-pre7-benh20010722-volume/drivers/macintosh/adbhid.c	Mon Jul 23 17:28:35 2001
+++ linux-2.4.7-pre7-benh20010722-volume2/drivers/macintosh/adbhid.c	Sun Jul 29 00:32:25 2001
@@ -288,6 +288,9 @@
 	case 0x9:	/* brightness increase */
 	  input_report_key(&adbhid[id]->input, KEY_BRIGHTNESSUP, data[1] == (data[1] & 0xf));
 	  break;
+	case 0xb:	/* eject key */
+	  input_report_key(&adbhid[id]->input, KEY_EJECTCD, data[1] == (data[1] & 0xf));
+	  break;
 	default:
 	  printk(KERN_INFO "Unhandled button code %02x\n",data[1]&0xf);
 	  break;
diff -ruP -X ../ignorediff linux-2.4.7-pre7-benh20010722-volume/drivers/macintosh/mac_hid.c linux-2.4.7-pre7-benh20010722-volume2/drivers/macintosh/mac_hid.c
--- linux-2.4.7-pre7-benh20010722-volume/drivers/macintosh/mac_hid.c	Thu Jun 28 09:29:50 2001
+++ linux-2.4.7-pre7-benh20010722-volume2/drivers/macintosh/mac_hid.c	Sun Jul 29 00:38:43 2001
@@ -200,15 +200,15 @@
 	0, 0, 0, KEY_KPCOMMA, 0, KEY_INTL3, 0, 0,		/* 0x00-0x07 */
 	0, 0, 0, 0, KEY_LANG1, KEY_LANG2, 0, 0,			/* 0x08-0x0f */
 	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x10-0x17 */
-	0, 0, 0, 0, KEY_KPENTER, KEY_RIGHTCTRL, 0, 0,		/* 0x18-0x1f */
-	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x20-0x27 */
+	0, 0, 0, 0, KEY_KPENTER, KEY_RIGHTCTRL, KEY_VOLUMEUP, 0,		/* 0x18-0x1f */
+	0, 0, 0, 0, 0, KEY_VOLUMEDOWN, KEY_MUTE, 0,					/* 0x20-0x27 */
 	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x28-0x2f */
 	0, 0, 0, 0, 0, KEY_KPSLASH, 0, KEY_SYSRQ,		/* 0x30-0x37 */
-	KEY_RIGHTALT, 0, 0, 0, 0, 0, 0, 0,			/* 0x38-0x3f */
+	KEY_RIGHTALT, KEY_BRIGHTNESSUP, KEY_BRIGHTNESSDOWN, 0, 0, 0, 0, 0,			/* 0x38-0x3f */
 	0, 0, 0, 0, 0, 0, 0, KEY_HOME,				/* 0x40-0x47 */
 	KEY_UP, KEY_PAGEUP, 0, KEY_LEFT, 0, KEY_RIGHT, 0, KEY_END, /* 0x48-0x4f */
 	KEY_DOWN, KEY_PAGEDOWN, KEY_INSERT, KEY_DELETE, 0, 0, 0, 0, /* 0x50-0x57 */
-	0, 0, 0, KEY_LEFTMETA, KEY_RIGHTMETA, KEY_COMPOSE, 0, 0, /* 0x58-0x5f */
+	0, 0, 0, KEY_LEFTMETA, KEY_RIGHTMETA, KEY_COMPOSE, KEY_POWER, 0, /* 0x58-0x5f */
 	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x60-0x67 */
 	0, 0, 0, 0, 0, 0, 0, KEY_MACRO,				/* 0x68-0x6f */
 	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x70-0x77 */

Re: userspace button controls

[Bastien Nocera]

Hi,

Joseph P. Garcia wrote:

>Greetings.
>
>On Sun, 29 Jul 2001 04:48:14 +0100
>Bastien Nocera <hadess@hadess.net> 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.
>
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/

Re: userspace button controls

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

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 <hadess@hadess.net> 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.
>
> eject.patch
>
> Content-Type:
>
> application/octet-stream
> Content-Encoding:
>
> base64
>
>


[-- Attachment #2: buttons2.patch --]
[-- Type: text/plain, Size: 2381 bytes --]

diff -urN linux-benh/drivers/macintosh/adbhid.c linux-benh.new/drivers/macintosh/adbhid.c
--- linux-benh/drivers/macintosh/adbhid.c	Tue Jul 11 12:53:57 1933
+++ linux-benh.new/drivers/macintosh/adbhid.c	Sun Jul 29 23:14:17 2001
@@ -493,6 +493,7 @@
 			set_bit(KEY_VOLUMEDOWN, adbhid[id]->input.keybit);
 			set_bit(KEY_BRIGHTNESSUP, adbhid[id]->input.keybit);
 			set_bit(KEY_BRIGHTNESSDOWN, adbhid[id]->input.keybit);
+			set_bit(KEY_EJECTCD, adbhid[id]->input.keybit);
 			break;
 		}
 		if (adbhid[id]->name[0])
diff -urN linux-benh/drivers/macintosh/mac_hid.c linux-benh.new/drivers/macintosh/mac_hid.c
--- linux-benh/drivers/macintosh/mac_hid.c	Tue Jul 11 12:53:57 1933
+++ linux-benh.new/drivers/macintosh/mac_hid.c	Tue Jul 11 13:17:59 1933
@@ -204,7 +204,7 @@
 	0, 0, 0, 0, 0, KEY_VOLUMEDOWN, KEY_MUTE, 0,					/* 0x20-0x27 */
 	0, 0, 0, 0, 0, 0, 0, 0,					/* 0x28-0x2f */
 	0, 0, 0, 0, 0, KEY_KPSLASH, 0, KEY_SYSRQ,		/* 0x30-0x37 */
-	KEY_RIGHTALT, KEY_BRIGHTNESSUP, KEY_BRIGHTNESSDOWN, 0, 0, 0, 0, 0,			/* 0x38-0x3f */
+	KEY_RIGHTALT, KEY_BRIGHTNESSUP, KEY_BRIGHTNESSDOWN, KEY_EJECTCD, 0, 0, 0, 0,			/* 0x38-0x3f */
 	0, 0, 0, 0, 0, 0, 0, KEY_HOME,				/* 0x40-0x47 */
 	KEY_UP, KEY_PAGEUP, 0, KEY_LEFT, 0, KEY_RIGHT, 0, KEY_END, /* 0x48-0x4f */
 	KEY_DOWN, KEY_PAGEDOWN, KEY_INSERT, KEY_DELETE, 0, 0, 0, 0, /* 0x50-0x57 */
diff -urN linux-benh/drivers/video/aty128fb.c linux-benh.new/drivers/video/aty128fb.c
--- linux-benh/drivers/video/aty128fb.c	Mon Jul 10 23:06:46 1933
+++ linux-benh.new/drivers/video/aty128fb.c	Sun Jul 29 22:24:31 2001
@@ -1921,6 +1921,10 @@
     /* turn off bus mastering, just in case */
     aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL) | BUS_MASTER_DIS);

+#ifdef CONFIG_FB_BACKLIGHT
+    info->backlight_level=FBBACKLIGHT_MAX;
+#endif
+
     aty128fb_set_var(&var, -1, &info->fb_info);
     aty128_init_engine(&info->default_par, info);

@@ -1937,9 +1941,6 @@
 	    pmu_register_sleep_notifier(&aty128_sleep_notifier);
     }
 #endif
-#ifdef CONFIG_FB_BACKLIGHT
-	info->backlight_level=FBBACKLIGHT_MAX;
-#endif

     printk(KERN_INFO "fb%d: %s frame buffer device on %s\n",
 	   GET_FB_IDX(info->fb_info.node), aty128fb_name, name);
@@ -2523,6 +2524,8 @@
 aty128_set_backlight(int on, int level, struct fb_info_aty128* info)
 {
 	unsigned int reg = aty_ld_le32(LVDS_GEN_CNTL);
+
+	info->backlight_level = level;

 	if (!info->lcd_on)
 		on = 0;

[-- Attachment #3: keyevd2.c --]
[-- Type: text/plain, Size: 6322 bytes --]

#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <glib.h>
#include <popt.h>
#include <linux/version.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <syslog.h>
#include <linux/input.h>
#include <linux/soundcard.h>
#include <linux/fb.h>
#include <linux/types.h>

#define DEBUG

gchar *mixername = NULL;
gchar *fbname = NULL;
gboolean use_alsa = FALSE;
gboolean show_help = FALSE;

enum actions {
	VOLUME_UP,
	VOLUME_DOWN,
	VOLUME_MUTE,
	BACKLIGHT_UP,
	BACKLIGHT_DOWN,
	EJECT_CD
};

struct poptOption options[] = {
	{
	 "alsa",
	 'a',
	 POPT_ARG_NONE,
	 &use_alsa,
	 0,
	 "Use ALSA mixer instead of OSS mixer",
	 NULL},
	{
	 "mixer",
	 'm',
	 POPT_ARG_STRING,
	 &mixername,
	 0,
	 "Use a device other than /dev/mixer for the volume control",
	 "MIXER"},
	{
	 "fb",
	 'f',
	 POPT_ARG_STRING,
	 &fbname,
	 0,
	 "Use a device other than /dev/fb for the backlight control",
	 "FB"},
	POPT_AUTOHELP {NULL, 0, 0, NULL, 0}
};

static void quit(gint i, gchar * msg)
{
	g_print("%s\n", msg);
	exit(i);
}

static void do_signal(gint signum)
{
	gchar *msg = 0;

	/* There's a leak here, but we don't care since we're
	 * quitting the app */
	g_strdup_printf("Caught signal %d", signum);
	quit(signum == SIGTERM ? 0 : -1, msg);
}

#define open_action_dev(x) open(x,O_RDONLY)

static void volume_actions_oss(int action)
{
#ifdef SINGLE_CHANNEL
#define CHANNEL SOUND_MIXER_VOLUME
	static int mute = 0;
#else
#define CHANNELS 2
	static int channel[CHANNELS] =
	    { SOUND_MIXER_VOLUME, SOUND_MIXER_SPEAKER };
	static int channelidx = 0;
#define CHANNEL channel[channelidx]
#endif
	int actionfd;
	static int vol = 0;
	int parm;

	actionfd = open_action_dev(mixername);
	switch (action) {
#ifdef SINGLE_CHANNEL
	case VOLUME_UP:
		if (!mute) {
			ioctl(actionfd, MIXER_READ(CHANNEL), &vol);
			vol = (vol & 0xff) + 8;
			if (vol > 100)
				vol = 100;
			vol |= vol << 8;
		}		//dont increment if unmute from press
		mute = 0;
		parm = vol;
		break;
	case VOLUME_DOWN:
		ioctl(actionfd, MIXER_READ(CHANNEL), &parm);
		if (parm || mute) {	//if we aren't muted anymore or we think we are muted
			mute = 0;	//not muted now
			if (parm) {	//weren't anyway
				vol = parm;
				vol = (vol & 0xff) - 8;
				if (vol < 0)
					vol = 0;
				vol |= vol << 8;
			}	//dont decrement if unmuting due to press
			parm = vol;
		} else {	//no vol and no mute... we're mute now..
			mute = 1;
			parm = 0;
		}
		break;
	case VOLUME_MUTE:
		if (!mute) {
			ioctl(actionfd, MIXER_READ(CHANNEL), &parm);
			if (!parm) {	//already muted and we didn't know it
				parm = vol;	//if vol==0, it was deliberate.
				mute = 0;
			} else {	//have volume.  mute
				vol = parm;
				parm = 0;
				mute = 1;
			}
		} else {
			parm = vol;
			mute = 0;
		}
		break;
#else
	case VOLUME_UP:
		vol = (vol & 0xff) + 8;
		if (vol > 100)
			vol = 100;
		vol |= vol << 8;
		break;
	case VOLUME_DOWN:
		vol = (vol & 0xff) - 8;
		if (vol < 0)
			vol = 0;
		vol |= vol << 8;
		break;
	case VOLUME_MUTE:
		ioctl(actionfd, MIXER_READ(CHANNEL), &vol);
		parm = 0;
		ioctl(actionfd, MIXER_WRITE(CHANNEL), &parm);
		channelidx = (channelidx + 1) % CHANNELS;
		parm = vol;
		break;
#endif
	}
	ioctl(actionfd, MIXER_WRITE(CHANNEL), &parm);
	close(actionfd);
}

static void backlight_actions(int action)
{
	int actionfd;
	__u32 bklight;
	int foo;

	actionfd = open_action_dev(fbname);
	ioctl(actionfd, FBIOGET_BACKLIGHT, &bklight);
	switch (action) {
	case BACKLIGHT_UP:
		bklight++;
		if (bklight > FBBACKLIGHT_MAX)
			bklight = FBBACKLIGHT_MAX;
		break;
	case BACKLIGHT_DOWN:
		if (bklight > FBBACKLIGHT_OFF)
			bklight--;
		break;
	}
	foo = ioctl(actionfd, FBIOSET_BACKLIGHT, &bklight);
	if (foo <0)
		perror("keyevd");
	close(actionfd);
}

int main(int argc, const char **argv)
{
	poptContext pctx;
	int eventfd = -1;
	struct input_event inp;
	struct sigaction sigpipe = { {SIG_IGN}, {{0}}, SA_RESTART, 0 };
	struct sigaction sigterm = { {do_signal}, {{0}}, SA_RESTART, 0 };
	short ids[4];
	char *filename;

	int i;

	pctx = poptGetContext(NULL, argc, argv, options, 0);

	while ((i = poptGetNextOpt(pctx)) != -1) {	//everything should be handled
		poptStrerror(i);
		printf("%s: %s (-? for help)\n", poptStrerror(i),
		       poptBadOption(pctx, 0));
		exit(0);
	}
	if (mixername == NULL) {
		if (use_alsa == FALSE)
			mixername = g_strdup("/dev/mixer");
		else
			g_print("somebody please fix this ;)\n");
	}
	if (fbname == NULL)
		fbname = g_strdup("/dev/fb0");

	if (sigaction(SIGTERM, &sigterm, 0))
		quit(-1, "could not install SIGTERM handler");

	if (sigaction(SIGPIPE, &sigpipe, 0))
		quit(-1, "could not install SIGPIPE handler");

	for (i = 0; i < 32; i++) {
		filename = g_strdup_printf("/dev/input/event%i", i);
		eventfd = open(filename, O_RDONLY);
		if (eventfd >= 0) {
			ioctl(eventfd, EVIOCGID, ids);
			if ((ids[2] & 0xfff) == 0x71f) {
				printf("Powerbook Button device found at event%i.\n",
				       i);
				syslog(LOG_INFO,
				       "Powerbook Button device found at event%i.\n",
				       i);
				break;
			}
#ifdef DEBUG
			fprintf(stderr, "[%x] ids - %x %x %x %x\n", i,
				ids[0], ids[1], ids[2], ids[3]);
#endif
			close(eventfd);
			eventfd = -1;
		}
#ifdef DEBUG
		else {
			fprintf(stderr, "[%x] nil\n", i);
		}
#endif
	}
	if (eventfd < 0) {
		printf("Powerbook Button event device not found.\n");
		exit(-1);
	}
#ifndef DEBUG
	{
		int pid = fork();

		if (pid < 0) {
			printf("Couldn't fork\n");
			exit(-1);
		}
		if (pid > 0)
			quit(0, "parent exiting [note PID]");

		chdir("/");
		setsid();
		close(0);
		close(1);
		close(2);
	}
#endif
	while (read(eventfd, &inp, sizeof(inp))) {
		if (inp.value) {
			g_print("Event %0x caught\n", inp.code);
			switch (inp.code) {
			case KEY_MUTE:
				if (inp.value == 2)
					continue;
				if (!use_alsa)
					volume_actions_oss(VOLUME_MUTE);
				else
					g_print("fixme\n");
				break;
			case KEY_VOLUMEDOWN:
				if (!use_alsa)
					volume_actions_oss(VOLUME_DOWN);
				else
					g_print("fixme\n");
				break;
			case KEY_VOLUMEUP:
				if (!use_alsa)
					volume_actions_oss(VOLUME_UP);
				else
					g_print("fixme\n");
				break;
			case KEY_BRIGHTNESSDOWN:
				backlight_actions(BACKLIGHT_DOWN);
				break;
			case KEY_BRIGHTNESSUP:
				backlight_actions(BACKLIGHT_UP);
				break;
			case KEY_EJECTCD:
				system("eject");
				break;
			}
		}
	}
	close(eventfd);
	return 0;
}

Clock problem

[Ethan Blanton]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Bastien Nocera spake unto us the following wisdom:
> 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).

Are those "clock problems" by any chance a *mean* drift?  (on the
order of seconds per minute)  I had that problem, and BenH suggested
that I comment out two lines in pmac_time.c (via_calibrate_decr () in
an if statement and the following line).  That worked like a charm.

That said, it looks like maybe he's fixed it in the 2.4.7-ben0.  I
haven't yet tried booting it, but I see that there's an extra if
clause that was not there before.
Ethan

-- 
If I've told you once, I've told you once
And once is all that you needed.
		-- The Refreshments, "Carefree"

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: Clock problem

[Bastien Nocera]

Ethan Blanton wrote:

>Bastien Nocera spake unto us the following wisdom:
>
>>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).
>>
>
>Are those "clock problems" by any chance a *mean* drift?  (on the
>
mean ? not really, goes back to 1933 after each reboot...

>
>order of seconds per minute)  I had that problem, and BenH suggested
>that I comment out two lines in pmac_time.c (via_calibrate_decr () in
>an if statement and the following line).  That worked like a charm.
>
>That said, it looks like maybe he's fixed it in the 2.4.7-ben0.  I
>haven't yet tried booting it, but I see that there's an extra if
>clause that was not there before.
>Ethan
>


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

Re: Clock problem

[Martin Costabel]

Bastien Nocera wrote:

> mean ? not really, goes back to 1933 after each reboot...

You don't mean 1903? 'Cause that's what I get (December 31, 1903) after
each try to boot either 2.4.7-ben0 or 2.4.8-pre1(kernel.org) on my
iBook1-FW. 2.4.7-ben0 goes up to ..mounting local file systems.. and
then dumps me into xmon from a process ksoftirqd_CPU0 or something
similar. At leaving xmon, it shuts down hard, the PRAM is zapped, and it
is Dec 31, 1903. This is worse than taking out the battery, which gives
Jan 1st, 1904.

hwclock stopped working ("/dev/rtc no such device") already in BenH's
2.4.6 which is working nicely otherwise. In 2.4.6-pre8, hwclock still works.

2.4.8-pre1 boots if I don't let it find its modules. If it finds them,
then something (probably dmasound_awacs) writes garbage into the
framebuffer and produces a crash complete with zapped PRAM.

For the moment, I stay with 2.4.6-pre8 (or MacOSX :-))

--
Martin

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

Re: Clock problem

[David Schleef]

On Mon, Jul 30, 2001 at 06:16:32PM +0200, Martin Costabel wrote:
>
> Bastien Nocera wrote:
>
> > mean ? not really, goes back to 1933 after each reboot...
>
> You don't mean 1903? 'Cause that's what I get (December 31, 1903) after
> each try to boot either 2.4.7-ben0 or 2.4.8-pre1(kernel.org) on my
> iBook1-FW. 2.4.7-ben0 goes up to ..mounting local file systems.. and
> then dumps me into xmon from a process ksoftirqd_CPU0 or something
> similar. At leaving xmon, it shuts down hard, the PRAM is zapped, and it
> is Dec 31, 1903. This is worse than taking out the battery, which gives
> Jan 1st, 1904.


1933 is significant because it is 2^31 seconds in the past.
Apparently, there is a difference in the way that stime() and
settimeofday() operate, since the date command works correctly
when the year is set to 1903 (and uses stime()), whereas ntpdate
does not.  (ntpdate uses settimeofday()).  Then again, it might
just be a bug in ntpdate.



dave...

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