On Wed, Jul 12, 2000 at 02:35:25PM +0100, Alan Cox wrote:
> > At present there is no good interface that would allow a user space
> > utility to request part of the keyboard. And I do not know any userspace
> > utilities today that would profit from the possibility.
>
> The funkey driver seems to work quite well and binding it to a simple mixer
> driver and cd player in user space is very nice indeed.
Yes. My memory is bad, so I just looked at it again,
and indeed, /dev/funkey is a possibility.
Looking at the discussion I see that I reacted once already:
: Your /dev/funkey sounds nice, I wouldnt complain if your patch were applied.
: What do you obtain? The possibility to use loadkeys or the underlying
: ioctl to redirect certain keystrokes to a different destination.
: This would make all those people that yearn for DOS hotkeys and TSRs happy.
: But it is only a single destination, so you need a daemon that reads
: /dev/funkey and opens sockets so that everybody who wants to register
: their interest in a few keys can communicate via a socket with the daemon.
: I wonder how much such constructions would be used in practice.
: Maybe if we introduce this we conclude soon afterwards that it does
: not have the right level of generality.
Right now I had precisely the same objections: these keyboards
have CD player buttons, and Power management buttons, and
Browser buttons, etc. With a /dev/funkey one cannot have
the cdplay program open /dev/funkey, one needs a separate funkeyd.
But perhaps that is the right approach.
We were just reminded that there is also traffic in the opposite
direction: keys must be enabled, and LEDs set.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:14 EST