2.4 - buttons, temperature, ictc

mostly a rehash of patches from the past, and mostly not mine originally, attached is a patch.gz against the latest BenH 2.4 kernel.  It adds support for:
- repeating brightness buttons
- volume buttons (using kernel space volume control interface)  supported sound cards only (screamer, burgundy?)
- temperature support for my wallstreet 750CX, which doesn't use TAU. (not sure what CPUs support this coding.  no checks yet)
- ICTC proc support  (I still have this in my kernel.  might use it one day)
- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)

I'm willing to help see some of these get into a public tree.  BenH showed interest in the repeating and volume buttons, but with the noted exception of providing user space an interface to use them.  This coding has a broken new input layer volume key support, which if completed, and supported by a daemon, could lighten the code bulk extensively. (links between adbhid - pmacfeatures - dmasound[module] aren't pretty)

figured now was a good time to remind people these things still exist.

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

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

- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)

Why is it necessary to hardcode this address? It may clash with another device.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

On Tue, 17 Jul 2001 09:18:53 +0200 (CEST)
Geert Uytterhoeven [off-list ref] wrote:

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

quoted

- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)

Why is it necessary to hardcode this address? It may clash with another device.

Truth told, it isn't necessary anymore.  All this does is put the video control memory on wallstreets (it checks) at 0x830-- rather than 0x800--, which is where the current kernel puts it iirc.  A leftover from the days of the OF-caused ATY memory overlap.  Now, this mostly just makes /proc/iomem look cleaner.  nothing more.

That segment (the whole pmac_pci.c section of the patch) does only that, and can be ignored.  Don't know why i posted that part to tell the truth.

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

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

At 07:45 17.07.2001, Joseph P. Garcia wrote:

mostly a rehash of patches from the past, and mostly not mine originally,
attached is a patch.gz against the latest BenH 2.4 kernel.  It adds
support for:
- repeating brightness buttons
- volume buttons (using kernel space volume control interface)  supported
sound cards only (screamer, burgundy?)
- temperature support for my wallstreet 750CX, which doesn't use TAU. (not
sure what CPUs support this coding.  no checks yet)
- ICTC proc support  (I still have this in my kernel.  might use it one day)
- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure
if 0x800-- is best or not.  ignore if you like.)

I'm willing to help see some of these get into a public tree.  BenH showed
interest in the repeating and volume buttons, but with the noted exception
of providing user space an interface to use them.  This coding has a
broken new input layer volume key support, which if completed, and
supported by a daemon, could lighten the code bulk extensively. (links
between adbhid - pmacfeatures - dmasound[module] aren't pretty)

figured now was a good time to remind people these things still exist.

I object to putting anything you marked with CONFIG_PMAC_VOLUME into the
kernel, it's worse enough we have CONFIG_PMAC_BACKLIGHT in there. I'll
merge your "input_report_key" into my 2.5 adbhid.c source though, thx.

With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
to use the event devices then, so you better start using them _now_. Taking
kernel bloating shortcuts is not the way to go IMHO.

Franz.


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

I object to putting anything you marked with CONFIG_PMAC_VOLUME into the
kernel, it's worse enough we have CONFIG_PMAC_BACKLIGHT in there. I'll
merge your "input_report_key" into my 2.5 adbhid.c source though, thx.

With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
to use the event devices then, so you better start using them _now_. Taking
kernel bloating shortcuts is not the way to go IMHO.

Right, all this belongs to userland. I might include part of this
patch in 2.4 so we have the feature working now, but for 2.5, I'd
rather use the event devices for both backlight and volume, and
have pmud handle them.

Ben.


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

quoted

With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
to use the event devices then, so you better start using them _now_. Taking
kernel bloating shortcuts is not the way to go IMHO.

Right, all this belongs to userland. I might include part of this
patch in 2.4 so we have the feature working now, but for 2.5, I'd
rather use the event devices for both backlight and volume, and
have pmud handle them.

Why pmud? For backlight I kind of see how you'd get that notion. But
volume?

I admit to zero knowledge about the event device stuff but if it's
anything like register_event(fd, handler, event_code) or select instead of
having a hander registered I'd rather have some sort of event daemon
handle all this. That way, users could even customize the thing to get
particular functions mapped to keys :-)

	Michael


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

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

Why pmud? For backlight I kind of see how you'd get that notion. But
volume?

...

handle all this. That way, users could even customize the thing to get
particular functions mapped to keys :-)

I agree.  At least at the moment, there are measures to have volume controls in the new input layer.  Else, why would there be macros in input.h for them.  Assuming that this is generally preferred direction, it would require a shell- or X-based handler.  I'm sure that if keycodes are set up properly, you could have Sawfish or Enlightenment capture the key stroke and use it like macos with the volume bar appear at the bottom (if you want that sort of thing).  In console, it would be different.  But taken as stated, this starts to put bloat wherever it goes.  Having a window manager call aumix isn't very linux like, but I'd argue that its the kind of result you would get in a nice integrated environment like kde or gnome would like to attain.  if the user doesn't realize its part of the wm, and the code is clean, it should be tolerable.

So the question is, should I pursue a NIL approach and maybe others with similar keys will follow, or come up with another api using events (and basically deprecate three of many of the unused NIL keys for our own purpose).  I'd prefer following the NIL approach, but coming up with a good method to handle these without bloating, say,  bash and sawfish at the same time.

Suggestions on non-cascading methods of NIL support?  are mingetty and X the best places to aim for without changing everything, or is there better?  are these even supposed to know what the NIL is?  Or is a daemon really the way to go?

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

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