pbbuttons, need some help

pbbuttons, need some help

[Matthias Grimm]

Hi everybody,

I wrote the program PBButtons <http://www.cymes.de/members/joker/> and
need your help for a special task.

I would ask for someone who could assist me with debugging some code on
an OHARE-based Powerbook? I teached pbbuttonsd to read battery
information but I could only test the part depending on
PMU_SMART_BATTERY_STATE because I have no OHARE-based Powerbook at hand.
I took the part depending on PMU_BATTERY_STATE from the kernel source
but I would like to verify it again before I release it to the public.

I would also be confident with some valid data sets the PMU returned on
PMU_BATERY_STATE, so I could simulate a OHARE-based Powerbook.

If anyone have some documentation he would be welcome to send me a copy

   Regards
     Matthias Grimm


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

Re: pbbuttons, need some help

[Joseph P. Garcia]

Greetings.

The best way to get battery info now is to use to use /proc/pmu/ in newer
(2.4) kernels.  My gkrellm-pmu plugin used to use adb directly, then PMUD,
now /proc/pmu/.  I had to poke and prod at Paul Mackerras' Batmon to figure
out O'Hare.  But /proc/pmu is transparent to what kind of system its on.
Divide and conquer.  Nice that another conduit thats system independant
exists.

Along those same lines, I have a sugesstion for the gtk client for
pbbuttons.  The program should use the X keycodes rather than associate
with the daemon that controls the hardware.  This serves two purposes: X
handles any client/server mess, and the GUI will be the system independant
figurehead it should be (IMO).  Bastien wrote a similar program that uses
the keycodes, so it could be used on any system with the keys, even an x86.
(hadess.net)

Thanks for working to improve the Linux user expirience. (and anyone else
listening for keeping in touch with such ventures :)

Hope this helps.

--
Joseph P. Garcia    http://www.lycestra.com/    http://lidar.ssec.wisc.edu/
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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

Re: pbbuttons, need some help

[benh]

>The best way to get battery info now is to use to use /proc/pmu/ in newer
>(2.4) kernels.  My gkrellm-pmu plugin used to use adb directly, then PMUD,
>now /proc/pmu/.  I had to poke and prod at Paul Mackerras' Batmon to figure
>out O'Hare.  But /proc/pmu is transparent to what kind of system its on.
>Divide and conquer.  Nice that another conduit thats system independant
>exists.

Note that OHare in /proc/pmu is still known to be flawky as it seems
not all OHare based pbooks need the same formula. But at least it will
be fixed one day and I prefer indeed keeping that tricky code in a
single location. I do have some code to merge one of these days fixing
calculation for the 2400 for example.

>Along those same lines, I have a sugesstion for the gtk client for
>pbbuttons.  The program should use the X keycodes rather than associate
>with the daemon that controls the hardware.  This serves two purposes: X
>handles any client/server mess, and the GUI will be the system independant
>figurehead it should be (IMO).  Bastien wrote a similar program that uses
>the keycodes, so it could be used on any system with the keys, even an x86.
>(hadess.net)

Well, the daemon will still be needed to get the "special" keys on OHare
based powerbooks as I think those don't come via ADB.

>Thanks for working to improve the Linux user expirience. (and anyone else
>listening for keeping in touch with such ventures :)


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

Re: pbbuttons, need some help

[Matthias Grimm]

Joseph P. Garcia wrote:
Hi,

 > The best way to get battery info now is to use to use /proc/pmu/ in newer

> (2.4) kernels.  My gkrellm-pmu plugin used to use adb directly, then PMUD,
> now /proc/pmu/.  I had to poke and prod at Paul Mackerras' Batmon to figure
> out O'Hare.  But /proc/pmu is transparent to what kind of system its on.
> Divide and conquer.  Nice that another conduit thats system independant
> exists.


Yes, you are right. Why do something again what's already done. I looked
into the kernel source, afterwards into PMUD and then I thought that's
the way and other possibilities didn't come into my mind although I knew
/proc/pmu. So I will borrow some code from gkrellm-pmu for that task. ;-)


> Along those same lines, I have a sugesstion for the gtk client for
> pbbuttons.  The program should use the X keycodes rather than associate
> with the daemon that controls the hardware.  This serves two purposes: X
> handles any client/server mess, and the GUI will be the system independant
> figurehead it should be (IMO).  Bastien wrote a similar program that uses
> the keycodes, so it could be used on any system with the keys, even an x86.
> (hadess.net)


I didn't understand excactly what you mean. The GTK client is only a
simple stupid program that will do what it's told from the server. It
hasn't any own input routines except the message queue where the
messages from the server arrive. It doesn't get in contact with any
keycodes, neither from X nor from terminal.

What do you mean with 'client/server mess'? I don't use the X-protokoll
for communication and I don't think it would make much sense. We would
hardly benefit from the X-protokoll because the network transparency
isn't needed here. We only want to make the handling of our machines
more comfortable. Or have I misunderstood you here?


> Hope this helps.


Discussions will always help :-) Who else would turn me arround 180
degrees in a blind alley ;-)

  Matthias


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

Re: pbbuttons, need some help

[Matthias Grimm]

benh@kernel.crashing.org wrote:

Hi,

> Note that OHare in /proc/pmu is still known to be flawky as it seems
> not all OHare based pbooks need the same formula. But at least it will
> be fixed one day and I prefer indeed keeping that tricky code in a
> single location. I do have some code to merge one of these days fixing
> calculation for the 2400 for example.


Yes, I am convinced. I will do it like Jeramy in gkrellm-pmud so I would
benefit from any of your future changes.


> Well, the daemon will still be needed to get the "special" keys on OHare
> based powerbooks as I think those don't come via ADB.


Good point. The PMU has two command regarding the volume and brightness
buttons. Do you have any information about this commands? I think they
are for machines that wouldn't send this keys via the keyboard as you
explained in one of our first emails. Would there be a chance to use
those commands to get the keys also on Powerbooks that don't support the
button device? That would extend the usability of pbbuttons on older
Powerbooks.

   Matthias


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

Re: pbbuttons, need some help

[Tuomas Kuosmanen]

On Thu, 2002-03-07 at 21:41, Joseph P. Garcia wrote:

    Along those same lines, I have a sugesstion for the gtk client for
    pbbuttons.  The program should use the X keycodes rather than associate
    with the daemon that controls the hardware.  This serves two purposes: X
    handles any client/server mess, and the GUI will be the system independant
    figurehead it should be (IMO).  Bastien wrote a similar program that uses
    the keycodes, so it could be used on any system with the keys, even an x86.
    (hadess.net)

Now, I dont know if this is a problem or not but please note that the
"dim the lcd after inactivity" -kind of stuff should not rely on X
screen being active. I mean, if I use MOL for example the keyboard
activity happens on the console - resulting a dimmed display in a moment
if one monitors for X keyboard stuff. Which is rather annoying.

Best,

Tuomas

--
:: :: Tuomas Kuosmanen  :: Art Director, Ximian :: ::
:: :: tigert@ximian.com :: www.ximian.com       :: ::


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

Re: pbbuttons, need some help

[Joseph P. Garcia]

Greetings.

On 09 Mar 2002 16:43:42 +0200
Tuomas Kuosmanen <tigert@ximian.com> wrote:
> Now, I dont know if this is a problem or not but please note that the
....
> if one monitors for X keyboard stuff. Which is rather annoying.

The way I'm suggesting it work is similar to how it does currently, with
one exception.  It would still have a system service (not run as a user) to
listen to the key events and control the hardware.  This maintains that
they keys would work under any environment.  The proposal would also
maintain that the GUI part does nothing but display what happened to tell
the user and nothing more.  That lets the user know what happening or not
on their own choice, and with their own process.

The difference is that rather than the GUI feedback screen using the daemon
to find the event (which thus requires the daemon), it can be triggered off
of the X keyboard events, like Bastien's Acme.  As the button device is
just an additional set of the keyboard keys, the kernel sends an event just
as such.  All keyboard events manifest in the event interface, and, if
linux keycodes are enabled, whereever the system gets its keys as well.
(since all keyboards are also events, this is why /dev/input/event* should
not be world-readable)  This also includes that X gets the key event, and
normally does nothing with it.  X has provisions to associate those keys to
a particular process (or something.  i don't really know) and more or less
have that process sit idle until such an key is pressed.

The point?  Having X handle the event is just like using /proc/pmu/.  It
should work on any system that supports it, regardless of actual hardware.
(i'd like the volume handled generically by the gui too, as it could be...
but people seem against that.  There's always Acme for us types)

However, as Ben pointed out, O'Hare doesn't generate these events yet.  But
I suppose those should go into userspace as well, if possible.  I can help
with that.  (is that an adb mess or a pmu mess?)

Sorry about the lecture.  there just seems to be some misconception of what
I'm proposing.

--
Joseph P. Garcia    http://www.lycestra.com/    http://lidar.ssec.wisc.edu/
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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