Re: 2.4 - buttons, temperature, ictc

On   Wed, Jul 18, 2001,  Bastien Nocera wrote:

Iain Sandoe wrote:

quoted

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

[snip]

quoted

quoted

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.  [...]
wm, and the code is clean, it should be tolerable.

Better yet for handling the volume would be to get all these keys
recognized by the Linux kernel (these keys don't produce any recognized
keycode on my iMac's Apple Pro kbd), and then by XFree86 so that anybody
can start adding shortcuts for their preferred window manager/desktop
for these keys (that do also exist on x86, btw)

I'd guess that Franz has the ideas of how this will work ... this side is
out of my parish ...

quoted

How does the action end up getting routed to the sound driver?
[...]
(c) the OSS implementation *might* soon be sitting on top of an ALSA driver
talking to a non-onboard sound card (e.g. a pcmcia card) [although this is
not likely in the immediate future on PPC ... it is quite likely soon on x86
laptops]

A pcmcia sound card ?! didn't know that existed.

Yep. there are some "on the stocks" - pro-audio stuff really tho' rather
than SBLive-type things (although those may exist too).

Maybe USB speakers would be a better example (like on the Cube).

yeah. USB audio integration is a headache right now ...

quoted

[...]
I've been toying with the idea of a PMac-specific GUI mixer for a while -
the PMac hardware doesn't map well onto OSS.

- that is, we have several capabilities (and growing with tumbler etc.) that
cannot be reached from the normal OSS interface.

Can you explain ? OSS is indeed not very good for our mixers, maybe your
ideas could be integrated into ALSA before it reaches 1.0 or gets
included in the kernel.

I don't think there's any need to worry about this in ASLA - it already has
the ethic of describing the underlying hardware - no more no less.

The problem is with OSS - where the API embeds an idea of what the hardware
should look like - and that idea is *way* different from how PMac built-in
sound is configured.

I planned on using the OSS "special purpose uncommitted" ioctl() values to
access the PMac-specific stuff and (perhaps) making a GUI mixer that
followed the Apple-type sound manager interface (i.e. reflecting
mutually-exclusive inputs etc. etc.).

This would make dmasound continue to work with the "standard" mixers -
whilst allowing people who wanted a more closely matched interface to use
that.

quoted

Perhaps (at least the sound part) it could be integrated with eSound & aRts
so that coverage would come as part of a standard install?

esound is _dead_. On PPC, it's a piece of junk, and Gnome 2.0 will use
aRts through a C interface.

OK ... I don't (under any circumstances) want to start a desktop/toolkit war
- that was part of my point in making the suggestion.

ciao,
iain.

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