From: Vojtech Pavlik <vojtech@suse.cz>
To: Andries.Brouwer@cwi.nl
Cc: aebr@win.tue.nl, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6 input drivers FAQ
Date: Mon, 2 Feb 2004 13:25:10 +0100 [thread overview]
Message-ID: <20040202122510.GA1265@ucw.cz> (raw)
In-Reply-To: <UTC200402021134.i12BY0601230.aeb@smtp.cwi.nl>
On Mon, Feb 02, 2004 at 12:34:00PM +0100, Andries.Brouwer@cwi.nl wrote:
> > Well, I think it's a bad idea to have the userspace tool know about the
> > e0 thing at all. It should be just opaque numbers to it.
>
> But how is the user to invent these opaque numbers?
> She uses showkey -s to see what scancodes a key produces,
> and then setkeycodes to assign a keycode to them.
That's another problem. showkey -s will show nothing if the keys don't
work in 2.6, and nothing useful for setkeycodes usage if they do.
I'm planning to add a new event type to report the raw scancodes through
the event interface, though I'm still yet not decided about how exactly
to do it and whether to use this to do real raw mode instead of the
simulated one where possible. I don't think the later is a good idea.
> > I don't have a problem with swapping the set3 table, if setkeycodes
> > works reasonably now for scancodes above 128.
>
> Above 128, yes. Above 256, no.
> The interface is a char - 8 bits only.
Even for scancodes? Well, in that case I'll have to keep the kludge as
it is. Or have setkeycodes use EVIOCSKEYCODE.
> (So, right now, NR_KEYS > 256 is not useful.)
--
Vojtech Pavlik
SuSE Labs, SuSE CR
next prev parent reply other threads:[~2004-02-02 12:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-02 11:34 2.6 input drivers FAQ Andries.Brouwer
2004-02-02 12:25 ` Vojtech Pavlik [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-02-02 12:44 Andries.Brouwer
2004-02-02 12:56 ` Vojtech Pavlik
2004-02-01 10:06 Vojtech Pavlik
2004-02-01 13:15 ` Andries Brouwer
2004-02-01 13:50 ` Vojtech Pavlik
2004-02-01 15:14 ` Andries Brouwer
2004-02-02 9:35 ` Vojtech Pavlik
2004-02-02 9:43 ` Vojtech Pavlik
2004-02-01 13:51 ` Marcel J.E. Mol
2004-02-01 15:18 ` Andries Brouwer
2004-02-01 15:25 ` Andreas Jellinghaus
2004-02-01 15:56 ` Peter Osterlund
2004-02-01 16:58 ` Andreas Jellinghaus
2004-02-01 21:54 ` Vojtech Pavlik
2004-02-01 16:31 ` Joshua Kwan
2004-02-01 18:23 ` Gene Heskett
2004-02-02 16:45 ` Valdis.Kletnieks
2004-02-02 5:27 ` Valdis.Kletnieks
2004-02-02 9:23 ` Vojtech Pavlik
2004-02-02 18:12 ` Valdis.Kletnieks
2004-02-02 20:18 ` Vojtech Pavlik
2004-02-02 20:24 ` Joshua Kwan
2004-02-02 21:16 ` Vojtech Pavlik
2004-02-02 20:28 ` Valdis.Kletnieks
2004-02-02 21:19 ` Vojtech Pavlik
2004-02-02 9:24 ` Vojtech Pavlik
2004-02-02 9:29 ` Joshua Kwan
2004-02-02 17:50 ` Jesse Barnes
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=20040202122510.GA1265@ucw.cz \
--to=vojtech@suse.cz \
--cc=Andries.Brouwer@cwi.nl \
--cc=aebr@win.tue.nl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox