All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Brabec <utx@penguin.cz>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [patch commit request] kdrive xserver:	support	for	key codes 128-255
Date: Sun, 10 Feb 2008 22:33:47 +0100	[thread overview]
Message-ID: <20080210223347.7a151067@zaurus.lan> (raw)
In-Reply-To: <47ADA3F2.1000500@gmail.com>

On Sat, 09 Feb 2008 07:00:34 -0600 Junqian Gordon Xu wrote:

> On 02/03/2008 03:57 PM, Stanislav Brabec wrote:

> > It adds support for key codes 128-255 in general.
> 
> I understand this patch is general. But could you educate me that
> except for the Z clamshells, what's the use case for other devices? I
> guess my question is more in line with Paul's challenge. Is this
> patch just a why-not for other devices or something might be helpful?

Many devices have special keys with (input.h) keycodes outside 1-127
(e. g. Mail - KEY_MAIL).

Now you have to map them to a random keys from range 1-127, otherwise
it will not work. In particular it invalidates key interpretation in
the kernel - kernel knows, that the key is Mail and not F11 but it has
to send KEY_F11, because KEY_MAIL is lost.

Even after this patch the situation will not be ideal - for example
KEY_OK has keycode 352 and cannot pass through X11 protocol. That is
why it is only a partial solution. Final solution could be: upgrade to
X12 (rewrite X and give up 20 years of compatibility; in proposal
collection stage) or at least write X Evdev Extension and Xlib keyboard
code rewrite (simpler to implement, but not yet started to work on).

The opinion of kernel people: We have a good and modern keyboard
layer, which can provide exact key meaning. We don't want to be limited
to 1-127 and mangle our keycodes. Let userspace fix their broken
drivers.

And hardware manufacturers don't make things easier. Many USB keyboards
identify themselves as devices including keys defined in the HID
standard (it allows them to recycle the same chip).

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus



  parent reply	other threads:[~2008-02-10 21:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 18:19 [patch commit request] kdrive xserver: support for key codes 128-255 Stanislav Brabec
2008-01-30  1:38 ` Junqian Gordon Xu
2008-01-30 10:45 ` Paul Sokolovsky
2008-01-30 12:13   ` Stanislav Brabec
2008-02-01  8:02     ` Junqian Gordon Xu
2008-02-03 21:57       ` Stanislav Brabec
2008-02-04  1:12         ` Dmitry Baryshkov
2008-02-04 11:05           ` Stanislav Brabec
2008-02-09 13:00         ` Junqian Gordon Xu
2008-02-09 13:40           ` Paul Sokolovsky
2008-02-10 21:33           ` Stanislav Brabec [this message]
2008-02-01  7:03 ` Junqian Gordon Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080210223347.7a151067@zaurus.lan \
    --to=utx@penguin.cz \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.