>Feedback is quite welcome and need not be just positive.
Sorry if I was little knee-jerk-ish.
>> The right way
>> to do this already exists (and I did it for XFree 3.3.2, with a
>> Logitech keyboard that has 18 extra keys)
>
>Please refer me to it, I couldn't get it done with XFree, and found
>affirmatio n on FAQs that it is not possible.
I never released it because the XFree folks wouldn't agree to do
something that would have made it work for everyone. I wish I could
remember what. I still have the sources to the hacked X server files
for 3.3.2 if you really want to look at them.
The relationship in Linux between the X server scancode handling and
the kernel is nothing short of totally obfuscated and confused. It
makes it very hard to get new keys to work correctly. I wish they
would do it a different way.
>I am interpreting the following as what _I_ did, not _you_; correct?
No, this is what I did:
>> 1) you use setkeycodes(8) to create kernel-side mappings from the scan
>> codes to new text strings for console-mode apps
>> 2) you fix the X server to handle the new scancodes.
>That's what I like about my solution and why I posted it --- I think the
>function keys should not be handled through the console as regular keys,
>because all sorts of programs then need to interpret it, with X as an
>example. These keys are _different_.
Well, *you* think they are different, and your solution requires them
to be handled in a different way. *I* think that the keys might be
different, or they might not, and I'd rather not require the different
handling at such a deep level. By making them behave like regular
keys, you can use any of the various techniques for keybinding that
exist, including those in X.
>Instead, I tap the codes from /dev/funkey rather than from /dev/console and
>directly start the requested function. Now, there is no need to inform X and
>all kinds of textual apps what it means when I press "play". For instance, if
>"play" was sent out over /dev/console as a string, I might end up instructing
>VI what to do when it is typed, as well as elm, X, bash, and so on. That's
>quite yuk, you'll probably agree.
Well, yes, I agree, but I'd rather see something that didn't *require*
the use of a special notification mechanism. I simply don't agree that
these keys are fundamentally different - I regularly use all 18 of
mine as an extra set of Fn keys in Emacs, for example.
Furthermore, the solution you're describing doesn't work where an
existing application has control of the required h/w resources. How
would you change the volume on a device that has exclusive access and
already has a process with it open ?
I agree, however, that there is a difficult situation on the
console. I need to ruminate on this a bit more.
>That's because the kernel already distinguishes `response types' for different
>keyboard kinda-keys, for example to treat plain keys, shift/ctrl keys, functio
>n
>keys differently. There's also SysRq, which crosses through the code structure
>of the kernel; that I call a kludge. I merely appended to a list of `reponse
>types' for the keyboard handling.
I don't believe it treats any of the keys differently in terms of
their presentation to user-space, except for ones that it traps
itself. You're suggesting trapping a new set of keys - the existing
kernel traps just a few. I would prefer a solution that doesn't add a
whole bunch of keys to the "special cases".
One thing that is in your favor is that, because of setkeycodes(8),
the mapping you're talking about is really completely independent of
the actual physical keys that get pressed. I could use setkeycodes to
make my numeric keys act like the "new" function keys, for example.
>Also, please carefuly read the architectural issues on the webpage where I arg
>ue
>for a solution *in* the kernel, which indeed may seem like an overkill at firs
>t
>sight, but is quite logical (to me) after second thought.
I'll take a look this week.
>And, if you have a working alternative outside the kernel, I
>certainly conside r it worth looking at!
Well, as I said, I did get all 18 new keys on my logitech working as
function keys under X. But then I upgrade to 3.3.6, and have just done
without them ever since. I tend to not really care these days, except
on "theoretical" grounds that Linux should be able to handle them.
--p
-
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 : Sun Apr 23 2000 - 21:00:09 EST