I'm pretty much convinced it's a kernel bug. Firstly, to follow your logic:
> gnome-volume-control gives warnings: > > ** (gnome-volume-control:5579): WARNING **: Error getting device (7) volume: > Operation not permitted > > ** (gnome-volume-control:5579): WARNING **: Error getting recording device > (7) volume: Operation not permitted > > but works without any problem. So, this is not a bug in the kernel. tkmixer works on all kernels except some versions of powerpc, so this is not a bug in tkmixer, right? But the real reasons why I think it's a kernel bug are below. 1. The ioctl which returns EPERM is a request to get the value of mixer control no. 7 (Microphone). Previous three similar ioctls for controls 0 (Master volume), 5 (Speaker) and 6 (Line) have all succeeded, as shown by strace. I see no logic in that reading some mixer elements is permitted and reading others is not. 2. Permission checks are usually done at device openinig time, not at ioctl time. 3. EPERM's code is 1, which means that the mixer ioctl handler in the kernel returns -1, which is then translated to an error condition with errno = -(-1) = 1 = EPERM. I think that -1 is returned by mistake; if EPERM had a different error code, the code returned would still be 1, and not EPERM's. Of course, I could equip tkxmier with a workaround similar to the one in gnome-volume-control, or forgo error checking altogether, like most other mixers that "work" on powerpc do, and let the real bug go unnoticed. But before that, I'd still like to bounce this off PowerPC kernel/sound driver developers, or even look into this myself if you give me precise details about the kernel and platform: driver type (OSS or ALSA), sound device (AWACS/Burgundy/etc.), kernel configuration, gcc version, and the kernel-image package used (I couldn't find kernel-image-2.6.9-powerpc in Debian archive). It might even be a result of miscompilation by gcc. Nikita -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
