Hi Paul!
> Sorry, but this strikes me as a simply *appalling* idea.
Feedback is quite welcome and need not be just positive.
I merely enjoy the patch myself and am willing to share it.
> 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 affirmation
on FAQs that it is not possible.
I am interpreting the following as what _I_ did, not _you_; correct?
> 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.
No! I did not do anything to X.
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_.
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.
> Unfortunately, step 2 is non-trivial (for a bunch of stupid reasons),
> and I could not get any agreement from anyone with XFree86 on how it
> should be done in the mainline X source. But neither step requires any
> kernel hacking.
I tried step 2 too, but did not make it. This solution was the simplest.
And I think it's a useful addition to the kernel. But that may be just me :)
> However, once done, it means that you can use standard console, X and
> X application methods to map the keys to useful commands, instead of a
> new kludge. Note that if you really wanted to do it your way, you
> still could.
It doesn't feel like a kludge to me :)
That's because the kernel already distinguishes `response types' for different
keyboard kinda-keys, for example to treat plain keys, shift/ctrl keys, function
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.
Please let me know if you've looked into the kernel code, and when you've done
so, please let me know if you still think it's a kludge and on what points.
I'm not claiming that it cannot be improved, but at the moment I wouldn't know
how to do it.
Also, please carefuly read the architectural issues on the webpage where I argue
for a solution *in* the kernel, which indeed may seem like an overkill at first
sight, but is quite logical (to me) after second thought.
>From your email I cannot see if this is a first `intuitive' response or based
upon careful study of the proposal. But I hope you'll answer my questions above;
I am surely open to debate!
And, if you have a working alternative outside the kernel, I certainly consider
it worth looking at!
See ya'
-Rick.
-
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:08 EST