pbbuttons-users — Everything regarding pbbuttons' usage and develpment

Re: Question about CFLAGS handling in configure.in

[Frank L. <dj...@de...>]

On Thu, Sep 29, 2005 at 07:56:04PM +0200, Matthias Grimm wrote:
> On Wed, 28 Sep 2005 19:24:09 +0200
> Frank Lichtenheld <dj...@de...> wrote:
> > Is there a good reason to do this? It seems you use this only to
> > filter out "-g" from CFLAGS?
> 
> This code is a relict from the very beginning of pbbuttonsd development.
> I used the autotools files from glade as base for my own. This sippet
> was part of the glade files and was never questioned.
> 
> Any suggestions to replace it?

I made the following patch (it's against gtkpbbuttons):
Index: configure.in
===================================================================
RCS file:
/home/djpig/vcs/cvs/Projekte/debian/gtkpbbuttons/configure.in,v
retrieving revision 1.1.1.7
retrieving revision 1.2
diff -u -r1.1.1.7 -r1.2
--- configure.in        7 Jul 2005 17:15:02 -0000       1.1.1.7
+++ configure.in        28 Sep 2005 17:53:35 -0000      1.2
@@ -88,7 +88,6 @@
 packagesrcdir=`cd $srcdir && pwd`
 AC_DEFINE_UNQUOTED(PACKAGE_SOURCE_DIR, "${packagesrcdir}", [source dir of the package])

-CFLAGS=
 dnl Use -Wall if we have gcc.
 changequote(,)dnl
 if test "x$GCC" = "xyes"; then
Index: src/Makefile.am
===================================================================
RCS file:
/home/djpig/vcs/cvs/Projekte/debian/gtkpbbuttons/src/Makefile.am,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- src/Makefile.am     28 Jan 2005 11:23:45 -0000      1.1.1.3
+++ src/Makefile.am     28 Sep 2005 17:53:35 -0000      1.2
@@ -21,9 +21,7 @@
 gtkpbbuttons_LDFLAGS = @PBB_LDFLAGS@

 if DEBUG
-AM_CFLAGS = -g -DDEBUG
-else
-AM_CFLAGS = -O2
+AM_CFLAGS = -DDEBUG
 endif

This still adds -Wall wether the user wants or not but at least
he can override everything else...

Please note though that this changes the build behaviour so that
now the program will always compiled with -g (because
that's the standard autotools behaviour which was broken by the
current code).

If you want to really simplify things just delete the whole code block
and let users always decide which CFLAGS they want by specifying them
to ./configure.
If you want to complicate things (one never knows), copy AC_PROG_CC
and patch it so that it does what you like. This would enable you
to safely check for CFLAGS inherited by the environment because it
is cleary impossible to do that _after_ AC_PROG_CC ...

(I used that ocasion of fiddling with Makefile.am to also update the
gtkpbbuttons automake stuff to automake 1.9)

Gruesse,
-- 
Frank Lichtenheld <dj...@de...>
www: http://www.djpig.de/

Re: mac-mini power button

[Matthias G. <mat...@us...>]

On Thu, 15 Sep 2005 10:01:43 +0200
pix <pi...@te...> wrote:

> i could see that on pressing the power button, the bytes [0x40 0x0c] are
> generated. when you release the button, [0x40 0x04] is generated.
> 
> i tried adding this to the module_pmac.c file, but then i noticed a
> bigger problem. it appears that when running on the mac mini, pbbuttonsd
> doesn't even listen to /dev/pmu. to check, i turned on PMUINTR in
> debug.h and compiled with -DDEBUG. i get a lot more debug info, but i
> don't get the expected line printing out the bytes that i know are being
> generated at /dev/pmu... so i assume somewhere during startup, pbbutons
> makes some decision not to monitor /dev/pmu.. possibly because it
> doesn't support many laptop-like functions, such as sleeping (this is
> also why pmud doesn't want to start on the mac-mini).

There is no check for desktop or laptop in pbbuttonsd. As long
as /dev/pmu could be opened it would always be read (check permissions
on /dev/pmu and your logs for pbbuttonsd error messages). Could you
send me the debug output?

> i hope this is useful for the developers, unless there is some policy
> about not supporting desktop machines...

Such a policy doesn't exist. If something doesn't work, we make it work.

  Best Regards
    Matthias

Re: Question about CFLAGS handling in configure.in

[Matthias G. <mat...@us...>]

On Wed, 28 Sep 2005 19:24:09 +0200
Frank Lichtenheld <dj...@de...> wrote:

> In configure.in of gtkpbbuttonsd (and probably the others, too, didn't
> check) you use the following snippet:
> 
> CFLAGS=
> dnl Use -Wall if we have gcc.
> changequote(,)dnl
> if test "x$GCC" = "xyes"; then
>   case " $CFLAGS " in
>   *[\ \ ]-Wall[\ \      ]*) ;;
>   *) CFLAGS="$CFLAGS -Wall" ;;
>   esac
> fi
> changequote([,])dnl
> 
> which is bit "suboptimal", since it deletes all previous changes
> to CFLAGS, especially such given in the configure commandline or
> as enviroment variables.
> 
> Is there a good reason to do this? It seems you use this only to
> filter out "-g" from CFLAGS?

This code is a relict from the very beginning of pbbuttonsd development.
I used the autotools files from glade as base for my own. This sippet
was part of the glade files and was never questioned.

Any suggestions to replace it?

 Best Regards
   Matthias

Re: [patch] pbbuttonsd should not go to sleep on init 0 ?

[Kristian B. <kb...@op...>]

On Thu, 2005-09-15 at 00:25 -0400, Kristian Benoit wrote:
> On Thu, 2005-09-15 at 01:16 +0200, Gabriel Labelle wrote:
> > On Wed, 2005-09-14 at 23:44 +0200, Frank Lichtenheld wrote:
> > > On Wed, Sep 14, 2005 at 06:23:50PM +0200, Matthias Grimm wrote:
> > > > On Tue, 13 Sep 2005 16:39:19 -0400
> > > > Kristian Benoit <kb...@op...> wrote:
> > > > 
> > > > > > What you mean is a user action "shutdown" on the same level as
> > > > > > "suspend-to-RAM" or "suspend-to-disk". Such a action is currently
> > > > > > not
> > > > > > supported and haven't been requested yet.
> > > > > 
> > > > > IMO, Gab mean if you type "shutdown -h now" then close the lid, it
> > > > > should'nt go to sleep.
> > > > 
> > > > Ah, this type of mechanism. But if you type ths shutdown command to the
> > > > console, you could also start a script that kill pbbuttonsd just before
> > > > it calls shutdown, couldn't you? Anyway you have to tell pbbuttonsd that
> > > > you are going to shutdown,
> 
> The shutdown might come from the gui or whatever.
> 
> > > Hmm, it might be a good idea to kill pbbuttonsd as soon as possible
> > > on shutdown, i.e. install the init script as K01 instead of K20
> > > in rc0.d
> 
> The problem with this, is that init send a term to it's childs, wait 1-5
> seconds then send a kill. In 5 seconds, you have the time to close the
> lid.
>  
> > Maybe I'm saying something stupid but, could pbbuttonsd simply always
> > check current runlevel before making the *book go to sleep?
> >
> > If current init is 0 (or 6? maybe not a good idea?) it just doesn't go
> > to sleep.
> 
> Yeah!! seems like the best idea !! here's the patch :)
> 
> --- pbbuttonsd-0.7.1/src/module_powersave.c.orig        2005-09-14 23:59:15.000000000 -0400
> +++ pbbuttonsd-0.7.1/src/module_powersave.c     2005-09-15 00:10:13.000000000 -0400
> @@ -21,6 +21,7 @@
>  #include <string.h>
>  #include <signal.h>
>  #include <fcntl.h>
> +#include <utmp.h>
>  #include <sys/time.h>
>  #include <sys/ioctl.h>
>  #include <sys/kd.h>
> @@ -313,6 +314,28 @@ power_sync ()
>         base->activeProfile = base->powersource ? &base->onAC : &base->onBattery;
>  }
> 
> +int
> +power_shuttingdown ()
> +{
> +       struct utmp *ut;
> +       int runlevel=-1;
> +       int shuttingdown = 0;
> +
> +       setutent();
> +       while ((ut = getutent()) != NULL) {
> +               if (ut->ut_type == RUN_LVL) {
> +                       runlevel = ut->ut_pid % 256;
> +                       break;
> +               }
> +       }
> +       endutent();
> +
> +       if (runlevel == '0' || runlevel == '6')
> +               shuttingdown = 1;
> +
> +       return shuttingdown;
> +}
> +
>  void
>  power_query (struct tagitem *taglist)
>  {
> @@ -811,11 +834,13 @@ power_suspend (int action)
> 
>         switch (action) {
>         case ACTION_TODISK:
> -               singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
> -               call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "disk");
> -               break;
> +               if (!power_shuttingdown()) {
> +                       singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
> +                       call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "disk");
> +                       break;
> +               }
>         case ACTION_TORAM:
> -               if (base->flags.sleep_supported) {
> +               if (base->flags.sleep_supported && !power_shuttingdown()) {
>                         singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
>  /*                     sleep(1);    give clients a chance to react */
>                         call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "ram");
> 
> 
> Et voila !! :)
> 
> Kristian

I check the cvs ... not yet in. I wonder if this fix is fine with you to
push in ? Or if you see a better solution ? Or if you think it's fine
like it actually is ?

Kristian

Question about CFLAGS handling in configure.in

[Frank L. <dj...@de...>]

In configure.in of gtkpbbuttonsd (and probably the others, too, didn't
check) you use the following snippet:

CFLAGS=
dnl Use -Wall if we have gcc.
changequote(,)dnl
if test "x$GCC" = "xyes"; then
  case " $CFLAGS " in
  *[\ \ ]-Wall[\ \      ]*) ;;
  *) CFLAGS="$CFLAGS -Wall" ;;
  esac
fi
changequote([,])dnl

which is bit "suboptimal", since it deletes all previous changes
to CFLAGS, especially such given in the configure commandline or
as enviroment variables.

Is there a good reason to do this? It seems you use this only to
filter out "-g" from CFLAGS?

Gruesse,
-- 
Frank Lichtenheld <dj...@de...>
www: http://www.djpig.de/

mac-mini power button

[pix <pi...@te...>]

hi,

i was trying to get pbbuttons to detect the mac-mini power button. by
running: 

od -t x1 -w1 /dev/pmu

i could see that on pressing the power button, the bytes [0x40 0x0c] are
generated. when you release the button, [0x40 0x04] is generated.

i tried adding this to the module_pmac.c file, but then i noticed a
bigger problem. it appears that when running on the mac mini, pbbuttonsd
doesn't even listen to /dev/pmu. to check, i turned on PMUINTR in
debug.h and compiled with -DDEBUG. i get a lot more debug info, but i
don't get the expected line printing out the bytes that i know are being
generated at /dev/pmu... so i assume somewhere during startup, pbbutons
makes some decision not to monitor /dev/pmu.. possibly because it
doesn't support many laptop-like functions, such as sleeping (this is
also why pmud doesn't want to start on the mac-mini).

anyhow, i have resorted to writing a small program which does nothing
but monitor /dev/pmu, and hand off any read bytes to a script, which
then halts the machine is the power button is pressed.

it is available here... http://f0.am/darcs/lyta/system/pmumon/ the
install rule is very debian-centric, sorry. also, the rcd script
included sets server_mode in /proc/pmu/options, which is something very
peculiar to our setup here, and possibly isn't what you want.

it would probably be better for this *cough* feature to be incorporated
into pbbuttonsd, but it seems a few people are trying to get their
mac-mini power buttons to work like this, so i've made this available.

i hope this is useful for the developers, unless there is some policy
about not supporting desktop machines...

pix.

Re: [patch] pbbuttonsd should not go to sleep on init 0 ?

[Kristian B. <kb...@op...>]

On Thu, 2005-09-15 at 01:16 +0200, Gabriel Labelle wrote:
> On Wed, 2005-09-14 at 23:44 +0200, Frank Lichtenheld wrote:
> > On Wed, Sep 14, 2005 at 06:23:50PM +0200, Matthias Grimm wrote:
> > > On Tue, 13 Sep 2005 16:39:19 -0400
> > > Kristian Benoit <kb...@op...> wrote:
> > > 
> > > > > What you mean is a user action "shutdown" on the same level as
> > > > > "suspend-to-RAM" or "suspend-to-disk". Such a action is currently
> > > > > not
> > > > > supported and haven't been requested yet.
> > > > 
> > > > IMO, Gab mean if you type "shutdown -h now" then close the lid, it
> > > > should'nt go to sleep.
> > > 
> > > Ah, this type of mechanism. But if you type ths shutdown command to the
> > > console, you could also start a script that kill pbbuttonsd just before
> > > it calls shutdown, couldn't you? Anyway you have to tell pbbuttonsd that
> > > you are going to shutdown,

The shutdown might come from the gui or whatever.

> > Hmm, it might be a good idea to kill pbbuttonsd as soon as possible
> > on shutdown, i.e. install the init script as K01 instead of K20
> > in rc0.d

The problem with this, is that init send a term to it's childs, wait 1-5
seconds then send a kill. In 5 seconds, you have the time to close the
lid.
 
> Maybe I'm saying something stupid but, could pbbuttonsd simply always
> check current runlevel before making the *book go to sleep?
>
> If current init is 0 (or 6? maybe not a good idea?) it just doesn't go
> to sleep.

Yeah!! seems like the best idea !! here's the patch :)

--- pbbuttonsd-0.7.1/src/module_powersave.c.orig        2005-09-14 23:59:15.000000000 -0400
+++ pbbuttonsd-0.7.1/src/module_powersave.c     2005-09-15 00:10:13.000000000 -0400
@@ -21,6 +21,7 @@
 #include <string.h>
 #include <signal.h>
 #include <fcntl.h>
+#include <utmp.h>
 #include <sys/time.h>
 #include <sys/ioctl.h>
 #include <sys/kd.h>
@@ -313,6 +314,28 @@ power_sync ()
        base->activeProfile = base->powersource ? &base->onAC : &base->onBattery;
 }

+int
+power_shuttingdown ()
+{
+       struct utmp *ut;
+       int runlevel=-1;
+       int shuttingdown = 0;
+
+       setutent();
+       while ((ut = getutent()) != NULL) {
+               if (ut->ut_type == RUN_LVL) {
+                       runlevel = ut->ut_pid % 256;
+                       break;
+               }
+       }
+       endutent();
+
+       if (runlevel == '0' || runlevel == '6')
+               shuttingdown = 1;
+
+       return shuttingdown;
+}
+
 void
 power_query (struct tagitem *taglist)
 {
@@ -811,11 +834,13 @@ power_suspend (int action)

        switch (action) {
        case ACTION_TODISK:
-               singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
-               call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "disk");
-               break;
+               if (!power_shuttingdown()) {
+                       singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
+                       call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "disk");
+                       break;
+               }
        case ACTION_TORAM:
-               if (base->flags.sleep_supported) {
+               if (base->flags.sleep_supported && !power_shuttingdown()) {
                        singletag_to_clients(WARNING, TAG_SLEEPINSECONDS, 0);
 /*                     sleep(1);    give clients a chance to react */
                        call_script (base->script_pmcs, "suspend", base->powersource ? "ac" : "battery", "ram");


Et voila !! :)

Kristian

Re: pbbuttonsd should not go to sleep on init 0 ?

[Gabriel L. <gla...@op...>]

On Wed, 2005-09-14 at 23:44 +0200, Frank Lichtenheld wrote:
> On Wed, Sep 14, 2005 at 06:23:50PM +0200, Matthias Grimm wrote:
> > On Tue, 13 Sep 2005 16:39:19 -0400
> > Kristian Benoit <kb...@op...> wrote:
> > 
> > > > What you mean is a user action "shutdown" on the same level as
> > > > "suspend-to-RAM" or "suspend-to-disk". Such a action is currently
> > > > not
> > > > supported and haven't been requested yet.
> > > 
> > > IMO, Gab mean if you type "shutdown -h now" then close the lid, it
> > > should'nt go to sleep.
> > 
> > Ah, this type of mechanism. But if you type ths shutdown command to the
> > console, you could also start a script that kill pbbuttonsd just before
> > it calls shutdown, couldn't you? Anyway you have to tell pbbuttonsd that
> > you are going to shutdown,
> 
> Hmm, it might be a good idea to kill pbbuttonsd as soon as possible
> on shutdown, i.e. install the init script as K01 instead of K20
> in rc0.d
> 
> Gruesse,

Maybe I'm saying something stupid but, could pbbuttonsd simply always
check current runlevel before making the *book go to sleep?

If current init is 0 (or 6? maybe not a good idea?) it just doesn't go
to sleep.

-- 
Gabriel Labelle <gla...@op...>

Re: pbbuttonsd should not go to sleep on init 0 ?

[Frank L. <dj...@de...>]

On Wed, Sep 14, 2005 at 06:23:50PM +0200, Matthias Grimm wrote:
> On Tue, 13 Sep 2005 16:39:19 -0400
> Kristian Benoit <kb...@op...> wrote:
> 
> > > What you mean is a user action "shutdown" on the same level as
> > > "suspend-to-RAM" or "suspend-to-disk". Such a action is currently
> > > not
> > > supported and haven't been requested yet.
> > 
> > IMO, Gab mean if you type "shutdown -h now" then close the lid, it
> > should'nt go to sleep.
> 
> Ah, this type of mechanism. But if you type ths shutdown command to the
> console, you could also start a script that kill pbbuttonsd just before
> it calls shutdown, couldn't you? Anyway you have to tell pbbuttonsd that
> you are going to shutdown,

Hmm, it might be a good idea to kill pbbuttonsd as soon as possible
on shutdown, i.e. install the init script as K01 instead of K20
in rc0.d

Gruesse,
-- 
Frank Lichtenheld <dj...@de...>
www: http://www.djpig.de/

Re: pbbuttonsd should not go to sleep on init 0 ?

[Matthias G. <mat...@us...>]

On Tue, 13 Sep 2005 16:39:19 -0400
Kristian Benoit <kb...@op...> wrote:

> > What you mean is a user action "shutdown" on the same level as
> > "suspend-to-RAM" or "suspend-to-disk". Such a action is currently
> > not
> > supported and haven't been requested yet.
> 
> IMO, Gab mean if you type "shutdown -h now" then close the lid, it
> should'nt go to sleep.

Ah, this type of mechanism. But if you type ths shutdown command to the
console, you could also start a script that kill pbbuttonsd just before
it calls shutdown, couldn't you? Anyway you have to tell pbbuttonsd that
you are going to shutdown,

 Best Regards
   Matthias

Re: pbbuttonsd should not go to sleep on init 0 ?

[Kristian B. <kb...@op...>]

On Tue, 2005-09-13 at 15:57 +0200, Matthias Grimm wrote:
> On Tue, 13 Sep 2005 15:05:44 +0200
> Gabriel Labelle <gla...@op...> wrote:
> 
> > I installed and use pbbuttonsd 0.7.1 on Ubuntu Breezy it works like a charm
> > (except for the keyboard backlit I'm unable to enable).
> 
> Check your I2C devices. Mostly it is i2c-4.
>  
> > The problem is when I shutdown or reboot my Powerbook and close the the
> > Powerbook itself, it goes to sleep instead of simply shuting down as I
> > requested. IMHO, it shouldn't because the user has request a shutdown and might
> > simply want to leave his desk rapidly and close the *book.
> 
> Thats a little problem. Shutdown is offered only as emergency action,
> that means only if the battery was critically low the machine would
> shut down (or send a signal to init).
> 
> What you mean is a user action "shutdown" on the same level as
> "suspend-to-RAM" or "suspend-to-disk". Such a action is currently not
> supported and haven't been requested yet.

IMO, Gab mean if you type "shutdown -h now" then close the lid, it
should'nt go to sleep.

> It would be really simple to add this action. What is the general
> opinion about a shutdown action? Will it be more dangerous than useful
> or vica versa? What do you think?

I think the solution would be to tweek init or an initscript so it send
a msg "disable suspend" to pbbuttonsd as early as possible when entering
runlevel 0 or 6.

Kristian

Re: pbbuttonsd should not go to sleep on init 0 ?

[Matthias G. <mat...@us...>]

On Tue, 13 Sep 2005 15:05:44 +0200
Gabriel Labelle <gla...@op...> wrote:

> I installed and use pbbuttonsd 0.7.1 on Ubuntu Breezy it works like a charm
> (except for the keyboard backlit I'm unable to enable).

Check your I2C devices. Mostly it is i2c-4.
 
> The problem is when I shutdown or reboot my Powerbook and close the the
> Powerbook itself, it goes to sleep instead of simply shuting down as I
> requested. IMHO, it shouldn't because the user has request a shutdown and might
> simply want to leave his desk rapidly and close the *book.

Thats a little problem. Shutdown is offered only as emergency action,
that means only if the battery was critically low the machine would
shut down (or send a signal to init).

What you mean is a user action "shutdown" on the same level as
"suspend-to-RAM" or "suspend-to-disk". Such a action is currently not
supported and haven't been requested yet.

It would be really simple to add this action. What is the general
opinion about a shutdown action? Will it be more dangerous than useful
or vica versa? What do you think?

  Best Regards
   Matthias

pbbuttonsd should not go to sleep on init 0 ?

[Gabriel L. <gla...@op...>]

Hello,

I installed and use pbbuttonsd 0.7.1 on Ubuntu Breezy it works like a charm
(except for the keyboard backlit I'm unable to enable).

The problem is when I shutdown or reboot my Powerbook and close the the
Powerbook itself, it goes to sleep instead of simply shuting down as I
requested. IMHO, it shouldn't because the user has request a shutdown and might
simply want to leave his desk rapidly and close the *book.

-- 
Gabriel Labelle <gla...@op...>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: ejectcdkey does not work with key 161

[Kristian B. <kb...@op...>]

On Sat, 2005-09-03 at 09:57 +0200, Matthias Grimm wrote:
> On Tue, 30 Aug 2005 10:17:39 -0400
> Kristian Benoit <kb...@op...> wrote:
> 
> Your config seems to be ok. I haven't any explanation for this.
> I attached two programs to scan your event devices. Would you
> please run them and send me the output?
> 
> First you need to compile them:
>   gcc -Wall -o cev cev.c
>   gcc -Wall -o evtest evtest.c
> 
> cev finds available event devices and reads generic information from
> them. evtest does deeper investigation on a single event device. Please
> call it with the device that handles your eject key.

# ./cev
[0] ids - 17 1 1 100  Name: Macintosh mouse button emulation
  Supported Events:
  0 (Reset) 1 (Key) 2 (Relative)
[1] ids - 3 5ac 1000 1792  Name: 05ac:1000
  Supported Events:
  0 (Reset) 1 (Key) 17 (LED) 20 (Repeat)
[2] ids - 3 5ac 1000 1792  Name: 05ac:1000
  Supported Events:
  0 (Reset) 1 (Key) 2 (Relative)
[3] ids - 3 5ac 20e 28  Name: Apple Computer Apple Internal
Keyboard/Trackpad
  Supported Events:
  0 (Reset) 1 (Key) 17 (LED) 20 (Repeat)
[4] ids - 3 5ac 20e 28  Name: Apple Computer Apple Internal
Keyboard/Trackpad
  Supported Events:
  0 (Reset) 1 (Key)
[5] ids - 3 5ac 20e 7  Name: appletouch
  Supported Events:
  0 (Reset) 1 (Key) 3 (Absolute)
[6] ids - 17 1f 1 100  Name: PowerMac Beep
  Supported Events:
  0 (Reset) 18 (Sound)
[7] nil
[8] ...

# ./evtest /dev/input/event4
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x5ac product 0x20e version 0x28
Input device name: "Apple Computer Apple Internal Keyboard/Trackpad"
Supported events:
  Event type 0 (Reset)
    Event code 0 (Reset)
    Event code 1 (Key)
  Event type 1 (Key)
    Event code 161 (EjectCD)
Testing ... (interrupt to exit)
Event: time 1126495636.864879, type 1 (Key), code 161 (EjectCD), value 1
Event: time 1126495636.864882, type 0 (Reset), code 0 (Reset), value 0
Event: time 1126495637.024857, type 1 (Key), code 161 (EjectCD), value 0
Event: time 1126495637.024859, type 0 (Reset), code 0 (Reset), value 0

Thanks, that actually help me finding out I had an old version (0.6.6)
which is still the the stable version on gentoo. So I installed 0.7.1
and it work fine now.

Kristian

Re: ejectcdkey does not work with key 161

[Matthias G. <mat...@us...>]

On Tue, 30 Aug 2005 10:17:39 -0400
Kristian Benoit <kb...@op...> wrote:

Your config seems to be ok. I haven't any explanation for this.
I attached two programs to scan your event devices. Would you
please run them and send me the output?

First you need to compile them:
  gcc -Wall -o cev cev.c
  gcc -Wall -o evtest evtest.c

cev finds available event devices and reads generic information from
them. evtest does deeper investigation on a single event device. Please
call it with the device that handles your eject key.

  Best Regards
    Matthias

ejectcdkey does not work with key 161

[Kristian B. <kb...@op...>]

Hi, I have this weird problem with a powerbook5,6.
$ pbbcmd query EJECTCDKEY
161

$ showkey # press on the eject key
keycode 161 press
keycode 161 release

# but pressing on the key does not eject the cd.

# Strangely, If I:
$ pbbcmd config EJECTCDKEY 88 # Which is F12
# Now pressing on F12 eject the cd.


I Think it is because the eject key is a usb device of it's own (not
part of the keyboard, but emulated as if it was). Any idea on how it
could be solved is welcome.

Kristian

Re: Problems to recover from blankscreen

[Kristian B. <kb...@op...>]

On Sat, 2005-08-20 at 03:13 -0400, Kristian Benoit wrote:
> On Wed, 2005-08-17 at 21:19 +0200, Matthias Grimm wrote:
> > On Wed, 17 Aug 2005 13:41:54 +0200
> > Albert Farr=E9s <alb...@gm...> wrote:
> >=20
> > > Hi list
> > >=20
> > > I've the owner of an iBook G4. I've been using debian with pbbutton=
s
> > > for a year and everything works perfectly except two things:
> > >=20
> > > 1. When pbbutons puts in blankscreen, then, when i want to recover =
the
> > > screen i've to push up or down brigthness key. Before, whith kernel
> > > 2.6.9, i just did move the mouse. How can i return to this mode?
> >=20
> > That are problems with the framebuffer device. Set the option
> > UseFBBlank =3D no. This should help.
> >=20
> > > 2. I works with gnome. It use in ts apps F1, F2, .. keys to launch
> > > apps like help. When i push, for example, fn+F2, pbbunttons increas=
es
> > > the brigthness but gnome launches the help too. How can i do to onl=
y
> > > increase brigthness?
> >=20
> > Please check the keycodes you set in pbbuttonsd.conf. The values for
> > LCD_IllumUpKey and LCD_IllumDownKey should be set as follows:
> >    LCD_IllumUpKey =3D 225
> >    LCD_IllumDownKey =3D 224
>=20
> I have the same problem, but my pbbuttonsd.conf contain:
> LCD_IllumUpKey        =3D 60 + ctrl
> LCD_IllumDownKey      =3D 59 + ctrl
> I tried your settings, but it does not work at all. I think I could
> manage to fix it by modifying the xkb mapping so that it does not repor=
t
> a F1 on pressing Fn-F1. I'll see wat I can do when I'll get the time.

Ok it bugged me enough to have a look here's how it was defined:=20

    key <FK01> {
        type=3D "FUNCTION_FN",
        symbols[Group1]=3D [              F1, XF86_Switch_VT_1,        No=
Symbol ]
    };

And here is how it's now defined and no more problemo !!!

    key <FK01> {
        type=3D "FUNCTION_FN",
        symbols[Group1]=3D [              F1, XF86_Switch_VT_1,        No=
Symbol ],=20
        symbols[Group3]=3D []
    };

I got a weird keyboard mapping so you probably dont want it.

> > If you have something else (for example 59 and 60) please change them=
 to
> > the above values and your problem should be solved.
>=20
> Kristian

Kristian

Re: ERROR: Can't create message port for server: Function not implemented.

[Matthias G. <mat...@us...>]

On Fri, 19 Aug 2005 08:57:34 +0200
Zeno Davatz <zd...@gm...> wrote:

> Hi
> 
> I installed pbbuttonsd 0.7.0 on my PowerBook, with Gentoo and Kernel
> 2.6.13-rc5 (mm sources).
> 
> When I try to start pbbuttonsd I get:
> ERROR: Can't create message port for server: Function not implemented.
> 
> Any hints?

I guess you built your kernel without SUN IPC support. Please check your
kernel config.
  
  Best Regards
    Matthias

Re: Problems to recover from blankscreen

[Kristian B. <kb...@op...>]

On Wed, 2005-08-17 at 21:19 +0200, Matthias Grimm wrote:
> On Wed, 17 Aug 2005 13:41:54 +0200
> Albert Farr=E9s <alb...@gm...> wrote:
>=20
> > Hi list
> >=20
> > I've the owner of an iBook G4. I've been using debian with pbbuttons
> > for a year and everything works perfectly except two things:
> >=20
> > 1. When pbbutons puts in blankscreen, then, when i want to recover th=
e
> > screen i've to push up or down brigthness key. Before, whith kernel
> > 2.6.9, i just did move the mouse. How can i return to this mode?
>=20
> That are problems with the framebuffer device. Set the option
> UseFBBlank =3D no. This should help.
>=20
> > 2. I works with gnome. It use in ts apps F1, F2, .. keys to launch
> > apps like help. When i push, for example, fn+F2, pbbunttons increases
> > the brigthness but gnome launches the help too. How can i do to only
> > increase brigthness?
>=20
> Please check the keycodes you set in pbbuttonsd.conf. The values for
> LCD_IllumUpKey and LCD_IllumDownKey should be set as follows:
>    LCD_IllumUpKey =3D 225
>    LCD_IllumDownKey =3D 224

I have the same problem, but my pbbuttonsd.conf contain:
LCD_IllumUpKey        =3D 60 + ctrl
LCD_IllumDownKey      =3D 59 + ctrl
I tried your settings, but it does not work at all. I think I could
manage to fix it by modifying the xkb mapping so that it does not report
a F1 on pressing Fn-F1. I'll see wat I can do when I'll get the time.

> If you have something else (for example 59 and 60) please change them t=
o
> the above values and your problem should be solved.

Kristian

Re: Problems to recover from blankscreen

[<alb...@gm...>]

2005/8/17, Matthias Grimm <mat...@us...>:
> On Wed, 17 Aug 2005 13:41:54 +0200
> Albert Farr=E9s <alb...@gm...> wrote:
>=20
> > Hi list
> >
> > I've the owner of an iBook G4. I've been using debian with pbbuttons
> > for a year and everything works perfectly except two things:
> >
> > 1. When pbbutons puts in blankscreen, then, when i want to recover the
> > screen i've to push up or down brigthness key. Before, whith kernel
> > 2.6.9, i just did move the mouse. How can i return to this mode?
>=20
> That are problems with the framebuffer device. Set the option
> UseFBBlank =3D no. This should help.
>=20
Ok, that's the solution!

> > 2. I works with gnome. It use in ts apps F1, F2, .. keys to launch
> > apps like help. When i push, for example, fn+F2, pbbunttons increases
> > the brigthness but gnome launches the help too. How can i do to only
> > increase brigthness?
>=20
> Please check the keycodes you set in pbbuttonsd.conf. The values for
> LCD_IllumUpKey and LCD_IllumDownKey should be set as follows:
>    LCD_IllumUpKey =3D 225
>    LCD_IllumDownKey =3D 224
>=20
My values are correct. What I would want to say was that if there is
some way to prevent gnome launches its apps.

> If you have something else (for example 59 and 60) please change them to
> the above values and your problem should be solved.
>=20
>   Best Regards
>      Matthias
>=20
Thanks a lot

Albert
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> pbbuttons-users mailing list
> pbb...@li...
> https://lists.sourceforge.net/lists/listinfo/pbbuttons-users
>

ERROR: Can't create message port for server: Function not implemented.

[Zeno D. <zd...@gm...>]

Hi

I installed pbbuttonsd 0.7.0 on my PowerBook, with Gentoo and Kernel
2.6.13-rc5 (mm sources).

When I try to start pbbuttonsd I get:
ERROR: Can't create message port for server: Function not implemented.

Any hints?

Thanks for your Feedback.
Zeno

Re: Problems to recover from blankscreen

[Matthias G. <mat...@us...>]

On Wed, 17 Aug 2005 13:41:54 +0200
Albert Farr=E9s <alb...@gm...> wrote:

> Hi list
>=20
> I've the owner of an iBook G4. I've been using debian with pbbuttons
> for a year and everything works perfectly except two things:
>=20
> 1. When pbbutons puts in blankscreen, then, when i want to recover the
> screen i've to push up or down brigthness key. Before, whith kernel
> 2.6.9, i just did move the mouse. How can i return to this mode?

That are problems with the framebuffer device. Set the option
UseFBBlank =3D no. This should help.

> 2. I works with gnome. It use in ts apps F1, F2, .. keys to launch
> apps like help. When i push, for example, fn+F2, pbbunttons increases
> the brigthness but gnome launches the help too. How can i do to only
> increase brigthness?

Please check the keycodes you set in pbbuttonsd.conf. The values for
LCD_IllumUpKey and LCD_IllumDownKey should be set as follows:
   LCD_IllumUpKey =3D 225
   LCD_IllumDownKey =3D 224

If you have something else (for example 59 and 60) please change them to
the above values and your problem should be solved.

  Best Regards
     Matthias

=20

Problems to recover from blankscreen

[<alb...@gm...>]

Hi list

I've the owner of an iBook G4. I've been using debian with pbbuttons
for a year and everything works perfectly except two things:

1. When pbbutons puts in blankscreen, then, when i want to recover the
screen i've to push up or down brigthness key. Before, whith kernel
2.6.9, i just did move the mouse. How can i return to this mode?

2. I works with gnome. It use in ts apps F1, F2, .. keys to launch
apps like help. When i push, for example, fn+F2, pbbunttons increases
the brigthness but gnome launches the help too. How can i do to only
increase brigthness?

I'm usnig now 0.7.1 with kernel 2.6.12, but i had the same problem with 0.6=
.6

Greetings

Albert

Fw: Re: Fitting TPB into PBButtonsd

[Matthias G. <mat...@us...>]

Begin forwarded message:

Date: Sat, 6 Aug 2005 12:37:15 +0200
From: Matthias Grimm <mat...@us...>
To: "Aaron Stone" <aa...@se...>, mar...@kr...
Subject: Re: Fitting TPB into PBButtonsd


On Fri, 5 Aug 2005 00:05:02 -0000
"Aaron Stone" <aa...@se...> wrote:

Hi,
PBButtonsd has a modular design and is prepared to handle more than
Apple Powerbooks. So it should be easy to add some modules to cope with
IBM ThinkPads.

I had a glimpse at TPS's source code and I see tree new modules:
 1. a generic multimedia keys module to start a script on key trigger
 2. a APM module to get battery information from /proc/apm
 3. a ThinkPad specific hardware module

Because I don't have access to a IBM ThinkPad I can't help with the
ThinkPad specific stuff but I would help working on the other modules
and offer generic pbbuttonsd support, if Markus really become fond of
joining his project with pbbuttonsd. I would welcome anyone who wants
to join the team.

> Would anybody mind looking to PBButtonsd to be the one-button-manager
> to-rule-them-all, and placing future development of TPB (after getting it
> all integrated, not sure how easy that'll be at first) within PBButtonsd?

The point with "rule them all" is quite difficult and you won't get
much friends with this theme ;-) Most programmers and users like the
diversity of GNU/Linux software and dislike any monopoly (as I do,
too). The only thing we could do is to convince them using pbbuttonsd
because it has the best performance and most wanted features. To make
pbbuttonsd to such a program you have my full support :-)

> Eventually I'd like to convince jwz to add PBButtonsd support to
> xscreensaver so that the backlight can be adjusted when X is idle (say,
> drop to 1/2 brightness) and when screensavers are running (say, drop to
> min. brightness).

I don't see much sense in using a power consuming screensaver on a
laptop but If you think people likes it please feel free to convince
anyone you like to implement pbbuttonsd support. The package offers a
static library, which makes this task very comfortable.

> PS - I'm good with C and am I'm digging into the code now. But I wanted to
> get the idea out there first, in case anybody else is thinking the same
> thing.

:-) For the generic concept it might be helpful to download the program
documentation on pbbttons.sourceforge.net. I describes the version
0.5.x but the concept haven't changed till today. If you have any
question, feel free to ask.

  Best Regards
     Matthias

Re: Problems with recent versions of pbbutonsd

[Tom C. <tca...@ch...>]

On Tue, Jul 26, 2005 at 07:23:58PM +1000, Erik de Castro Lopo wrote:
> Hi all,
> 
> I've had a G3 based iBook for about three years now. The system
> runs Debain testing and until very recently everything was running
> fine.
> 
> About 2 weeks ago I did an apt-get update/upgrade which installed
> a new version of pbbutonsd and ever since then the machine has 
> hung whenever it comes out of sleep. On the debian-ppc list people
> were suggesting that this was a kernel problem. However, my kernel
> stayed at the same version for a month before the problems began.
> 
> The current version of pbuttonsd is 0.7.0 but I'm not sure what
> the previous version was.

When I upgraded from 0.6.* to 0.7.0 using dpkg, I experienced unusual
problems (sleeping in 20 seconds even though the conf file stated
otherwise...). The problem was due to dpkg not updating
/etc/pbbuttonsd.conf as it was a symbolic link to another file located
under /var.

I resolved all my problems by

apt-get remove --purge pbbuttonsd
rm /etc/pbbuttonsd.conf
apt-get install pbbuttonsd

Everything runs correct now. 

- Tom