* [PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports
@ 2004-05-07 20:55 Tuukka Toivonen
2004-05-08 2:35 ` Andrew Morton
0 siblings, 1 reply; 80+ messages in thread
From: Tuukka Toivonen @ 2004-05-07 20:55 UTC (permalink / raw)
To: linux-kernel; +Cc: danlee, b-gruber, Mikael Hakali
Download:
wget http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
This is the first public release of the patch, but it has been already
tested by a few people, so it should be stable.
I hope to get some more testers, and if no serious bugs are found, I really
would like this to get included into the mainstream kernel.
Snippet from the documentation:
SERIO_USERDEV - Direct serial input device access for userspace
This driver provides direct access from usespace into PS/2 (or psaux)
serial ports used usually for input devices such as mouses and keyboards.
The code is part of the serio module. It can be enabled or disabled
from kernel configuration
Device Drivers -> Input device support -> User space driver support
if serial i/o support is enabled.
All available devices will be registered as miscellaneous
devices with major 10, minor dynamically allocated. The devices
with their minors will be listed in /proc/misc with isa0060/serio0
for keyboard and the rest for pointing devices. If devfs is enabled,
the device files will be created as /dev/misc/isa0060/serio*.
The created devices which are connected to a mouse can be usually
used in place of /dev/psaux which was used in 2.4.x kernels.
Therefore, you could do (if devfs is enabled):
ln -s /dev/misc/isa0060/serio1 /dev/psaux
(or some other device) and run mouse drivers such as gpm and XFree86
just as with 2.4.x kernel.
Features:
- Both read and write support to all PS/2 ports. With active multiplexing,
there will be five serial ports up to isa0060/serio4.
- Multiple readers supported, each reader will get copy of the complete stream.
Write locking supported via special ioctl calls.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports
2004-05-07 20:55 [PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports Tuukka Toivonen
@ 2004-05-08 2:35 ` Andrew Morton
2004-05-25 20:16 ` keyboard problem with 2.6.6 Chris Osicki
0 siblings, 1 reply; 80+ messages in thread
From: Andrew Morton @ 2004-05-08 2:35 UTC (permalink / raw)
To: Tuukka Toivonen; +Cc: linux-kernel, danlee, b-gruber, mhakali, Vojtech Pavlik
Tuukka Toivonen <tuukkat@ee.oulu.fi> wrote:
>
> SERIO_USERDEV - Direct serial input device access for userspace
>
> This driver provides direct access from usespace into PS/2 (or psaux)
> serial ports used usually for input devices such as mouses and keyboards.
I must say that last time this went around, the arguments which were made
in its favour made sense. Let me recap:
At present, the kernel decodes the external device into logical "events"
and, if someone wants access to the raw device bitstream the kernel will
synthesize that bitstream from the decoded event stream.
But if, for example, the kernel doesn't have a decoder for the external
device, we're out of luck.
And given that the external device generates a stream of bits, the kernel
should provide some way for applications to directly access that stream
without the intervening interpretation.
Is that a decent summary of the situation?
If so then yeah, I think the kernel should have a driver which does all of
this.
^ permalink raw reply [flat|nested] 80+ messages in thread
* keyboard problem with 2.6.6
@ 2004-05-25 20:16 ` Chris Osicki
2004-05-26 7:54 ` Sau Dan Lee
2004-05-28 19:41 ` keyboard problem with 2.6.6 Andries Brouwer
0 siblings, 2 replies; 80+ messages in thread
From: Chris Osicki @ 2004-05-25 20:16 UTC (permalink / raw)
To: linux-kernel
Hi
I recently moved to kernel 2.6.6 from 2.4.26 and noticed that four keys
on my keyboard stopped working.
The kernel reports:
keyboard: unrecognized scancode (XX) - ignored
Where XX is 71, 72, 74, 75.
My setup is quite unusual as I'm using Sun type 5 keyboard on my
PC with a self-made adapter. However, this setup has worked for at
least six years with different kernel versions.
The four keys which don't work anymore are from the function-key-set
on the left hand side of the keyboard, if you know what a Sun
keyboard looks like.
I tried to solve my problem using setkeycodes and tried:
setkeycodes 71 101
as 101 was unused keycode (according to getkeycodes)
getkeycodes reported after that:
# getkeycodes | grep 0x70
0x70: 93 101 0 89 0 0 85 91
But showkeys -s shows 0x5b when the key in question is pressed
(and no release event!!??)
Which is what I don't understand but what probably is out of the scope
of this list.
Under XFree86 this key is then keycode 99 and keysym ff55 which
confuses me totally, but the question "why" belongs probably not to
this list either.
All mentioned keyboard related programs come from the latest
kbd-package - kbd-1.12.
I would be very thankful if somebody could help me to understand
what's going on and how can I get my keys working again.
There must be a good reason for the change from 2.4.x to 2.6.x
which escapes me.
Thanks for your time.
Regards,
Chris
PS Please Cc: me if possible
--
Chris Osicki osk@osk.ch
Dipl. Informatik-Ing. HTL
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-25 20:16 ` keyboard problem with 2.6.6 Chris Osicki
@ 2004-05-26 7:54 ` Sau Dan Lee
2004-05-28 13:33 ` Giuseppe Bilotta
` (6 more replies)
2004-05-28 19:41 ` keyboard problem with 2.6.6 Andries Brouwer
1 sibling, 7 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-26 7:54 UTC (permalink / raw)
To: Chris Osicki; +Cc: linux-kernel
>>>>> "Chris" == Chris Osicki <osk@osk.ch> writes:
Chris> Hi
Chris> I recently moved to kernel 2.6.6 from 2.4.26 and noticed
Chris> that four keys on my keyboard stopped working.
Congratulations, you've hit the most annoying (IMO) part of the new
'features' in 2.6.6: the new input subsystem.
Chris> The kernel reports:
Chris> keyboard: unrecognized scancode (XX) - ignored
Chris> Where XX is 71, 72, 74, 75.
They have rewritten the kernel keyboard and mouse drivers, causing
lots of problems to people who switch from 2.4. What's worse: there
is no way back. No backward-compatibility to 2.4 behaviours have been
provided, because some kernel developers believe the new input system
is "perfect", so perfect that no one would want the old behaviours
anymore.
See also: http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/
Chris> I tried to solve my problem using setkeycodes and tried:
Chris> setkeycodes 71 101
Chris> as 101 was unused keycode (according to getkeycodes)
I don't think you should invent your own keycodes, given that the
following appears in linux-2.6.*/include/linux/input.h
#define KEY_STOP 128
#define KEY_AGAIN 129
#define KEY_PROPS 130
#define KEY_UNDO 131
#define KEY_FRONT 132
#define KEY_COPY 133
#define KEY_OPEN 134
#define KEY_PASTE 135
#define KEY_FIND 136
#define KEY_CUT 137
#define KEY_HELP 138
#define KEY_MENU 139
#define KEY_CALC 140
I'm not sure if the configs of XFree86 need any further adjustments.
Chris> I would be very thankful if somebody could help me to
Chris> understand what's going on
The keyboard driver has changed, and hence the behaviour.
It also affects my notebook: The SysRq key activated by some [Fn]- key
combo does not work anymore. It DID work in 2.4. On 2.6, I have to
use Alt-PrintScreen instead. The atkbd keyboard driver seems to
assume that SysRq == Alt-PrintScreen in all cases, which is simply
wrong!
Chris> and how can I get my keys working again.
Lobby the input system developers, emphasizing that COMPATIBILITY with
2.4 behaviours is desired and important. Without a smooth transition
path, people will be reluctant to migrate to 2.6.
Chris> There must be a good reason for the change from 2.4.x to
Chris> 2.6.x which escapes me.
Yeah. They say the input system "unifies" the interface to
keyboard/mouse devices. They're also proud that the in-kernel
keyboard/mouse drivers are supporting more and more devices. But at
the same time, they're sacrificing flexibility by moving many codes
into kernel. (GPM supports more mouse types!) The new system also
breaks backward compatibility.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-26 7:54 ` Sau Dan Lee
@ 2004-05-28 13:33 ` Giuseppe Bilotta
2004-05-28 17:37 ` Sau Dan Lee
` (5 subsequent siblings)
6 siblings, 0 replies; 80+ messages in thread
From: Giuseppe Bilotta @ 2004-05-28 13:33 UTC (permalink / raw)
To: linux-kernel
Sau Dan Lee wrote:
> Yeah. They say the input system "unifies" the interface to
> keyboard/mouse devices. They're also proud that the in-kernel
> keyboard/mouse drivers are supporting more and more devices. But at
> the same time, they're sacrificing flexibility by moving many codes
> into kernel. (GPM supports more mouse types!) The new system also
> breaks backward compatibility.
The new system has some ups and downs. The biggest "down",
which is that of RAW mode not being available anymore (it's
emulated!) could be circumvented by having both the RAW and
translated codes move between layers.
Concerning GPM vs kernel support for mice, maybe we can hope
for a merging of the efforts and a reduction of code
duplication, if there is any?
Overall, I think that the new system *could* be a good starting
point, but it still needs a *lot* of work.
(Now, if we could have any reply from the maintainers?)
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-05-28 13:59 Tuukka Toivonen
2004-05-29 13:14 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Tuukka Toivonen @ 2004-05-28 13:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: linux-kernel
Giuseppe Bilotta wrote:
>The new system has some ups and downs. The biggest "down",
>which is that of RAW mode not being available anymore (it's
>emulated!) could be circumvented by having both the RAW and
>translated codes move between layers.
Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
mode? To me this sounds like a big incompatibility. Fortunately this patch
(written together with Sau Dan Lee) should give _really_ raw mode in 2.6.x
too (but it's not compatible with the raw mode in 2.4.x):
http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-26 7:54 ` Sau Dan Lee
2004-05-28 13:33 ` Giuseppe Bilotta
@ 2004-05-28 17:37 ` Sau Dan Lee
2004-05-29 13:12 ` Vojtech Pavlik
2004-05-28 19:39 ` 2.6.* useland replacements of the atkbd and psmouse modules Sau Dan Lee
` (4 subsequent siblings)
6 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-28 17:37 UTC (permalink / raw)
To: Giuseppe Bilotta, linux-kernel; +Cc: Tuukka Toivonen
>>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
Giuseppe> Concerning GPM vs kernel support for mice, maybe we can
Giuseppe> hope for a merging of the efforts and a reduction of
Giuseppe> code duplication, if there is any?
I'm trying to port the kernel's psmouse.c to userspace, exploiting the
SERIO_USERDEV patch that Tuukka Toivonen and I developed. That patch
provided a direct path from the PC keyboard and PS2 mouse port to
userspace programs. I've been using it so as to use my legacy XFree86
driver for my touch screen for many weeks.
I've just had some success porting atkbd.c to userspace. Running this
userspace program and unloading the 'atkbd' module, I can type as
usual. It works like this:
userland atkbd.c --------+ apps
^ | ^
|3 |4 |7
module 'serio' with | |
SERIO_USERDEV v {input system}
^ uinput |
|2 | |
module 'i8042' |5 |6
^ | |
| | |
virtual device | +---> "AT keyboard"
|1
|
hardware i8042 chip
Data abstraction:
(1) electronic signals
(2), (3) byte stream
(4), (5), (6), (7) a stream of struct input_event
By moving the translation from byte-stream to input events, we have
more flexibilities. E.g., I've imagined using SSH to pipe (3) to
another machine, where my atkbd.c userland program can then continue
converting to (4) and feeding that to the *remote* system. This means
it's possible to Alt-F1, SysRq-*, ctrl-alt-delete from a REMOTE
machine! It's also possible to replace atkbd.c above with an X11
client that gives a virtual keyboard. Again, this can be exploited to
do remote controlling.
Right now, my atkbd.c doesn't hand the LEDs. I get stuck with a bug
with 'uinput', which oops upon select() and poll(), which is
necessary. I've posted this bug, which has been entered into buzilla
as bug #2786.
http://bugzilla.kernel.org/show_bug.cgi?id=2786
As soon as this bug is fixed, the userland atkbd.c can be made to
support the keyboard LEDs.
Giuseppe> Overall, I think that the new system *could* be a good
Giuseppe> starting point, but it still needs a *lot* of work.
I also agree the new system has its merits. What I hate is only the
part where mouse/keyboard drivers are now in kernel space. The
translation of raw byte streams into input events should be better
done in userland. One important argument is: userland program may be
swapped out. Kernel modules can't.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* 2.6.* useland replacements of the atkbd and psmouse modules
2004-05-26 7:54 ` Sau Dan Lee
2004-05-28 13:33 ` Giuseppe Bilotta
2004-05-28 17:37 ` Sau Dan Lee
@ 2004-05-28 19:39 ` Sau Dan Lee
2004-05-28 19:57 ` keyboard problem with 2.6.6 Andries Brouwer
` (3 subsequent siblings)
6 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-28 19:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Tuukka Toivonen, Giuseppe Bilotta, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/#userdrivers
These userspace drivers are ported from kernel code based on 2.6.6.
They are still in alpha stage. Some "difficult features" (or code
that I don't understand) are dropped.
However, they do demonstrate that using the SERIO_USERDEV patch (see
message <Pine.GSO.4.58.0405072348120.21057@stekt37>, available at
http://lkml.org/lkml/2004/5/7/143), it is really possible to implement
the PS2 mouse/keyboard drivers in user space.
[-- Attachment #2: atkbd.c --]
[-- Type: text/plain, Size: 24576 bytes --]
/*
* AT and PS/2 keyboard driver
*
* Copyright (c) 1999-2002 Vojtech Pavlik
* Copyright (c) 2004 Sau Dan LEE
*/
/*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
/*
This program is based on linux-2.6.6/drivers/input/serio/atkbd.c
The difference is that this program now runs in user-space (swappable),
while the kernel driver runs in kernel-space.
Usage: atkbd /dev/misc/isa0060/serio0
Prerequisites:
1) 'uinput' module loaded or compiled in
If not using 'devfs', you have to create the /dev/uinput char
device with major 10. The minor number can be found in
"cat /proc/misc" after loading the 'uinput' module.
2) 'serio' module with SERIO_USERDEV patch loaded or compiled in
3) 'i8042' module loaded or compiled in
4) 'atkbd' module UNloaded and NOT compiled in
Note: if you're accessing from console, keyboard will be disabled
when 'atkbd' is unloaded. It's more convenient to connect from
remote to do this. Alternatively, write some shell scripts
to invoke unload 'atkbd' and activate this program at once.
TODO:
- this program current ignore LED events -- BUG
- options parsing should be added to allow user to
specify the module parameters.
- daemonize this program, so as to make it easy to run from /etc/inittab
- soft_repeat is not supported yet. (How useful is this?)
*/
/*
* This driver can handle standard AT keyboards and PS/2 keyboards in
* Translated and Raw Set 2 and Set 3, as well as AT keyboards on dumb
* input-only controllers and AT keyboards connected over a one way RS232
* converter.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/input.h>
#include <linux/uinput.h>
/* older kernel headers lack the following two key codes */
#ifndef KEY_HANGUEL
#define KEY_HANGUEL 122
#endif
#ifndef KEY_HANJA
#define KEY_HANJA 123
#endif
#define module_param_named(name,var,type,defl) struct dummy
#define MODULE_PARM_DESC(name,desc) struct dummy
#define warn(...) fprintf(stderr, "atkbd: (warning) " __VA_ARGS__)
#define err(...) fprintf(stderr, "atkbd: ERROR " __VA_ARGS__)
#define info(...) printf("atkbd: " __VA_ARGS__)
#define perr(msg) do{fprintf(stderr, "atkbd: ERROR: "); perror(msg);}while(0)
#define perrx(msg) do{perr(msg); exit(1);}while(0)
#define pferrx() perrx(__FUNCTION__)
static int atkbd_set = 2;
module_param_named(set, atkbd_set, int, 0);
MODULE_PARM_DESC(set, "Select keyboard code set (2 = default, 3 = PS/2 native)");
#if defined(__i386__) || defined(__x86_64__) || defined(__hppa__)
static int atkbd_reset;
#else
static int atkbd_reset = 1;
#endif
module_param_named(reset, atkbd_reset, bool, 0);
MODULE_PARM_DESC(reset, "Reset keyboard during initialization");
static int atkbd_softrepeat;
module_param_named(softrepeat, atkbd_softrepeat, bool, 0);
MODULE_PARM_DESC(softrepeat, "Use software keyboard repeat");
static int atkbd_scroll;
module_param_named(scroll, atkbd_scroll, bool, 0);
MODULE_PARM_DESC(scroll, "Enable scroll-wheel on MS Office and similar keyboards");
static int atkbd_extra;
module_param_named(extra, atkbd_extra, bool, 0);
MODULE_PARM_DESC(extra, "Enable extra LEDs and keys on IBM RapidAcces, EzKey and similar keyboards");
/*
* Scancode to keycode tables. These are just the default setting, and
* are loadable via an userland utility.
*/
#if defined(__hppa__)
#include "hpps2atkbd.h"
#else
static unsigned char atkbd_set2_keycode[512] = {
0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117,
0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0,
0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183,
0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185,
0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0,
0, 89, 40, 0, 26, 13, 0, 0, 58, 54, 28, 27, 0, 43, 0, 85,
0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0,
82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
217,100,255, 0, 97,165, 0, 0,156, 0, 0, 0, 0, 0, 0,125,
173,114, 0,113, 0, 0, 0,126,128, 0, 0,140, 0, 0, 0,127,
159, 0,115, 0,164, 0, 0,116,158, 0,150,166, 0, 0, 0,142,
157, 0, 0, 0, 0, 0, 0, 0,155, 0, 98, 0, 0,163, 0, 0,
226, 0, 0, 0, 0, 0, 0, 0, 0,255, 96, 0, 0, 0,143, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0,107, 0,105,102, 0, 0,112,
110,111,108,112,106,103, 0,119, 0,118,109, 0, 99,104,119, 0,
0, 0, 0, 65, 99,
};
static unsigned char atkbd_set3_keycode[512] = {
0, 0, 0, 0, 0, 0, 0, 59, 1,138,128,129,130, 15, 41, 60,
131, 29, 42, 86, 58, 16, 2, 61,133, 56, 44, 31, 30, 17, 3, 62,
134, 46, 45, 32, 18, 5, 4, 63,135, 57, 47, 33, 20, 19, 6, 64,
136, 49, 48, 35, 34, 21, 7, 65,137,100, 50, 36, 22, 8, 9, 66,
125, 51, 37, 23, 24, 11, 10, 67,126, 52, 53, 38, 39, 25, 12, 68,
113,114, 40, 43, 26, 13, 87, 99, 97, 54, 28, 27, 43, 43, 88, 70,
108,105,119,103,111,107, 14,110, 0, 79,106, 75, 71,109,102,104,
82, 83, 80, 76, 77, 72, 69, 98, 0, 96, 81, 0, 78, 73, 55,183,
184,185,186,187, 74, 94, 92, 93, 0, 0, 0,125,126,127,112, 0,
0,139,150,163,165,115,152,150,166,140,160,154,113,114,167,168,
148,149,147,140
};
static unsigned char atkbd_unxlate_table[128] = {
0,118, 22, 30, 38, 37, 46, 54, 61, 62, 70, 69, 78, 85,102, 13,
21, 29, 36, 45, 44, 53, 60, 67, 68, 77, 84, 91, 90, 20, 28, 27,
35, 43, 52, 51, 59, 66, 75, 76, 82, 14, 18, 93, 26, 34, 33, 42,
50, 49, 58, 65, 73, 74, 89,124, 17, 41, 88, 5, 6, 4, 12, 3,
11, 2, 10, 1, 9,119,126,108,117,125,123,107,115,116,121,105,
114,122,112,113,127, 96, 97,120, 7, 15, 23, 31, 39, 47, 55, 63,
71, 79, 86, 94, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 87,111,
19, 25, 57, 81, 83, 92, 95, 98, 99,100,101,103,104,106,109,110
};
#define ATKBD_CMD_SETLEDS 0x10ed
#define ATKBD_CMD_GSCANSET 0x11f0
#define ATKBD_CMD_SSCANSET 0x10f0
#define ATKBD_CMD_GETID 0x02f2
#define ATKBD_CMD_SETREP 0x10f3
#define ATKBD_CMD_ENABLE 0x00f4
#define ATKBD_CMD_RESET_DIS 0x00f5
#define ATKBD_CMD_SETALL_MBR 0x00fa
#define ATKBD_CMD_RESET_BAT 0x02ff
#define ATKBD_CMD_RESEND 0x00fe
#define ATKBD_CMD_EX_ENABLE 0x10ea
#define ATKBD_CMD_EX_SETLEDS 0x20eb
#define ATKBD_CMD_OK_GETID 0x02e8
#define ATKBD_RET_ACK 0xfa
#define ATKBD_RET_NAK 0xfe
#define ATKBD_RET_BAT 0xaa
#define ATKBD_RET_EMUL0 0xe0
#define ATKBD_RET_EMUL1 0xe1
#define ATKBD_RET_RELEASE 0xf0
#define ATKBD_RET_HANGUEL 0xf1
#define ATKBD_RET_HANJA 0xf2
#define ATKBD_RET_ERR 0xff
#define ATKBD_KEY_UNKNOWN 0
#define ATKBD_KEY_NULL 255
#define ATKBD_SCR_1 254
#define ATKBD_SCR_2 253
#define ATKBD_SCR_4 252
#define ATKBD_SCR_8 251
#define ATKBD_SCR_CLICK 250
#define ATKBD_SPECIAL 250
static unsigned char atkbd_scroll_keys[5][2] = {
{ ATKBD_SCR_1, 0x45 },
{ ATKBD_SCR_2, 0x29 },
{ ATKBD_SCR_4, 0x36 },
{ ATKBD_SCR_8, 0x27 },
{ ATKBD_SCR_CLICK, 0x60 },
};
#endif
/*
* The atkbd control structure
*/
struct atkbd {
unsigned char keycode[512];
char name[64];
char phys[32];
unsigned char cmdbuf[4];
unsigned char cmdcnt;
unsigned char set;
unsigned char extra;
unsigned char release;
int lastkey;
volatile signed char ack;
unsigned char emul;
unsigned short id;
unsigned char write;
unsigned char translated;
unsigned char resend;
unsigned char bat_xl;
unsigned int last;
};
static struct atkbd atkbd_data;
static struct atkbd * const atkbd = &atkbd_data;
static const char* phys_filename;
/********** functions for interacting with 'uinput' **********/
static const char *uinput_dev_name = NULL;
static int uinput_fd;
static void uinput_open() {
uinput_fd = open(uinput_dev_name, O_WRONLY);
}
static void uinput_set_evbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_EVBIT, bit);
if (r==-1) { pferrx(); }
}
static void uinput_set_ledbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_LEDBIT, bit);
if (r==-1) { pferrx();}
}
static void uinput_set_keybit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_KEYBIT, bit);
if (r==-1) { pferrx(); }
}
static void uinput_set_relbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_RELBIT, bit);
if (r==-1) { pferrx(); }
}
static void uinput_create() {
struct uinput_user_dev uinput = {
.name = "atkbd ",
};
int r;
snprintf(uinput.name, UINPUT_MAX_NAME_SIZE,
"atkbd %s", phys_filename);
r = write(uinput_fd, &uinput, sizeof(uinput));
if (r==-1) { pferrx(); }
r = ioctl(uinput_fd, UI_DEV_CREATE);
if (r==-1) { pferrx(); }
}
static void uinput_destroy() {
int r;
r = ioctl(uinput_fd, UI_DEV_DESTROY);
if (r==-1) { pferrx(); }
}
static void uinput_close() {
int r;
r = close(uinput_fd);
if (r==-1) { pferrx(); }
}
static void uinput_event(__u16 type, __u16 code, __s32 value) {
struct input_event ev = {
.type = type,
.code = code,
.value = value
};
int r;
r = write(uinput_fd, &ev, sizeof(ev));
if (r!=sizeof(ev)) { pferrx(); }
}
#define uinput_report_key(code,value) uinput_event(EV_KEY, (code), (value))
#define uinput_report_rel(code,value) uinput_event(EV_REL, (code), (value))
#define uinput_sync() uinput_event(EV_SYN, 0, 0)
/********** functions for accessing the raw keyboard device **********/
static int phys_fd = -1;
static const char* phys_filename;
static int phys_open() {
phys_fd = open(phys_filename, O_RDWR);
if (phys_fd == -1) {
const int e = errno;
perr(phys_filename);
switch (e) {
case EACCES:
err("read-write access required. Are you 'root'?\n");
break;
}
exit(1);
}
return 0;
}
static int phys_write(unsigned char byte) {
int r;
r = write(phys_fd, &byte, 1);
if (r==-1) { pferrx(); }
if (r!=1) { err("cannot write"); exit(1); }
return 0;
}
static void atkbd_interrupt(unsigned char data,
unsigned int flags);
static int phys_wait_for_input(int *ptimeout) {
unsigned char byte;
int r;
if (ptimeout != NULL) {
fd_set fds;
struct timeval tv;
FD_ZERO(&fds);
FD_SET(phys_fd, &fds);
tv.tv_sec=0; tv.tv_usec=*ptimeout;
r = select(phys_fd+1, &fds, NULL, &fds, &tv);
*ptimeout = tv.tv_sec*1000000 + tv.tv_usec;
if (r==-1) { pferrx(); }
if (r==0) { return -1; } /* timeout */
if (r!=1) { err("cannot select"); exit(1); }
}
r = read(phys_fd, &byte, 1);
if (r==-1) { pferrx(); }
if (r!=1) { err("cannot read"); exit(1); }
atkbd_interrupt(byte, 0);
return 0;
}
static void phys_close() {
int r;
r = close(phys_fd);
if (r==-1) { pferrx(); }
}
static int atkbd_connect();
static void atkbd_disconnect();
static void phys_rescan() {
atkbd_disconnect();
atkbd_connect();
}
static void atkbd_report_key(int code, int value)
{
if (value == 3) {
uinput_report_key(code, 1);
uinput_report_key(code, 0);
} else
uinput_event(EV_KEY, code, value);
uinput_sync();
}
/*
* atkbd_interrupt(). Here takes place processing of data received from
* the keyboard into events.
*/
static void atkbd_interrupt(unsigned char data,
unsigned int flags)
{
unsigned int code = data;
int scroll = 0, click = -1;
int value;
#ifdef ATKBD_DEBUG
printk(KERN_DEBUG "atkbd.c: Received %02x flags %02x\n", data, flags);
#endif
#if !defined(__i386__) && !defined (__x86_64__)
if ((flags & (SERIO_FRAME | SERIO_PARITY)) && (~flags & SERIO_TIMEOUT) && !atkbd->resend && atkbd->write) {
printk("atkbd.c: frame/parity error: %02x\n", flags);
serio_write(serio, ATKBD_CMD_RESEND);
atkbd->resend = 1;
goto out;
}
if (!flags && data == ATKBD_RET_ACK)
atkbd->resend = 0;
#endif
if (!atkbd->ack)
switch (code) {
case ATKBD_RET_ACK:
atkbd->ack = 1;
goto out;
case ATKBD_RET_NAK:
atkbd->ack = -1;
goto out;
}
if (atkbd->cmdcnt) {
atkbd->cmdbuf[--atkbd->cmdcnt] = code;
goto out;
}
if (atkbd->translated) {
if (atkbd->emul ||
!(code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1 ||
code == ATKBD_RET_HANGUEL || code == ATKBD_RET_HANJA ||
code == ATKBD_RET_ERR ||
(code == ATKBD_RET_BAT && !atkbd->bat_xl))) {
atkbd->release = code >> 7;
code &= 0x7f;
}
if (!atkbd->emul &&
(code & 0x7f) == (ATKBD_RET_BAT & 0x7f))
atkbd->bat_xl = !atkbd->release;
}
switch (code) {
case ATKBD_RET_BAT:
phys_rescan();
goto out;
case ATKBD_RET_EMUL0:
atkbd->emul = 1;
goto out;
case ATKBD_RET_EMUL1:
atkbd->emul = 2;
goto out;
case ATKBD_RET_RELEASE:
atkbd->release = 1;
goto out;
case ATKBD_RET_HANGUEL:
atkbd_report_key(KEY_HANGUEL, 3);
goto out;
case ATKBD_RET_HANJA:
atkbd_report_key(KEY_HANJA, 3);
goto out;
case ATKBD_RET_ERR:
warn("Keyboard reports too many keys pressed.\n");
goto out;
}
if (atkbd->set != 3)
code = (code & 0x7f) | ((code & 0x80) << 1);
if (atkbd->emul) {
if (--atkbd->emul)
goto out;
code |= (atkbd->set != 3) ? 0x80 : 0x100;
}
switch (atkbd->keycode[code]) {
case ATKBD_KEY_NULL:
break;
case ATKBD_KEY_UNKNOWN:
warn("Unknown key %s (%s set %d, code %#x).\n",
atkbd->release ? "released" : "pressed",
atkbd->translated ? "translated" : "raw",
atkbd->set, code);
if (atkbd->translated && atkbd->set == 2 && code == 0x7a)
warn("This is an XFree86 bug. It shouldn't access"
" hardware directly.\n");
else
warn("Use 'setkeycodes %s%02x <keycode>' to make it known.\n", code & 0x80 ? "e0" : "", code & 0x7f);
break;
case ATKBD_SCR_1:
scroll = 1 - atkbd->release * 2;
break;
case ATKBD_SCR_2:
scroll = 2 - atkbd->release * 4;
break;
case ATKBD_SCR_4:
scroll = 4 - atkbd->release * 8;
break;
case ATKBD_SCR_8:
scroll = 8 - atkbd->release * 16;
break;
case ATKBD_SCR_CLICK:
click = !atkbd->release;
break;
default:
value = atkbd->release ? 0 :
(1 + (!atkbd_softrepeat));
switch (value) { /* Workaround Toshiba laptop multiple keypress */
case 0:
atkbd->last = 0;
break;
case 1:
atkbd->last = code;
break;
case 2:
value = 1;
break;
}
atkbd_report_key(atkbd->keycode[code], value);
}
if (scroll || click != -1) {
uinput_report_key(BTN_MIDDLE, click);
uinput_report_rel(REL_WHEEL, scroll);
uinput_sync();
}
atkbd->release = 0;
out:
return;
}
/*
* atkbd_sendbyte() sends a byte to the keyboard, and waits for
* acknowledge. It doesn't handle resends according to the keyboard
* protocol specs, because if these are needed, the keyboard needs
* replacement anyway, and they only make a mess in the protocol.
*/
static int atkbd_sendbyte(unsigned char byte)
{
int timeout = 20000; /* 200 msec */
atkbd->ack = 0;
#ifdef ATKBD_DEBUG
printk(KERN_DEBUG "atkbd.c: Sent: %02x\n", byte);
#endif
if (phys_write(byte))
return -1;
while (!atkbd->ack && timeout>0)
phys_wait_for_input(&timeout);
return -(atkbd->ack <= 0);
}
/*
* atkbd_command() sends a command, and its parameters to the keyboard,
* then waits for the response and puts it in the param array.
*/
static int atkbd_command(unsigned char *param, int command)
{
int timeout = 500000; /* 500 msec */
int send = (command >> 12) & 0xf;
int receive = (command >> 8) & 0xf;
int i;
atkbd->cmdcnt = receive;
if (command == ATKBD_CMD_RESET_BAT)
timeout = 2000000; /* 2 sec */
if (receive && param)
for (i = 0; i < receive; i++)
atkbd->cmdbuf[(receive - 1) - i] = param[i];
if (command & 0xff)
if (atkbd_sendbyte(command & 0xff))
return (atkbd->cmdcnt = 0) - 1;
for (i = 0; i < send; i++)
if (atkbd_sendbyte(param[i]))
return (atkbd->cmdcnt = 0) - 1;
while (atkbd->cmdcnt && timeout>0) {
if (atkbd->cmdcnt == 1 &&
command == ATKBD_CMD_RESET_BAT && timeout > 100000)
timeout = 100000;
if (atkbd->cmdcnt == 1 && command == ATKBD_CMD_GETID &&
atkbd->cmdbuf[1] != 0xab && atkbd->cmdbuf[1] != 0xac) {
atkbd->cmdcnt = 0;
break;
}
phys_wait_for_input(&timeout);
}
if (param)
for (i = 0; i < receive; i++)
param[i] = atkbd->cmdbuf[(receive - 1) - i];
if (command == ATKBD_CMD_RESET_BAT && atkbd->cmdcnt == 1)
atkbd->cmdcnt = 0;
if (atkbd->cmdcnt) {
atkbd->cmdcnt = 0;
return -1;
}
return 0;
}
#if 0
/*
* Event callback from the input module. Events that change the state of
* the hardware are processed here.
*/
static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
{
struct atkbd *atkbd = dev->private;
const short period[32] =
{ 33, 37, 42, 46, 50, 54, 58, 63, 67, 75, 83, 92, 100, 109, 116, 125,
133, 149, 167, 182, 200, 217, 232, 250, 270, 303, 333, 370, 400, 435, 470, 500 };
const short delay[4] =
{ 250, 500, 750, 1000 };
unsigned char param[2];
int i, j;
if (!atkbd->write)
return -1;
switch (type) {
case EV_LED:
param[0] = (test_bit(LED_SCROLLL, dev->led) ? 1 : 0)
| (test_bit(LED_NUML, dev->led) ? 2 : 0)
| (test_bit(LED_CAPSL, dev->led) ? 4 : 0);
atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS);
if (atkbd->extra) {
param[0] = 0;
param[1] = (test_bit(LED_COMPOSE, dev->led) ? 0x01 : 0)
| (test_bit(LED_SLEEP, dev->led) ? 0x02 : 0)
| (test_bit(LED_SUSPEND, dev->led) ? 0x04 : 0)
| (test_bit(LED_MISC, dev->led) ? 0x10 : 0)
| (test_bit(LED_MUTE, dev->led) ? 0x20 : 0);
atkbd_command(atkbd, param, ATKBD_CMD_EX_SETLEDS);
}
return 0;
case EV_REP:
if (atkbd_softrepeat) return 0;
i = j = 0;
while (i < 32 && period[i] < dev->rep[REP_PERIOD]) i++;
while (j < 4 && delay[j] < dev->rep[REP_DELAY]) j++;
dev->rep[REP_PERIOD] = period[i];
dev->rep[REP_DELAY] = delay[j];
param[0] = i | (j << 5);
atkbd_command(atkbd, param, ATKBD_CMD_SETREP);
return 0;
}
return -1;
}
#endif
/*
* atkbd_probe() probes for an AT keyboard on a serio port.
*/
static int atkbd_probe()
{
unsigned char param[2];
/*
* Some systems, where the bit-twiddling when testing the io-lines of the
* controller may confuse the keyboard need a full reset of the keyboard. On
* these systems the BIOS also usually doesn't do it for us.
*/
if (atkbd_reset)
if (atkbd_command(NULL, ATKBD_CMD_RESET_BAT))
warn("keyboard reset failed on\n");
/*
* Then we check the keyboard ID. We should get 0xab83 under normal conditions.
* Some keyboards report different values, but the first byte is always 0xab or
* 0xac. Some old AT keyboards don't report anything. If a mouse is connected, this
* should make sure we don't try to set the LEDs on it.
*/
param[0] = param[1] = 0xa5; /* initialize with invalid values */
if (atkbd_command(param, ATKBD_CMD_GETID)) {
/*
* If the get ID command failed, we check if we can at least set the LEDs on
* the keyboard. This should work on every keyboard out there. It also turns
* the LEDs off, which we want anyway.
*/
param[0] = 0;
if (atkbd_command(param, ATKBD_CMD_SETLEDS))
return -1;
atkbd->id = 0xabba;
return 0;
}
if (param[0] != 0xab && param[0] != 0xac)
return -1;
atkbd->id = (param[0] << 8) | param[1];
if (atkbd->id == 0xaca1 && atkbd->translated) {
err("NCD terminal keyboards are only supported on non-translating\n");
err("controllers. Use i8042.direct=1 to disable translation.\n");
return -1;
}
return 0;
}
/*
* atkbd_set_3 checks if a keyboard has a working Set 3 support, and
* sets it into that. Unfortunately there are keyboards that can be switched
* to Set 3, but don't work well in that (BTC Multimedia ...)
*/
static int atkbd_set_3()
{
unsigned char param[2];
/*
* For known special keyboards we can go ahead and set the correct set.
* We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
* IBM RapidAccess / IBM EzButton / Chicony KBP-8993 keyboards.
*/
if (atkbd->translated)
return 2;
if (atkbd->id == 0xaca1) {
param[0] = 3;
atkbd_command(param, ATKBD_CMD_SSCANSET);
return 3;
}
if (atkbd_extra) {
param[0] = 0x71;
if (!atkbd_command(param, ATKBD_CMD_EX_ENABLE)) {
atkbd->extra = 1;
return 2;
}
}
if (atkbd_set != 3)
return 2;
if (!atkbd_command(param, ATKBD_CMD_OK_GETID)) {
atkbd->id = param[0] << 8 | param[1];
return 2;
}
param[0] = 3;
if (atkbd_command(param, ATKBD_CMD_SSCANSET))
return 2;
param[0] = 0;
if (atkbd_command(param, ATKBD_CMD_GSCANSET))
return 2;
if (param[0] != 3) {
param[0] = 2;
if (atkbd_command(param, ATKBD_CMD_SSCANSET))
return 2;
}
atkbd_command(param, ATKBD_CMD_SETALL_MBR);
return 3;
}
static int atkbd_enable()
{
unsigned char param[1];
/*
* Set the LEDs to a defined state.
*/
param[0] = 0;
if (atkbd_command(param, ATKBD_CMD_SETLEDS))
return -1;
/*
* Set autorepeat to fastest possible.
*/
param[0] = 0;
if (atkbd_command(param, ATKBD_CMD_SETREP))
return -1;
/*
* Enable the keyboard to receive keystrokes.
*/
if (atkbd_command(NULL, ATKBD_CMD_ENABLE)) {
err("Failed to enable keyboard\n");
return -1;
}
return 0;
}
/*
* atkbd_disconnect() closes and frees.
*/
static void atkbd_disconnect()
{
phys_close();
}
/*
* atkbd_connect() is called when the serio module finds and interface
* that isn't handled yet by an appropriate device driver. We check if
* there is an AT keyboard out there and if yes, we register ourselves
* to the input module.
*/
static int atkbd_connect()
{
int i;
memset(atkbd, 0, sizeof(struct atkbd));
#if 0
switch (serio->type & SERIO_TYPE) {
case SERIO_8042_XL:
atkbd->translated = 1;
case SERIO_8042:
if (serio->write)
atkbd->write = 1;
break;
case SERIO_RS232:
if ((serio->type & SERIO_PROTO) == SERIO_PS2SER)
break;
default:
kfree(atkbd);
return;
}
#else
atkbd->translated = 1;
atkbd->write = 1;
#endif
if (phys_open()) {
return -1;
}
if (atkbd->write) {
uinput_set_evbit(EV_KEY);
uinput_set_evbit(EV_LED);
uinput_set_evbit(EV_REP);
uinput_set_ledbit(LED_NUML);
uinput_set_ledbit(LED_CAPSL);
uinput_set_ledbit(LED_SCROLLL);
} else {
uinput_set_evbit(EV_KEY);
uinput_set_evbit(EV_REP);
}
if (atkbd_softrepeat) {
assert("not implemented yet" == 0);
}
atkbd->ack = 1;
if (atkbd->write) {
if (atkbd_probe()) {
return -1;
}
atkbd->set = atkbd_set_3();
atkbd_enable();
} else {
atkbd->set = 2;
atkbd->id = 0xab00;
}
if (atkbd->extra) {
uinput_set_ledbit(LED_COMPOSE);
uinput_set_ledbit(LED_SUSPEND);
uinput_set_ledbit(LED_SLEEP);
uinput_set_ledbit(LED_MUTE);
uinput_set_ledbit(LED_MISC);
sprintf(atkbd->name, "AT Set 2 Extra keyboard");
} else
sprintf(atkbd->name, "AT %s Set %d keyboard",
atkbd->translated ? "Translated" : "Raw", atkbd->set);
if (atkbd_scroll) {
for (i = 0; i < 5; i++)
atkbd_set2_keycode[atkbd_scroll_keys[i][1]] = atkbd_scroll_keys[i][0];
uinput_set_evbit(EV_REL);
uinput_set_relbit(REL_WHEEL);
uinput_set_keybit(BTN_MIDDLE);
}
if (atkbd->translated) {
for (i = 0; i < 128; i++) {
atkbd->keycode[i] = atkbd_set2_keycode[atkbd_unxlate_table[i]];
atkbd->keycode[i | 0x80] = atkbd_set2_keycode[atkbd_unxlate_table[i] | 0x80];
}
} else if (atkbd->set == 3) {
memcpy(atkbd->keycode, atkbd_set3_keycode, sizeof(atkbd->keycode));
} else {
memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
}
for (i = 0; i < 512; i++)
if (atkbd->keycode[i] && atkbd->keycode[i] < ATKBD_SPECIAL)
uinput_set_keybit(atkbd->keycode[i]);
info("keyboard %s\n", atkbd->name);
return 0;
}
int main(int argc, char**argv) {
if (argc != 2) {
fprintf(stderr, "Usage: %s raw_kbd_device\n", argv[0]);
return 1;
}
phys_filename = argv[1];
/* try devfs name first */
uinput_dev_name = "/dev/misc/uinput";
uinput_open();
if (uinput_fd == -1 && errno==ENOENT) {
/* was not found: try non-devfs name */
uinput_dev_name = "/dev/uinput";
uinput_open();
}
if (uinput_fd == -1) {
const int e = errno;
perr(uinput_dev_name);
switch (e) {
case ENOENT:
err("Have you loaded the 'uinput' module?\n");
break;
case EACCES:
err("Write access needed. Are you 'root'?\n");
break;
}
exit (1);
}
if (atkbd_connect() != 0) {
fprintf(stderr, "cannot connect to device\n");
return 1;
}
uinput_create();
for (;;) {
phys_wait_for_input(NULL);
}
uinput_destroy();
atkbd_disconnect();
uinput_close();
return 0;
}
[-- Attachment #3: psmouse.tgz --]
[-- Type: text/plain, Size: 51247 bytes --]
psmouse/#define _UINPUT_H_
extern void uinput_open(void);
extern void uinput_create(void);
extern void uinput_event(int type, int code, int value);
extern void uinput_report_key(int code, int value);
extern void uinput_report_rel(int code, int value);
extern void uinput_report_abs(int code, int value);
extern void uinput_sync();
extern void uinput_set_evbit(unsigned int bit);
extern void uinput_set_ledbit(unsigned int bit);
extern void uinput_set_relbit(unsigned int bit);
extern void uinput_set_keybit(unsigned int bit);
extern void uinput_clear_keybit(unsigned int bit);
#endif /* _UINPUT_H_ */
#include <fcntl.h>
#include <linux/input.h>
#include <linux/uinput.h>
#include "psmouse.h"
#include "uinput.h"
#define UI_DEV "/dev/misc/uinput"
static int uinput_fd = -1;
void uinput_open(void) {
uinput_fd = open(UI_DEV, O_WRONLY);
if (uinput_fd == -1) {
perror("Can't open");
err("Have you loaded the 'uinput' module?\n");
exit(1);
}
}
void uinput_create(void) {
struct uinput_user_dev uinput_user_dev;
int r;
strncpy(uinput_user_dev.name, psmouse->name,
UINPUT_MAX_NAME_SIZE);
r = write(uinput_fd, &uinput_user_dev, sizeof(uinput_user_dev));
if (r != sizeof(uinput_user_dev)) {
if (r==-1) perror("Can't write");
else err("Can't write");
exit(1);
}
r = ioctl(uinput_fd, UI_DEV_CREATE);
if (r==-1) {
perror("Can't create uinput device");
exit(1);
}
}
void uinput_event(int type, int code, int value) {
struct input_event ev = {
.type = type,
.code = code,
.value = value,
};
int r;
r = write(uinput_fd, &ev, sizeof(ev));
if (r != sizeof(ev)) {
if (r==-1) perror("Can't write");
else err("Can't write");
exit(1);
}
}
void uinput_report_key(int code, int value) {
uinput_event(EV_KEY, code, value);
}
void uinput_report_rel(int code, int value) {
uinput_event(EV_REL, code, value);
}
void uinput_report_abs(int code, int value) {
uinput_event(EV_ABS, code, value);
}
void uinput_sync() {
uinput_event(EV_SYN, SYN_REPORT, 0);
}
static void uinput_set_bit(int command, unsigned int bit) {
if (ioctl(uinput_fd, command, bit) == -1) {
perror("Can't ioctl");
exit(1);
}
}
void uinput_set_evbit(unsigned int bit) {
uinput_set_bit(UI_SET_EVBIT, bit);
}
void uinput_set_ledbit(unsigned int bit) {
uinput_set_bit(UI_SET_LEDBIT, bit);
}
void uinput_set_relbit(unsigned int bit) {
uinput_set_bit(UI_SET_RELBIT, bit);
}
void uinput_set_keybit(unsigned int bit) {
uinput_set_bit(UI_SET_KEYBIT, bit);
}
void uinput_clear_keybit(unsigned int bit) {
//FIXME!
}
* Synaptics TouchPad PS/2 mouse driver
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
#ifndef _SYNAPTICS_H
#define _SYNAPTICS_H
extern void synaptics_process_byte();
extern int synaptics_detect();
extern int synaptics_init();
extern void synaptics_reset();
/* synaptics queries */
#define SYN_QUE_IDENTIFY 0x00
#define SYN_QUE_MODES 0x01
#define SYN_QUE_CAPABILITIES 0x02
#define SYN_QUE_MODEL 0x03
#define SYN_QUE_SERIAL_NUMBER_PREFIX 0x06
#define SYN_QUE_SERIAL_NUMBER_SUFFIX 0x07
#define SYN_QUE_RESOLUTION 0x08
#define SYN_QUE_EXT_CAPAB 0x09
/* synatics modes */
#define SYN_BIT_ABSOLUTE_MODE (1 << 7)
#define SYN_BIT_HIGH_RATE (1 << 6)
#define SYN_BIT_SLEEP_MODE (1 << 3)
#define SYN_BIT_DISABLE_GESTURE (1 << 2)
#define SYN_BIT_FOUR_BYTE_CLIENT (1 << 1)
#define SYN_BIT_W_MODE (1 << 0)
/* synaptics model ID bits */
#define SYN_MODEL_ROT180(m) ((m) & (1 << 23))
#define SYN_MODEL_PORTRAIT(m) ((m) & (1 << 22))
#define SYN_MODEL_SENSOR(m) (((m) >> 16) & 0x3f)
#define SYN_MODEL_HARDWARE(m) (((m) >> 9) & 0x7f)
#define SYN_MODEL_NEWABS(m) ((m) & (1 << 7))
#define SYN_MODEL_PEN(m) ((m) & (1 << 6))
#define SYN_MODEL_SIMPLIC(m) ((m) & (1 << 5))
#define SYN_MODEL_GEOMETRY(m) ((m) & 0x0f)
/* synaptics capability bits */
#define SYN_CAP_EXTENDED(c) ((c) & (1 << 23))
#define SYN_CAP_PASS_THROUGH(c) ((c) & (1 << 7))
#define SYN_CAP_SLEEP(c) ((c) & (1 << 4))
#define SYN_CAP_FOUR_BUTTON(c) ((c) & (1 << 3))
#define SYN_CAP_MULTIFINGER(c) ((c) & (1 << 1))
#define SYN_CAP_PALMDETECT(c) ((c) & (1 << 0))
#define SYN_CAP_VALID(c) ((((c) & 0x00ff00) >> 8) == 0x47)
#define SYN_EXT_CAP_REQUESTS(c) ((((c) & 0x700000) >> 20) == 1)
#define SYN_CAP_MULTI_BUTTON_NO(ec) (((ec) & 0x00f000) >> 12)
/* synaptics modes query bits */
#define SYN_MODE_ABSOLUTE(m) ((m) & (1 << 7))
#define SYN_MODE_RATE(m) ((m) & (1 << 6))
#define SYN_MODE_BAUD_SLEEP(m) ((m) & (1 << 3))
#define SYN_MODE_DISABLE_GESTURE(m) ((m) & (1 << 2))
#define SYN_MODE_PACKSIZE(m) ((m) & (1 << 1))
#define SYN_MODE_WMODE(m) ((m) & (1 << 0))
/* synaptics identify query bits */
#define SYN_ID_MODEL(i) (((i) >> 4) & 0x0f)
#define SYN_ID_MAJOR(i) ((i) & 0x0f)
#define SYN_ID_MINOR(i) (((i) >> 16) & 0xff)
#define SYN_ID_IS_SYNAPTICS(i) ((((i) >> 8) & 0xff) == 0x47)
/* synaptics special commands */
#define SYN_PS_SET_MODE2 0x14
#define SYN_PS_CLIENT_CMD 0x28
/* synaptics packet types */
#define SYN_NEWABS 0
#define SYN_NEWABS_STRICT 1
#define SYN_NEWABS_RELAXED 2
#define SYN_OLDABS 3
/*
* A structure to describe the state of the touchpad hardware (buttons and pad)
*/
struct synaptics_hw_state {
int x;
int y;
int z;
int w;
int left;
int right;
int up;
int down;
int b0;
int b1;
int b2;
int b3;
int b4;
int b5;
int b6;
int b7;
};
struct synaptics_data {
/* Data read from the touchpad */
unsigned long int model_id; /* Model-ID */
unsigned long int capabilities; /* Capabilities */
unsigned long int ext_cap; /* Extended Capabilities */
unsigned long int identity; /* Identification */
/* Data for normal processing */
unsigned int out_of_sync; /* # of packets out of sync */
int old_w; /* Previous w value */
unsigned char pkt_type; /* packet type - old, new, etc */
};
#endif /* _SYNAPTICS_H */
* Synaptics TouchPad PS/2 mouse driver
*
* 2004 Sau Dan LEE
*
* 2003 Dmitry Torokhov <dtor@mail.ru>
* Added support for pass-through port. Special thanks to Peter Berg Larsen
* for explaining various Synaptics quirks.
*
* 2003 Peter Osterlund <petero2@telia.com>
* Ported to 2.5 input device infrastructure.
*
* Copyright (C) 2001 Stefan Gmeiner <riddlebox@freesurf.ch>
* start merging tpconfig and gpm code to a xfree-input module
* adding some changes and extensions (ex. 3rd and 4th button)
*
* Copyright (c) 1997 C. Scott Ananian <cananian@alumni.priceton.edu>
* Copyright (c) 1998-2000 Bruce Kalk <kall@compass.com>
* code for the special synaptics commands (from the tpconfig-source)
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*
* Trademarks are the property of their respective owners.
*/
#include <stdio.h>
#include <stdlib.h>
#include <linux/input.h>
#include "psmouse.h"
#include "synaptics.h"
/*
* The x/y limits are taken from the Synaptics TouchPad interfacing Guide,
* section 2.3.2, which says that they should be valid regardless of the
* actual size of the sensor.
*/
#define XMIN_NOMINAL 1472
#define XMAX_NOMINAL 5472
#define YMIN_NOMINAL 1408
#define YMAX_NOMINAL 4448
/*****************************************************************************
* Synaptics communications functions
****************************************************************************/
/*
* Use the Synaptics extended ps/2 syntax to write a special command byte.
* special command: 0xE8 rr 0xE8 ss 0xE8 tt 0xE8 uu where (rr*64)+(ss*16)+(tt*4)+uu
* is the command. A 0xF3 or 0xE9 must follow (see synaptics_send_cmd
* and synaptics_mode_cmd)
*/
static int synaptics_special_cmd(unsigned char command)
{
int i;
if (psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11))
return -1;
for (i = 6; i >= 0; i -= 2) {
unsigned char d = (command >> i) & 3;
if (psmouse_command(&d, PSMOUSE_CMD_SETRES))
return -1;
}
return 0;
}
/*
* Send a command to the synpatics touchpad by special commands
*/
static int synaptics_send_cmd(unsigned char c, unsigned char *param)
{
if (synaptics_special_cmd(c))
return -1;
if (psmouse_command(param, PSMOUSE_CMD_GETINFO))
return -1;
return 0;
}
/*
* Set the synaptics touchpad mode byte by special commands
*/
static int synaptics_mode_cmd(struct psmouse *psmouse, unsigned char mode)
{
unsigned char param[1];
if (synaptics_special_cmd(mode))
return -1;
param[0] = SYN_PS_SET_MODE2;
if (psmouse_command(param, PSMOUSE_CMD_SETRATE))
return -1;
return 0;
}
/*
* Read the model-id bytes from the touchpad
* see also SYN_MODEL_* macros
*/
static int synaptics_model_id()
{
struct synaptics_data *priv = psmouse->private;
unsigned char mi[3];
if (synaptics_send_cmd(SYN_QUE_MODEL, mi))
return -1;
priv->model_id = (mi[0]<<16) | (mi[1]<<8) | mi[2];
return 0;
}
/*
* Read the capability-bits from the touchpad
* see also the SYN_CAP_* macros
*/
static int synaptics_capability()
{
struct synaptics_data *priv = psmouse->private;
unsigned char cap[3];
if (synaptics_send_cmd(SYN_QUE_CAPABILITIES, cap))
return -1;
priv->capabilities = (cap[0]<<16) | (cap[1]<<8) | cap[2];
priv->ext_cap = 0;
if (!SYN_CAP_VALID(priv->capabilities))
return -1;
if (SYN_EXT_CAP_REQUESTS(priv->capabilities)) {
if (synaptics_send_cmd(SYN_QUE_EXT_CAPAB, cap)) {
err("Synaptics claims to have extended capabilities,"
" but I'm not able to read them.");
} else
priv->ext_cap = (cap[0]<<16) | (cap[1]<<8) | cap[2];
}
return 0;
}
/*
* Identify Touchpad
* See also the SYN_ID_* macros
*/
static int synaptics_identify()
{
struct synaptics_data *priv = psmouse->private;
unsigned char id[3];
if (synaptics_send_cmd(SYN_QUE_IDENTIFY, id))
return -1;
priv->identity = (id[0]<<16) | (id[1]<<8) | id[2];
if (SYN_ID_IS_SYNAPTICS(priv->identity))
return 0;
return -1;
}
static void print_ident(struct synaptics_data *priv)
{
info("Synaptics Touchpad, model: %ld\n", SYN_ID_MODEL(priv->identity));
info(" Firmware: %ld.%ld\n", SYN_ID_MAJOR(priv->identity),
SYN_ID_MINOR(priv->identity));
if (SYN_MODEL_ROT180(priv->model_id))
info(" 180 degree mounted touchpad\n");
if (SYN_MODEL_PORTRAIT(priv->model_id))
info(" portrait touchpad\n");
info(" Sensor: %ld\n", SYN_MODEL_SENSOR(priv->model_id));
if (SYN_MODEL_NEWABS(priv->model_id))
info(" new absolute packet format\n");
if (SYN_MODEL_PEN(priv->model_id))
info(" pen detection\n");
if (SYN_CAP_EXTENDED(priv->capabilities)) {
info(" Touchpad has extended capability bits\n");
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) <= 8)
info(" -> %d multi-buttons, i.e. besides standard buttons\n",
(int)(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)));
else if (SYN_CAP_FOUR_BUTTON(priv->capabilities))
info(" -> four buttons\n");
if (SYN_CAP_MULTIFINGER(priv->capabilities))
info(" -> multifinger detection\n");
if (SYN_CAP_PALMDETECT(priv->capabilities))
info(" -> palm detection\n");
if (SYN_CAP_PASS_THROUGH(priv->capabilities))
info(" -> pass-through port\n");
}
}
static int synaptics_query_hardware()
{
int retries = 0;
while ((retries++ < 3) && psmouse_reset())
err("synaptics reset failed\n");
if (synaptics_identify())
return -1;
if (synaptics_model_id())
return -1;
if (synaptics_capability())
return -1;
return 0;
}
static int synaptics_set_mode(struct psmouse *psmouse, int mode)
{
struct synaptics_data *priv = psmouse->private;
mode |= SYN_BIT_ABSOLUTE_MODE;
if (psmouse_rate >= 80)
mode |= SYN_BIT_HIGH_RATE;
if (SYN_ID_MAJOR(priv->identity) >= 4)
mode |= SYN_BIT_DISABLE_GESTURE;
if (SYN_CAP_EXTENDED(priv->capabilities))
mode |= SYN_BIT_W_MODE;
if (synaptics_mode_cmd(psmouse, mode))
return -1;
return 0;
}
/*****************************************************************************
* Driver initialization/cleanup functions
****************************************************************************/
#if 0
static inline void set_abs_params(struct input_dev *dev, int axis, int min, int max, int fuzz, int flat)
{
dev->absmin[axis] = min;
dev->absmax[axis] = max;
dev->absfuzz[axis] = fuzz;
dev->absflat[axis] = flat;
set_bit(axis, dev->absbit);
}
static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
{
set_bit(EV_ABS, dev->evbit);
set_abs_params(dev, ABS_X, XMIN_NOMINAL, XMAX_NOMINAL, 0, 0);
set_abs_params(dev, ABS_Y, YMIN_NOMINAL, YMAX_NOMINAL, 0, 0);
set_abs_params(dev, ABS_PRESSURE, 0, 255, 0, 0);
set_bit(ABS_TOOL_WIDTH, dev->absbit);
set_bit(EV_KEY, dev->evbit);
set_bit(BTN_TOUCH, dev->keybit);
set_bit(BTN_TOOL_FINGER, dev->keybit);
set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
set_bit(BTN_TOOL_TRIPLETAP, dev->keybit);
set_bit(BTN_LEFT, dev->keybit);
set_bit(BTN_RIGHT, dev->keybit);
set_bit(BTN_FORWARD, dev->keybit);
set_bit(BTN_BACK, dev->keybit);
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap)) {
switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
default:
/*
* if nExtBtn is greater than 8 it should be considered
* invalid and treated as 0
*/
break;
case 8:
set_bit(BTN_7, dev->keybit);
set_bit(BTN_6, dev->keybit);
case 6:
set_bit(BTN_5, dev->keybit);
set_bit(BTN_4, dev->keybit);
case 4:
set_bit(BTN_3, dev->keybit);
set_bit(BTN_2, dev->keybit);
case 2:
set_bit(BTN_1, dev->keybit);
set_bit(BTN_0, dev->keybit);
break;
}
}
clear_bit(EV_REL, dev->evbit);
clear_bit(REL_X, dev->relbit);
clear_bit(REL_Y, dev->relbit);
}
#endif
void synaptics_reset()
{
/* reset touchpad back to relative mode, gestures enabled */
synaptics_mode_cmd(psmouse, 0);
}
static void synaptics_disconnect()
{
synaptics_reset(psmouse);
}
static int synaptics_reconnect()
{
struct synaptics_data *priv = psmouse->private;
struct synaptics_data old_priv = *priv;
if (!synaptics_detect())
return -1;
if (synaptics_query_hardware()) {
err("Unable to query Synaptics hardware.\n");
return -1;
}
if (old_priv.identity != priv->identity ||
old_priv.model_id != priv->model_id ||
old_priv.capabilities != priv->capabilities ||
old_priv.ext_cap != priv->ext_cap)
return -1;
if (synaptics_set_mode(psmouse, 0)) {
err("Unable to initialize Synaptics hardware.\n");
return -1;
}
return 0;
}
int synaptics_detect()
{
unsigned char param[4];
param[0] = 0;
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_GETINFO);
return param[1] == 0x47;
}
int synaptics_init()
{
struct synaptics_data *priv;
psmouse->private = priv = calloc(1, sizeof(struct synaptics_data));
if (!priv)
return -1;
if (synaptics_query_hardware(psmouse)) {
err("Unable to query Synaptics hardware.\n");
goto init_fail;
}
if (synaptics_set_mode(psmouse, 0)) {
err("Unable to initialize Synaptics hardware.\n");
goto init_fail;
}
priv->pkt_type = SYN_MODEL_NEWABS(priv->model_id) ? SYN_NEWABS : SYN_OLDABS;
print_ident(priv);
psmouse->disconnect = synaptics_disconnect;
psmouse->reconnect = synaptics_reconnect;
return 0;
init_fail:
return -1;
}
/*****************************************************************************
* Functions to interpret the absolute mode packets
****************************************************************************/
static void synaptics_parse_hw_state(unsigned char buf[], struct synaptics_data *priv, struct synaptics_hw_state *hw)
{
memset(hw, 0, sizeof(struct synaptics_hw_state));
if (SYN_MODEL_NEWABS(priv->model_id)) {
hw->x = (((buf[3] & 0x10) << 8) |
((buf[1] & 0x0f) << 8) |
buf[4]);
hw->y = (((buf[3] & 0x20) << 7) |
((buf[1] & 0xf0) << 4) |
buf[5]);
hw->z = buf[2];
hw->w = (((buf[0] & 0x30) >> 2) |
((buf[0] & 0x04) >> 1) |
((buf[3] & 0x04) >> 2));
hw->left = (buf[0] & 0x01) ? 1 : 0;
hw->right = (buf[0] & 0x02) ? 1 : 0;
if (SYN_CAP_EXTENDED(priv->capabilities) &&
(SYN_CAP_FOUR_BUTTON(priv->capabilities))) {
hw->up = ((buf[3] & 0x01)) ? 1 : 0;
if (hw->left)
hw->up = !hw->up;
hw->down = ((buf[3] & 0x02)) ? 1 : 0;
if (hw->right)
hw->down = !hw->down;
}
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) &&
((buf[3] & 2) ? !hw->right : hw->right)) {
switch (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
default:
/*
* if nExtBtn is greater than 8 it should be
* considered invalid and treated as 0
*/
break;
case 8:
hw->b7 = ((buf[5] & 0x08)) ? 1 : 0;
hw->b6 = ((buf[4] & 0x08)) ? 1 : 0;
case 6:
hw->b5 = ((buf[5] & 0x04)) ? 1 : 0;
hw->b4 = ((buf[4] & 0x04)) ? 1 : 0;
case 4:
hw->b3 = ((buf[5] & 0x02)) ? 1 : 0;
hw->b2 = ((buf[4] & 0x02)) ? 1 : 0;
case 2:
hw->b1 = ((buf[5] & 0x01)) ? 1 : 0;
hw->b0 = ((buf[4] & 0x01)) ? 1 : 0;
}
}
} else {
hw->x = (((buf[1] & 0x1f) << 8) | buf[2]);
hw->y = (((buf[4] & 0x1f) << 8) | buf[5]);
hw->z = (((buf[0] & 0x30) << 2) | (buf[3] & 0x3F));
hw->w = (((buf[1] & 0x80) >> 4) | ((buf[0] & 0x04) >> 1));
hw->left = (buf[0] & 0x01) ? 1 : 0;
hw->right = (buf[0] & 0x02) ? 1 : 0;
}
}
/*
* called for each full received packet from the touchpad
*/
static void synaptics_process_packet()
{
struct synaptics_data *priv = psmouse->private;
struct synaptics_hw_state hw;
int num_fingers;
int finger_width;
synaptics_parse_hw_state(psmouse->packet, priv, &hw);
if (hw.z > 0) {
num_fingers = 1;
finger_width = 5;
if (SYN_CAP_EXTENDED(priv->capabilities)) {
switch (hw.w) {
case 0 ... 1:
if (SYN_CAP_MULTIFINGER(priv->capabilities))
num_fingers = hw.w + 2;
break;
case 2:
if (SYN_MODEL_PEN(priv->model_id))
; /* Nothing, treat a pen as a single finger */
break;
case 4 ... 15:
if (SYN_CAP_PALMDETECT(priv->capabilities))
finger_width = hw.w;
break;
}
}
} else {
num_fingers = 0;
finger_width = 0;
}
/* Post events
* BTN_TOUCH has to be first as mousedev relies on it when doing
* absolute -> relative conversion
*/
if (hw.z > 30) uinput_report_key(BTN_TOUCH, 1);
if (hw.z < 25) uinput_report_key(BTN_TOUCH, 0);
if (hw.z > 0) {
uinput_report_abs(ABS_X, hw.x);
uinput_report_abs(ABS_Y, YMAX_NOMINAL + YMIN_NOMINAL - hw.y);
}
uinput_report_abs(ABS_PRESSURE, hw.z);
uinput_report_abs(ABS_TOOL_WIDTH, finger_width);
uinput_report_key(BTN_TOOL_FINGER, num_fingers == 1);
uinput_report_key(BTN_TOOL_DOUBLETAP, num_fingers == 2);
uinput_report_key(BTN_TOOL_TRIPLETAP, num_fingers == 3);
uinput_report_key(BTN_LEFT, hw.left);
uinput_report_key(BTN_RIGHT, hw.right);
uinput_report_key(BTN_FORWARD, hw.up);
uinput_report_key(BTN_BACK, hw.down);
if (SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap))
switch(SYN_CAP_MULTI_BUTTON_NO(priv->ext_cap) & ~0x01) {
default:
/*
* if nExtBtn is greater than 8 it should be considered
* invalid and treated as 0
*/
break;
case 8:
uinput_report_key(BTN_7, hw.b7);
uinput_report_key(BTN_6, hw.b6);
case 6:
uinput_report_key(BTN_5, hw.b5);
uinput_report_key(BTN_4, hw.b4);
case 4:
uinput_report_key(BTN_3, hw.b3);
uinput_report_key(BTN_2, hw.b2);
case 2:
uinput_report_key(BTN_1, hw.b1);
uinput_report_key(BTN_0, hw.b0);
break;
}
uinput_sync();
}
static int synaptics_validate_byte(unsigned char packet[], int idx, unsigned char pkt_type)
{
static unsigned char newabs_mask[] = { 0xC8, 0x00, 0x00, 0xC8, 0x00 };
static unsigned char newabs_rel_mask[] = { 0xC0, 0x00, 0x00, 0xC0, 0x00 };
static unsigned char newabs_rslt[] = { 0x80, 0x00, 0x00, 0xC0, 0x00 };
static unsigned char oldabs_mask[] = { 0xC0, 0x60, 0x00, 0xC0, 0x60 };
static unsigned char oldabs_rslt[] = { 0xC0, 0x00, 0x00, 0x80, 0x00 };
switch (pkt_type) {
case SYN_NEWABS:
case SYN_NEWABS_RELAXED:
return (packet[idx] & newabs_rel_mask[idx]) == newabs_rslt[idx];
case SYN_NEWABS_STRICT:
return (packet[idx] & newabs_mask[idx]) == newabs_rslt[idx];
case SYN_OLDABS:
return (packet[idx] & oldabs_mask[idx]) == oldabs_rslt[idx];
default:
err("synaptics: unknown packet type %d\n", pkt_type);
return 0;
}
}
static unsigned char synaptics_detect_pkt_type(struct psmouse *psmouse)
{
int i;
for (i = 0; i < 5; i++)
if (!synaptics_validate_byte(psmouse->packet, i, SYN_NEWABS_STRICT)) {
info("synaptics: using relaxed packet validation\n");
return SYN_NEWABS_RELAXED;
}
return SYN_NEWABS_STRICT;
}
void synaptics_process_byte()
{
struct synaptics_data *priv = psmouse->private;
if (psmouse->pktcnt >= 6) { /* Full packet received */
if (priv->out_of_sync) {
priv->out_of_sync = 0;
notice("Synaptics driver resynced.\n");
}
if (unlikely(priv->pkt_type == SYN_NEWABS))
priv->pkt_type = synaptics_detect_pkt_type(psmouse);
synaptics_process_packet();
psmouse->pktcnt = 0;
} else if (psmouse->pktcnt &&
!synaptics_validate_byte(psmouse->packet, psmouse->pktcnt - 1, priv->pkt_type)) {
warn("Synaptics driver lost sync at byte %d\n", psmouse->pktcnt);
psmouse->pktcnt = 0;
if (++priv->out_of_sync == psmouse_resetafter) {
psmouse->state = PSMOUSE_IGNORE;
notice("synaptics: issuing reconnect request\n");
phys_reconnect();
}
}
}
#define _PSMOUSE_H
#define PSMOUSE_CMD_SETSCALE11 0x00e6
#define PSMOUSE_CMD_SETRES 0x10e8
#define PSMOUSE_CMD_GETINFO 0x03e9
#define PSMOUSE_CMD_SETSTREAM 0x00ea
#define PSMOUSE_CMD_POLL 0x03eb
#define PSMOUSE_CMD_GETID 0x02f2
#define PSMOUSE_CMD_SETRATE 0x10f3
#define PSMOUSE_CMD_ENABLE 0x00f4
#define PSMOUSE_CMD_RESET_DIS 0x00f6
#define PSMOUSE_CMD_RESET_BAT 0x02ff
#define PSMOUSE_RET_BAT 0xaa
#define PSMOUSE_RET_ID 0x00
#define PSMOUSE_RET_ACK 0xfa
#define PSMOUSE_RET_NAK 0xfe
/* psmouse states */
#define PSMOUSE_CMD_MODE 0
#define PSMOUSE_ACTIVATED 1
#define PSMOUSE_IGNORE 2
struct psmouse;
struct psmouse {
void *private;
char *vendor;
char *name;
unsigned char cmdbuf[8];
unsigned char packet[8];
unsigned char cmdcnt;
unsigned char pktcnt;
unsigned char type;
unsigned char model;
unsigned char state;
char acking;
volatile char ack;
char error;
char devname[64];
long long last;
int (*reconnect)();
void (*disconnect)();
};
#define PSMOUSE_PS2 1
#define PSMOUSE_PS2PP 2
#define PSMOUSE_PS2TPP 3
#define PSMOUSE_GENPS 4
#define PSMOUSE_IMPS 5
#define PSMOUSE_IMEX 6
#define PSMOUSE_SYNAPTICS 7
extern int psmouse_command(unsigned char *param, int command);
extern int psmouse_reset(void);
extern void phys_reconnect();
extern int psmouse_smartscroll;
extern unsigned int psmouse_rate;
extern unsigned int psmouse_resetafter;
extern struct psmouse * const psmouse;
extern void uinput_set_evbit(int bit);
extern void uinput_set_ledbit(int bit);
extern void uinput_set_keybit(int bit);
extern void uinput_set_relbit(int bit);
extern void uinput_event(__u16 type, __u16 code, __s32 value);
#define uinput_report_key(code,value) uinput_event(EV_KEY, (code), (value))
#define uinput_report_rel(code,value) uinput_event(EV_REL, (code), (value))
#define uinput_report_abs(code,value) uinput_event(EV_ABS, (code), (value))
#define uinput_sync() uinput_event(EV_SYN, 0, 0)
#define warn(...) fprintf(stderr, "psmouse: (warning) " __VA_ARGS__)
#define err(...) fprintf(stderr, "psmouse: ERROR " __VA_ARGS__)
#define info(...) printf("psmouse: " __VA_ARGS__)
#define notice(...) printf("psmouse: NOTE " __VA_ARGS__)
#define perr(msg) do{fprintf(stderr, "psmouse: ERROR: "); perror(msg);}while(0)
#define perrx(msg) do{perr(msg); exit(1);}while(0)
#define pferrx() perrx(__FUNCTION__)
#define unlikely /* */
#endif /* _PSMOUSE_H */
* PS/2 mouse driver
*
* Copyright (c) 1999-2002 Vojtech Pavlik
* Copyright (c) 2004 Sau Dan LEE
*/
/*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
/*
This program is based on linux-2.6.6/drivers/input/mouse/*
The difference is that this program 'psmouse' now runs in user-space
(swappable), while the kernel driver runs in kernel-space.
Usage: psmouse /dev/misc/isa0060/serio0
Prerequisites:
1) 'uinput' module loaded or compiled in
If not using 'devfs', you have to create the /dev/uinput char
device with major 10. The minor number can be found in
"cat /proc/misc" after loading the 'uinput' module.
2) 'serio' module with SERIO_USERDEV patch loaded or compiled in
3) 'i8042' module loaded or compiled in
4) 'psmouse' module UNloaded and NOT compiled in
5) 'mousedev' loaded to do anything really useful
TODO:
- options parsing should be added to allow user to
specify the module parameters.
- daemonize this program, so as to make it easy to run from /etc/inittab
- pass-through port of synaptics devices is not supported yet.
*/
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/time.h>
#include <linux/input.h>
#include <linux/uinput.h>
#include "psmouse.h"
#define module_param_named(name,var,type,defl) struct dummy
#define MODULE_PARM_DESC(name,desc) struct dummy
static char *psmouse_proto;
static unsigned int psmouse_max_proto = -1U;
module_param_named(proto, psmouse_proto, charp, 0);
MODULE_PARM_DESC(proto, "Highest protocol extension to probe (bare, imps, exps). Useful for KVM switches.");
int psmouse_resolution = 200;
module_param_named(resolution, psmouse_resolution, uint, 0);
MODULE_PARM_DESC(resolution, "Resolution, in dpi.");
unsigned int psmouse_rate = 100;
module_param_named(rate, psmouse_rate, uint, 0);
MODULE_PARM_DESC(rate, "Report rate, in reports per second.");
int psmouse_smartscroll = 1;
module_param_named(smartscroll, psmouse_smartscroll, bool, 0);
MODULE_PARM_DESC(smartscroll, "Logitech Smartscroll autorepeat, 1 = enabled (default), 0 = disabled.");
unsigned int psmouse_resetafter;
module_param_named(resetafter, psmouse_resetafter, uint, 0);
MODULE_PARM_DESC(resetafter, "Reset Synaptics Touchpad after so many bad packets (0 = never).");
static char *psmouse_protocols[] = { "None", "PS/2", "PS2++", "PS2T++", "GenPS/2", "ImPS/2", "ImExPS/2", "SynPS/2"};
static struct psmouse psmouse_data;
struct psmouse * const psmouse = &psmouse_data;
/********** functions for interacting with 'uinput' **********/
static const char *uinput_dev_name = NULL;
static int uinput_fd;
static void uinput_open() {
uinput_fd = open(uinput_dev_name, O_WRONLY);
}
void uinput_set_evbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_EVBIT, bit);
if (r==-1) { pferrx(); }
}
void uinput_set_ledbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_LEDBIT, bit);
if (r==-1) { pferrx();}
}
void uinput_set_keybit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_KEYBIT, bit);
if (r==-1) { pferrx(); }
}
void uinput_set_relbit(int bit) {
int r;
r = ioctl(uinput_fd, UI_SET_RELBIT, bit);
if (r==-1) { pferrx(); }
}
static const char* phys_filename;
static void uinput_create() {
struct uinput_user_dev uinput = {
.name = "psmouse ",
};
int r;
snprintf(uinput.name, UINPUT_MAX_NAME_SIZE,
"psmouse %s", phys_filename);
r = write(uinput_fd, &uinput, sizeof(uinput));
if (r==-1) { pferrx(); }
r = ioctl(uinput_fd, UI_DEV_CREATE);
if (r==-1) { pferrx(); }
}
static void uinput_destroy() {
int r;
r = ioctl(uinput_fd, UI_DEV_DESTROY);
if (r==-1) { pferrx(); }
}
static void uinput_close() {
int r;
r = close(uinput_fd);
if (r==-1) { pferrx(); }
}
void uinput_event(__u16 type, __u16 code, __s32 value) {
struct input_event ev = {
.type = type,
.code = code,
.value = value
};
int r;
r = write(uinput_fd, &ev, sizeof(ev));
if (r!=sizeof(ev)) { pferrx(); }
}
/********** functions for accessing the raw keyboard device **********/
static int phys_fd = -1;
static const char* phys_filename;
static int phys_open() {
phys_fd = open(phys_filename, O_RDWR);
if (phys_fd == -1) {
const int e = errno;
perr(phys_filename);
switch (e) {
case EACCES:
err("read-write access required. Are you 'root'?\n");
break;
}
exit(1);
}
return 0;
}
static int phys_write(unsigned char byte) {
int r;
r = write(phys_fd, &byte, 1);
if (r==-1) { pferrx(); }
if (r!=1) { err("cannot write"); exit(1); }
return 0;
}
static void psmouse_interrupt(unsigned char data,
unsigned int flags);
static int phys_wait_for_input(int *ptimeout) {
unsigned char byte;
int r;
if (ptimeout != NULL) {
fd_set fds;
struct timeval tv;
FD_ZERO(&fds);
FD_SET(phys_fd, &fds);
tv.tv_sec=0; tv.tv_usec=*ptimeout;
r = select(phys_fd+1, &fds, NULL, &fds, &tv);
*ptimeout = tv.tv_sec*1000000 + tv.tv_usec;
if (r==-1) { pferrx(); }
if (r==0) { return -1; } /* timeout */
if (r!=1) { err("cannot select"); exit(1); }
}
r = read(phys_fd, &byte, 1);
if (r==-1) { pferrx(); }
if (r!=1) { err("cannot read"); exit(1); }
psmouse_interrupt(byte, 0);
return 0;
}
static void phys_close() {
int r;
r = close(phys_fd);
if (r==-1) { pferrx(); }
}
static int psmouse_connect();
static void psmouse_disconnect();
static int psmouse_reconnect();
static void phys_rescan() {
psmouse_disconnect();
psmouse_connect();
}
void phys_reconnect() {
psmouse_reconnect();
}
/*
* psmouse_process_packet() analyzes the PS/2 mouse packet contents and
* reports relevant events to the input module.
*/
static void psmouse_process_packet()
{
unsigned char *packet = psmouse->packet;
/*
* The PS2++ protocol is a little bit complex
*/
if (psmouse->type == PSMOUSE_PS2PP || psmouse->type == PSMOUSE_PS2TPP)
ps2pp_process_packet();
/*
* Scroll wheel on IntelliMice, scroll buttons on NetMice
*/
if (psmouse->type == PSMOUSE_IMPS || psmouse->type == PSMOUSE_GENPS)
uinput_report_rel(REL_WHEEL, -(signed char) packet[3]);
/*
* Scroll wheel and buttons on IntelliMouse Explorer
*/
if (psmouse->type == PSMOUSE_IMEX) {
uinput_report_rel(REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
uinput_report_key(BTN_SIDE, (packet[3] >> 4) & 1);
uinput_report_key(BTN_EXTRA, (packet[3] >> 5) & 1);
}
/*
* Extra buttons on Genius NewNet 3D
*/
if (psmouse->type == PSMOUSE_GENPS) {
uinput_report_key(BTN_SIDE, (packet[0] >> 6) & 1);
uinput_report_key(BTN_EXTRA, (packet[0] >> 7) & 1);
}
/*
* Generic PS/2 Mouse
*/
uinput_report_key(BTN_LEFT, packet[0] & 1);
uinput_report_key(BTN_MIDDLE, (packet[0] >> 2) & 1);
uinput_report_key(BTN_RIGHT, (packet[0] >> 1) & 1);
uinput_report_rel(REL_X, packet[1] ? (int) packet[1] - (int) ((packet[0] << 4) & 0x100) : 0);
uinput_report_rel(REL_Y, packet[2] ? (int) ((packet[0] << 3) & 0x100) - (int) packet[2] : 0);
uinput_sync();
}
/*
* psmouse_interrupt() handles incoming characters, either gathering them into
* packets or passing them to the command routine as command output.
*/
static void psmouse_interrupt(unsigned char data, unsigned int flags)
{
if (psmouse->state == PSMOUSE_IGNORE)
goto out;
if (psmouse->acking) {
switch (data) {
case PSMOUSE_RET_ACK:
psmouse->ack = 1;
break;
case PSMOUSE_RET_NAK:
psmouse->ack = -1;
break;
default:
psmouse->ack = 1; /* Workaround for mice which don't ACK the Get ID command */
if (psmouse->cmdcnt)
psmouse->cmdbuf[--psmouse->cmdcnt] = data;
break;
}
psmouse->acking = 0;
goto out;
}
if (psmouse->cmdcnt) {
psmouse->cmdbuf[--psmouse->cmdcnt] = data;
goto out;
}
{
struct timeval tv;
long long jiffies;
int r;
r = gettimeofday(&tv, NULL);
if (r==-1) { pferrx(); }
jiffies = tv.tv_sec * 1000000 + tv.tv_usec;
if (psmouse->state == PSMOUSE_ACTIVATED &&
psmouse->pktcnt
&& jiffies > psmouse->last + 500000) {
warn("%s lost synchronization, throwing %d bytes away.\n",
psmouse->name, psmouse->pktcnt);
psmouse->pktcnt = 0;
}
psmouse->last = jiffies;
}
psmouse->packet[psmouse->pktcnt++] = data;
if (psmouse->packet[0] == PSMOUSE_RET_BAT) {
if (psmouse->pktcnt == 1)
goto out;
if (psmouse->pktcnt == 2) {
if (psmouse->packet[1] == PSMOUSE_RET_ID) {
psmouse->state = PSMOUSE_IGNORE;
phys_rescan();
goto out;
}
if (psmouse->type == PSMOUSE_SYNAPTICS) {
/* neither 0xAA nor 0x00 are valid first bytes
* for a packet in absolute mode
*/
psmouse->pktcnt = 0;
goto out;
}
}
}
if (psmouse->type == PSMOUSE_SYNAPTICS) {
/*
* The synaptics driver has its own resync logic,
* so it needs to receive all bytes one at a time.
*/
synaptics_process_byte(psmouse);
goto out;
}
if (psmouse->pktcnt == 3 + (psmouse->type >= PSMOUSE_GENPS)) {
psmouse_process_packet();
psmouse->pktcnt = 0;
goto out;
}
out:
return;
}
/*
* psmouse_sendbyte() sends a byte to the mouse, and waits for acknowledge.
* It doesn't handle retransmission, though it could - because when there would
* be need for retransmissions, the mouse has to be replaced anyway.
*/
static int psmouse_sendbyte(unsigned char byte)
{
int timeout = 10000; /* 100 msec */
psmouse->ack = 0;
psmouse->acking = 1;
if (phys_write(byte)) {
psmouse->acking = 0;
return -1;
}
while (!psmouse->ack && timeout>0)
phys_wait_for_input(&timeout);
return -(psmouse->ack <= 0);
}
/*
* psmouse_command() sends a command and its parameters to the mouse,
* then waits for the response and puts it in the param array.
*/
int psmouse_command(unsigned char *param, int command)
{
int timeout = 500000; /* 500 msec */
int send = (command >> 12) & 0xf;
int receive = (command >> 8) & 0xf;
int i;
psmouse->cmdcnt = receive;
if (command == PSMOUSE_CMD_RESET_BAT)
timeout = 4000000; /* 4 sec */
/* initialize cmdbuf with preset values from param */
if (receive)
for (i = 0; i < receive; i++)
psmouse->cmdbuf[(receive - 1) - i] = param[i];
if (command & 0xff)
if (psmouse_sendbyte(command & 0xff))
return (psmouse->cmdcnt = 0) - 1;
for (i = 0; i < send; i++)
if (psmouse_sendbyte(param[i]))
return (psmouse->cmdcnt = 0) - 1;
while (psmouse->cmdcnt && timeout>0) {
if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_RESET_BAT &&
timeout > 100000) /* do not run in a endless loop */
timeout = 100000; /* 1 sec */
if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_GETID &&
psmouse->cmdbuf[1] != 0xab && psmouse->cmdbuf[1] != 0xac) {
psmouse->cmdcnt = 0;
break;
}
phys_wait_for_input(&timeout);
}
for (i = 0; i < receive; i++)
param[i] = psmouse->cmdbuf[(receive - 1) - i];
if (psmouse->cmdcnt)
return (psmouse->cmdcnt = 0) - 1;
return 0;
}
/*
* psmouse_reset() resets the mouse into power-on state.
*/
int psmouse_reset()
{
unsigned char param[2];
if (psmouse_command(param, PSMOUSE_CMD_RESET_BAT))
return -1;
if (param[0] != PSMOUSE_RET_BAT && param[1] != PSMOUSE_RET_ID)
return -1;
return 0;
}
/*
* Genius NetMouse magic init.
*/
static int genius_detect()
{
unsigned char param[4];
param[0] = 3;
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command(param, PSMOUSE_CMD_GETINFO);
return param[0] == 0x00 && param[1] == 0x33 && param[2] == 0x55;
}
/*
* IntelliMouse magic init.
*/
static int intellimouse_detect()
{
unsigned char param[2];
param[0] = 200;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
param[0] = 100;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
param[0] = 80;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
psmouse_command(param, PSMOUSE_CMD_GETID);
return param[0] == 3;
}
/*
* Try IntelliMouse/Explorer magic init.
*/
static int im_explorer_detect()
{
unsigned char param[2];
param[0] = 200;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
param[0] = 200;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
param[0] = 80;
psmouse_command(param, PSMOUSE_CMD_SETRATE);
psmouse_command(param, PSMOUSE_CMD_GETID);
return param[0] == 4;
}
/*
* psmouse_extensions() probes for any extensions to the basic PS/2 protocol
* the mouse may have.
*/
static int psmouse_extensions()
{
int synaptics_hardware = 0;
psmouse->vendor = "Generic";
psmouse->name = "Mouse";
psmouse->model = 0;
/*
* Try Synaptics TouchPad
*/
if (psmouse_max_proto > PSMOUSE_PS2 && synaptics_detect()) {
synaptics_hardware = 1;
psmouse->vendor = "Synaptics";
psmouse->name = "TouchPad";
if (psmouse_max_proto > PSMOUSE_IMEX) {
if (synaptics_init() == 0)
return PSMOUSE_SYNAPTICS;
/*
* Some Synaptics touchpads can emulate extended protocols (like IMPS/2).
* Unfortunately Logitech/Genius probes confuse some firmware versions so
* we'll have to skip them.
*/
psmouse_max_proto = PSMOUSE_IMEX;
}
/*
* Make sure that touchpad is in relative mode, gestures (taps) are enabled
*/
synaptics_reset();
}
if (psmouse_max_proto > PSMOUSE_IMEX && genius_detect()) {
uinput_set_keybit(BTN_EXTRA);
uinput_set_keybit(BTN_SIDE);
uinput_set_relbit(REL_WHEEL);
psmouse->vendor = "Genius";
psmouse->name = "Wheel Mouse";
return PSMOUSE_GENPS;
}
if (psmouse_max_proto > PSMOUSE_IMEX) {
int type = ps2pp_detect();
if (type)
return type;
}
if (psmouse_max_proto >= PSMOUSE_IMPS && intellimouse_detect()) {
uinput_set_relbit(REL_WHEEL);
if (psmouse_max_proto >= PSMOUSE_IMEX &&
im_explorer_detect()) {
uinput_set_keybit(BTN_SIDE);
uinput_set_keybit(BTN_EXTRA);
psmouse->name = "Explorer Mouse";
return PSMOUSE_IMEX;
}
psmouse->name = "Wheel Mouse";
return PSMOUSE_IMPS;
}
/*
* Okay, all failed, we have a standard mouse here. The number of the buttons
* is still a question, though. We assume 3.
*/
if (synaptics_hardware) {
/*
* We detected Synaptics hardware but it did not respond to IMPS/2 probes.
* We need to reset the touchpad because if there is a track point on the
* pass through port it could get disabled while probing for protocol
* extensions.
*/
psmouse_reset();
psmouse_command(NULL, PSMOUSE_CMD_RESET_DIS);
}
return PSMOUSE_PS2;
}
/*
* psmouse_probe() probes for a PS/2 mouse.
*/
static int psmouse_probe()
{
unsigned char param[2];
/*
* First, we check if it's a mouse. It should send 0x00 or 0x03
* in case of an IntelliMouse in 4-byte mode or 0x04 for IM Explorer.
*/
param[0] = 0xa5;
if (psmouse_command(param, PSMOUSE_CMD_GETID))
return -1;
if (param[0] != 0x00 && param[0] != 0x03 && param[0] != 0x04)
return -1;
/*
* Then we reset and disable the mouse so that it doesn't generate events.
*/
if (psmouse_command(NULL, PSMOUSE_CMD_RESET_DIS))
warn("Failed to reset mouse\n");
/*
* And here we try to determine if it has any extensions over the
* basic PS/2 3-button mouse.
*/
return psmouse->type = psmouse_extensions();
}
/*
* Here we set the mouse resolution.
*/
static void psmouse_set_resolution()
{
unsigned char param[1];
if (psmouse->type == PSMOUSE_PS2PP && psmouse_resolution > 400) {
ps2pp_set_800dpi(psmouse);
return;
}
if (!psmouse_resolution || psmouse_resolution >= 200)
param[0] = 3;
else if (psmouse_resolution >= 100)
param[0] = 2;
else if (psmouse_resolution >= 50)
param[0] = 1;
else if (psmouse_resolution)
param[0] = 0;
psmouse_command(param, PSMOUSE_CMD_SETRES);
}
/*
* Here we set the mouse report rate.
*/
static void psmouse_set_rate()
{
unsigned char rates[] = { 200, 100, 80, 60, 40, 20, 10, 0 };
int i = 0;
while (rates[i] > psmouse_rate) i++;
psmouse_command(rates + i, PSMOUSE_CMD_SETRATE);
}
/*
* psmouse_initialize() initializes the mouse to a sane state.
*/
static void psmouse_initialize()
{
unsigned char param[2];
/*
* We set the mouse report rate, resolution and scaling.
*/
if (psmouse_max_proto != PSMOUSE_PS2) {
psmouse_set_rate();
psmouse_set_resolution();
psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
}
/*
* We set the mouse into streaming mode.
*/
psmouse_command(param, PSMOUSE_CMD_SETSTREAM);
}
/*
* psmouse_activate() enables the mouse so that we get motion reports from it.
*/
static void psmouse_activate()
{
if (psmouse_command(NULL, PSMOUSE_CMD_ENABLE))
warn("Failed to enable mouse\n");
psmouse->state = PSMOUSE_ACTIVATED;
}
#if 0
/*
* psmouse_cleanup() resets the mouse into power-on state.
*/
static void psmouse_cleanup(struct serio *serio)
{
struct psmouse *psmouse = serio->private;
psmouse_reset(psmouse);
}
#endif
/*
* psmouse_disconnect() closes and frees.
*/
static void psmouse_disconnect()
{
psmouse->state = PSMOUSE_CMD_MODE;
if (psmouse->disconnect)
psmouse->disconnect(psmouse);
psmouse->state = PSMOUSE_IGNORE;
phys_close();
}
/*
* psmouse_connect() is a callback from the serio module when
* an unhandled serio port is found.
*/
static int psmouse_connect()
{
memset(psmouse, 0, sizeof(struct psmouse));
uinput_set_evbit(EV_KEY);
uinput_set_evbit(EV_REL);
uinput_set_keybit(BTN_LEFT);
uinput_set_keybit(BTN_MIDDLE);
uinput_set_keybit(BTN_RIGHT);
uinput_set_relbit(REL_X);
uinput_set_relbit(REL_Y);
psmouse->state = PSMOUSE_CMD_MODE;
if (phys_open()) {
return -1;
}
if (psmouse_probe() <= 0) {
return -1;
}
sprintf(psmouse->devname, "%s %s %s",
psmouse_protocols[psmouse->type], psmouse->vendor, psmouse->name);
info("%s\n", psmouse->devname);
psmouse_initialize();
psmouse_activate();
return 0;
}
static int psmouse_reconnect()
{
int old_type;
old_type = psmouse->type;
psmouse->state = PSMOUSE_CMD_MODE;
psmouse->type = psmouse->acking = psmouse->cmdcnt = psmouse->pktcnt = 0;
if (psmouse->reconnect) {
if (psmouse->reconnect())
return -1;
} else if (psmouse_probe() != old_type)
return -1;
/* ok, the device type (and capabilities) match the old one,
* we can continue using it, complete intialization
*/
psmouse->type = old_type;
psmouse_initialize();
psmouse_activate();
return 0;
}
#if 0
static struct serio_dev psmouse_dev = {
.interrupt = psmouse_interrupt,
.connect = psmouse_connect,
.reconnect = psmouse_reconnect,
.disconnect = psmouse_disconnect,
.cleanup = psmouse_cleanup,
};
static inline void psmouse_parse_proto(void)
{
if (psmouse_proto) {
if (!strcmp(psmouse_proto, "bare"))
psmouse_max_proto = PSMOUSE_PS2;
else if (!strcmp(psmouse_proto, "imps"))
psmouse_max_proto = PSMOUSE_IMPS;
else if (!strcmp(psmouse_proto, "exps"))
psmouse_max_proto = PSMOUSE_IMEX;
else
printk(KERN_ERR "psmouse: unknown protocol type '%s'\n", psmouse_proto);
}
}
#endif
int main(int argc, char**argv) {
if (argc != 2) {
fprintf(stderr, "Usage: %s raw_ps2_mouse_device\n", argv[0]);
return 1;
}
phys_filename = argv[1];
/* try devfs name first */
uinput_dev_name = "/dev/misc/uinput";
uinput_open();
if (uinput_fd == -1 && errno==ENOENT) {
/* was not found: try non-devfs name */
uinput_dev_name = "/dev/uinput";
uinput_open();
}
if (uinput_fd == -1) {
const int e = errno;
perr(uinput_dev_name);
switch (e) {
case ENOENT:
err("Have you loaded the 'uinput' module?\n");
break;
case EACCES:
err("Write access needed. Are you 'root'?\n");
break;
}
exit (1);
}
if (psmouse_connect() != 0) {
fprintf(stderr, "cannot connect to device\n");
return 1;
}
uinput_create();
for (;;) {
phys_wait_for_input(NULL);
}
uinput_destroy();
psmouse_disconnect();
uinput_close();
return 0;
}
* Logitech PS/2++ mouse driver header
*
* Copyright (c) 2003 Vojtech Pavlik <vojtech@suse.cz>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
#ifndef _LOGIPS2PP_H
#define _LOGIPS2PP_H
#define PS2PP_4BTN 0x01
#define PS2PP_WHEEL 0x02
#define PS2PP_MX 0x04
#define PS2PP_MX310 0x08
struct psmouse;
void ps2pp_process_packet();
void ps2pp_set_800dpi();
int ps2pp_detect();
#endif
* Logitech PS/2++ mouse driver
*
* Copyright (c) 1999-2003 Vojtech Pavlik <vojtech@suse.cz>
* Copyright (c) 2003 Eric Wong <eric@yhbt.net>
* Copyright (c) 2004 Sau Dan LEE
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
#include <stdlib.h>
#include <linux/input.h>
#include "psmouse.h"
#include "logips2pp.h"
/*
* Process a PS2++ or PS2T++ packet.
*/
void ps2pp_process_packet()
{
unsigned char *packet = psmouse->packet;
if ((packet[0] & 0x48) == 0x48 && (packet[1] & 0x02) == 0x02) {
switch ((packet[1] >> 4) | (packet[0] & 0x30)) {
case 0x0d: /* Mouse extra info */
uinput_report_rel(packet[2] & 0x80 ? REL_HWHEEL : REL_WHEEL,
(int) (packet[2] & 8) - (int) (packet[2] & 7));
uinput_report_key(BTN_SIDE, (packet[2] >> 4) & 1);
uinput_report_key(BTN_EXTRA, (packet[2] >> 5) & 1);
break;
case 0x0e: /* buttons 4, 5, 6, 7, 8, 9, 10 info */
uinput_report_key(BTN_SIDE, (packet[2]) & 1);
uinput_report_key(BTN_EXTRA, (packet[2] >> 1) & 1);
uinput_report_key(BTN_BACK, (packet[2] >> 3) & 1);
uinput_report_key(BTN_FORWARD, (packet[2] >> 4) & 1);
uinput_report_key(BTN_TASK, (packet[2] >> 2) & 1);
break;
case 0x0f: /* TouchPad extra info */
uinput_report_rel(packet[2] & 0x08 ? REL_HWHEEL : REL_WHEEL,
(int) ((packet[2] >> 4) & 8) - (int) ((packet[2] >> 4) & 7));
packet[0] = packet[2] | 0x08;
break;
#ifdef DEBUG
default:
printk(KERN_WARNING "psmouse.c: Received PS2++ packet #%x, but don't know how to handle.\n",
(packet[1] >> 4) | (packet[0] & 0x30));
#endif
}
packet[0] &= 0x0f;
packet[1] = 0;
packet[2] = 0;
}
}
/*
* ps2pp_cmd() sends a PS2++ command, sliced into two bit
* pieces through the SETRES command. This is needed to send extended
* commands to mice on notebooks that try to understand the PS/2 protocol
* Ugly.
*/
static int ps2pp_cmd(unsigned char *param, unsigned char command)
{
unsigned char d;
int i;
if (psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11))
return -1;
for (i = 6; i >= 0; i -= 2) {
d = (command >> i) & 3;
if(psmouse_command(&d, PSMOUSE_CMD_SETRES))
return -1;
}
if (psmouse_command(param, PSMOUSE_CMD_POLL))
return -1;
return 0;
}
/*
* SmartScroll / CruiseControl for some newer Logitech mice Defaults to
* enabled if we do nothing to it. Of course I put this in because I want it
* disabled :P
* 1 - enabled (if previously disabled, also default)
* 0/2 - disabled
*/
static void ps2pp_set_smartscroll()
{
unsigned char param[4];
ps2pp_cmd(param, 0x32);
param[0] = 0;
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command(param, PSMOUSE_CMD_SETRES);
if (psmouse_smartscroll == 1)
param[0] = 1;
else
if (psmouse_smartscroll > 2)
return;
/* else leave param[0] == 0 to disable */
psmouse_command(param, PSMOUSE_CMD_SETRES);
}
/*
* Support 800 dpi resolution _only_ if the user wants it (there are good
* reasons to not use it even if the mouse supports it, and of course there are
* also good reasons to use it, let the user decide).
*/
void ps2pp_set_800dpi()
{
unsigned char param = 3;
psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command(NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command(¶m, PSMOUSE_CMD_SETRES);
}
/*
* Detect the exact model and features of a PS2++ or PS2T++ Logitech mouse or
* touchpad.
*/
static int ps2pp_detect_model(unsigned char *param)
{
int i;
static struct _logips2_list {
const int model;
unsigned const int features;
} logips2pp_list [] = {
{ 12, PS2PP_4BTN},
{ 13, 0 },
{ 40, PS2PP_4BTN },
{ 41, PS2PP_4BTN },
{ 42, PS2PP_4BTN },
{ 43, PS2PP_4BTN },
{ 50, 0 },
{ 51, 0 },
{ 52, PS2PP_4BTN | PS2PP_WHEEL },
{ 53, PS2PP_WHEEL },
{ 61, PS2PP_WHEEL | PS2PP_MX }, /* MX700 */
{ 73, PS2PP_4BTN },
{ 75, PS2PP_WHEEL },
{ 76, PS2PP_WHEEL },
{ 80, PS2PP_4BTN | PS2PP_WHEEL },
{ 81, PS2PP_WHEEL },
{ 83, PS2PP_WHEEL },
{ 88, PS2PP_WHEEL },
{ 96, 0 },
{ 97, 0 },
{ 100 , PS2PP_WHEEL | PS2PP_MX }, /* MX510 */
{ 112 , PS2PP_WHEEL | PS2PP_MX }, /* MX500 */
{ 114 , PS2PP_WHEEL | PS2PP_MX | PS2PP_MX310 }, /* MX310 */
{ }
};
psmouse->vendor = "Logitech";
psmouse->model = ((param[0] >> 4) & 0x07) | ((param[0] << 3) & 0x78);
#if 0
if (param[1] < 3)
clear_bit(BTN_MIDDLE, psmouse->dev.keybit);
if (param[1] < 2)
clear_bit(BTN_RIGHT, psmouse->dev.keybit);
#endif
psmouse->type = PSMOUSE_PS2;
for (i = 0; logips2pp_list[i].model; i++){
if (logips2pp_list[i].model == psmouse->model){
psmouse->type = PSMOUSE_PS2PP;
if (logips2pp_list[i].features & PS2PP_4BTN)
uinput_set_keybit(BTN_SIDE);
if (logips2pp_list[i].features & PS2PP_WHEEL){
uinput_set_relbit(REL_WHEEL);
psmouse->name = "Wheel Mouse";
}
if (logips2pp_list[i].features & PS2PP_MX) {
uinput_set_keybit(BTN_SIDE);
uinput_set_keybit(BTN_EXTRA);
uinput_set_keybit(BTN_TASK);
if (!(logips2pp_list[i].features & PS2PP_MX310)){
uinput_set_keybit(BTN_BACK);
uinput_set_keybit(BTN_FORWARD);
}
psmouse->name = "MX Mouse";
}
break;
}
}
/*
* Do Logitech PS2++ / PS2T++ magic init.
*/
if (psmouse->type == PSMOUSE_PS2PP) {
if (psmouse->model == 97) { /* TouchPad 3 */
uinput_set_relbit(REL_WHEEL);
uinput_set_relbit(REL_HWHEEL);
param[0] = 0x11; param[1] = 0x04; param[2] = 0x68; /* Unprotect RAM */
psmouse_command(param, 0x30d1);
param[0] = 0x11; param[1] = 0x05; param[2] = 0x0b; /* Enable features */
psmouse_command(param, 0x30d1);
param[0] = 0x11; param[1] = 0x09; param[2] = 0xc3; /* Enable PS2++ */
psmouse_command(param, 0x30d1);
param[0] = 0;
if (!psmouse_command(param, 0x13d1) &&
param[0] == 0x06 && param[1] == 0x00 && param[2] == 0x14) {
psmouse->name = "TouchPad 3";
return PSMOUSE_PS2TPP;
}
} else {
param[0] = param[1] = param[2] = 0;
ps2pp_cmd(param, 0x39); /* Magic knock */
ps2pp_cmd(param, 0xDB);
if ((param[0] & 0x78) == 0x48 && (param[1] & 0xf3) == 0xc2 &&
(param[2] & 3) == ((param[1] >> 2) & 3)) {
ps2pp_set_smartscroll();
return PSMOUSE_PS2PP;
}
}
}
return 0;
}
/*
* Logitech magic init.
*/
int ps2pp_detect()
{
unsigned char param[4];
param[0] = 0;
psmouse_command(param, PSMOUSE_CMD_SETRES);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
psmouse_command( NULL, PSMOUSE_CMD_SETSCALE11);
param[1] = 0;
psmouse_command(param, PSMOUSE_CMD_GETINFO);
return param[1] != 0 ? ps2pp_detect_model(param) : 0;
}
$(LINK.c) -o $@ $^
logips2pp.o: logips2pp.c psmouse.h logips2pp.h
psmouse-base.o: psmouse-base.c psmouse.h uinput.h synaptics.h logips2pp.h
synaptics.o: synaptics.c psmouse.h synaptics.h
[-- Attachment #4: Type: text/plain, Size: 195 bytes --]
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-25 20:16 ` keyboard problem with 2.6.6 Chris Osicki
2004-05-26 7:54 ` Sau Dan Lee
@ 2004-05-28 19:41 ` Andries Brouwer
2004-05-28 20:10 ` Andries Brouwer
[not found] ` <20040528214620.GA2352@gucio>
1 sibling, 2 replies; 80+ messages in thread
From: Andries Brouwer @ 2004-05-28 19:41 UTC (permalink / raw)
To: Chris Osicki; +Cc: linux-kernel
On Tue, May 25, 2004 at 10:16:16PM +0200, Chris Osicki wrote:
> I recently moved to kernel 2.6.6 from 2.4.26 and noticed that four keys
> on my keyboard stopped working.
> The kernel reports:
>
> keyboard: unrecognized scancode (XX) - ignored
>
> Where XX is 71, 72, 74, 75.
Hmm. This message seems to be from arch/arm26/lib/kbd.c
Is this message from 2.6.6? Is this an ARM?
> My setup is quite unusual as I'm using Sun type 5 keyboard on my
> PC with a self-made adapter. However, this setup has worked for at
> least six years with different kernel versions.
> The four keys which don't work anymore are from the function-key-set
> on the left hand side of the keyboard, if you know what a Sun
> keyboard looks like.
>
> I tried to solve my problem using setkeycodes and tried:
>
> setkeycodes 71 101
>
> as 101 was unused keycode (according to getkeycodes)
>
> getkeycodes reported after that:
>
> # getkeycodes | grep 0x70
> 0x70: 93 101 0 89 0 0 85 91
Your report is a bit messy. You change things for scancode 0x71 and then
expect the keycode for 0x70 to be changed?
> But showkeys -s shows 0x5b when the key in question is pressed
> (and no release event!!??)
Given a careful and precise report, no doubt it will be clear
what your situation is. Mention architecture, scancodes under 2.4,
scancodes under 2.6.
Andries
[The situation with arch/arm26/lib/kbd.c is funny.
That is the old keyboard code that was removed from
the general kernel code. No doubt it should be updated.]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-26 7:54 ` Sau Dan Lee
` (2 preceding siblings ...)
2004-05-28 19:39 ` 2.6.* useland replacements of the atkbd and psmouse modules Sau Dan Lee
@ 2004-05-28 19:57 ` Andries Brouwer
2004-06-01 8:21 ` BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6] Sau Dan Lee
` (2 subsequent siblings)
6 siblings, 0 replies; 80+ messages in thread
From: Andries Brouwer @ 2004-05-28 19:57 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Chris Osicki, linux-kernel
Sau Dan Lee wrote:
> Actually, I have a side issue with input/i8042 related things: The
> keyboard on my laptop worked slightly different: On 2.4.*, SysRq is
> activated using a [Fn] key-combo, which agrees with the keycap labels
> on the laptop keyboard. After upgrading to 2.6, that key-combo no
> longer works. Instead, I must use Alt-PrintScreen as the key for
> SysRq. (And unfortunately, PrintScreen is a [Fn] combo on the laptop,
> thus requiring press 3 keys at the same time for SysRq, and a fourth
> key to use the various SysRq features. Very inconvenient.) Is this
> again due to some dirty translation processes down in the input layer?
> Is the input layer always assuming that Alt-PrintScreen == SysRq?
> This is not always true. Can the input layer be so configured that it
> never tries to interpret the scancodes, but pass them to the upper
> layers?
So, what scancodes do you get in 2.4? And in 2.6? (Use scancode -s.)
Andries
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-28 19:41 ` keyboard problem with 2.6.6 Andries Brouwer
@ 2004-05-28 20:10 ` Andries Brouwer
[not found] ` <20040528214620.GA2352@gucio>
1 sibling, 0 replies; 80+ messages in thread
From: Andries Brouwer @ 2004-05-28 20:10 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Chris Osicki, linux-kernel
On Fri, May 28, 2004 at 09:41:36PM +0200, Andries Brouwer wrote:
> > setkeycodes 71 101
> >
> > # getkeycodes | grep 0x70
> > 0x70: 93 101 0 89 0 0 85 91
>
> Your report is a bit messy. You change things for scancode 0x71 and then
> expect the keycode for 0x70 to be changed?
Sorry - replied too quickly.
Yes, so your setkeycodes worked fine.
> > But showkeys -s shows 0x5b when the key in question is pressed
> > (and no release event!!??)
Now you told the kernel that scancode 0x71 belongs to keycode 101.
Do you say that your key does not have scancode 0x71, but 0x5b?
The question remains: what is it under 2.4? what under 2.6?
Andries
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-28 17:37 ` Sau Dan Lee
@ 2004-05-29 13:12 ` Vojtech Pavlik
2004-05-30 9:45 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-29 13:12 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
On Fri, May 28, 2004 at 07:37:57PM +0200, Sau Dan Lee wrote:
> I also agree the new system has its merits.
Thanks.
> What I hate is only the
> part where mouse/keyboard drivers are now in kernel space. The
> translation of raw byte streams into input events should be better
> done in userland. One important argument is: userland program may be
> swapped out. Kernel modules can't.
Well, keyboard support was always in the kernel - you need it there,
because you need the keyboard always to work - even in the case of a
crash, when all userspace programs may already be dead.
That's also the reason why keyboard processing is done in the interrupt
context - even if nothing else works in the kernel but interrupts, you
still can get a register dump for example, using the keyboard.
Regarding mice: Yes, PS/2 and serial mice can be in userspace, as is
proven by reality. With USB mice it's much tougher, and busmice and
many other mice on non-PC platforms need their drivers to be in the
kernel, as they access hardware directly and not via a byte stream
abstraction.
Although PS/2 mice are very common, they're just one case in many. Thus
it was easier to put the processing of them in the kernel, too. It gives
us good advantages, like the support for AUX multiplexing (where you
have more mice connected to one system), synaptics passthrough (where
you have a mouse connected to a touchpad, with the data being embedded
in the touchpad protocol), and other stuff.
For serial mice, doing the processing in the kernel brought us a 4 times
better response rate for the mousesystems kind of them and 2 times
better for microsoft mice. That actually makes both useable.
And here are the two main reasons to keep mouse and keyboard processing
in the kernel:
1) Latency. The time it takes from keypress to giving it to an
application. Adding intermediate programs inbetween doesn't help this at
all.
2) Unified interface. If an application (X, QtEmbedded, SDL ...) needs
to talk to a mouse or keyboard, it can use the event interface instead
of knowing a gazillion of different protocols. This is a kernel job.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-28 13:59 Tuukka Toivonen
@ 2004-05-29 13:14 ` Vojtech Pavlik
2004-06-04 14:54 ` Tuukka Toivonen
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-29 13:14 UTC (permalink / raw)
To: Tuukka Toivonen; +Cc: Giuseppe Bilotta, linux-kernel
On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen wrote:
> Giuseppe Bilotta wrote:
> >The new system has some ups and downs. The biggest "down",
> >which is that of RAW mode not being available anymore (it's
> >emulated!) could be circumvented by having both the RAW and
> >translated codes move between layers.
>
> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
> mode? To me this sounds like a big incompatibility.
Q1: What would you do if the user has an USB keyboard?
Q2: What application should be looking at the raw data outside the
kernel and why?
> Fortunately this patch
> (written together with Sau Dan Lee) should give _really_ raw mode in 2.6.x
> too (but it's not compatible with the raw mode in 2.4.x):
>
> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
[not found] ` <20040528214620.GA2352@gucio>
@ 2004-05-29 13:23 ` Andries Brouwer
2004-05-29 13:46 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Andries Brouwer @ 2004-05-29 13:23 UTC (permalink / raw)
To: Chris Osicki; +Cc: Andries Brouwer, linux-kernel
On Fri, May 28, 2004 at 11:46:20PM +0200, Chris Osicki wrote:
>>> I tried to solve my problem using setkeycodes and tried:
>>>
>>> setkeycodes 71 101
>>>
>>> getkeycodes reported after that:
>>>
>>> # getkeycodes | grep 0x70
>>> 0x70: 93 101 0 89 0 0 85 91
Yes, fine.
>>> But showkeys -s shows 0x5b when the key in question is pressed
>>> (and no release event!!??)
0x5b is 91 which is x86_keycodes[101].
Yes, so all is clear:
The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
that is not very raw. When you updated the table used for the
scancode->keycode translation, the table used to reconstruct what
might have been the original scancode was not changed accordingly.
Thus, showkeys -s gave a garbage answer.
Thanks for the report. It shows that resurrecting raw mode is even
more desirable than I thought at first.
Andries
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 13:23 ` Andries Brouwer
@ 2004-05-29 13:46 ` Vojtech Pavlik
2004-05-29 14:30 ` Andries Brouwer
2004-05-29 15:12 ` Giuseppe Bilotta
0 siblings, 2 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-29 13:46 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Chris Osicki, linux-kernel
On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer wrote:
> >>> But showkeys -s shows 0x5b when the key in question is pressed
> >>> (and no release event!!??)
>
> 0x5b is 91 which is x86_keycodes[101].
>
> Yes, so all is clear:
> The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
> that is not very raw. When you updated the table used for the
> scancode->keycode translation, the table used to reconstruct what
> might have been the original scancode was not changed accordingly.
> Thus, showkeys -s gave a garbage answer.
>
> Thanks for the report. It shows that resurrecting raw mode is even
> more desirable than I thought at first.
What for?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 13:46 ` Vojtech Pavlik
@ 2004-05-29 14:30 ` Andries Brouwer
2004-05-29 14:41 ` Vojtech Pavlik
2004-05-29 15:12 ` Giuseppe Bilotta
1 sibling, 1 reply; 80+ messages in thread
From: Andries Brouwer @ 2004-05-29 14:30 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Andries Brouwer, linux-kernel
On Sat, May 29, 2004 at 03:46:14PM +0200, Vojtech Pavlik wrote:
> > Thus, showkeys -s gave a garbage answer.
> >
> > Thanks for the report. It shows that resurrecting raw mode is even
> > more desirable than I thought at first.
>
> What for?
As you know, the keyboard/mouse situation in 2.6 is unfortunate.
I get a steady stream with letters from people complaining about
the keyboard utilities under 2.6. How can I answer and tell them
what the problem is? I need facts - raw data, so that I can
trace the path of this raw data through the kernel.
That is my reason I want a raw mode. Often I have to ask them
to boot 2.4 first to get reality, so that one afterwards is
in a better position to understand the fake reality of 2.6.
But apart from such debugging use, there is also the more
direct use: in order to assign a keycode to an unusual key
one first asks for the scancode using scancode -s, and then
assigns the keycode using setkeycodes. If scancode -s lies,
this fails.
Andries
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 14:30 ` Andries Brouwer
@ 2004-05-29 14:41 ` Vojtech Pavlik
0 siblings, 0 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-29 14:41 UTC (permalink / raw)
To: Andries Brouwer; +Cc: linux-kernel
On Sat, May 29, 2004 at 04:30:43PM +0200, Andries Brouwer wrote:
> On Sat, May 29, 2004 at 03:46:14PM +0200, Vojtech Pavlik wrote:
>
> > > Thus, showkeys -s gave a garbage answer.
> > >
> > > Thanks for the report. It shows that resurrecting raw mode is even
> > > more desirable than I thought at first.
> >
> > What for?
>
> As you know, the keyboard/mouse situation in 2.6 is unfortunate.
>
> I get a steady stream with letters from people complaining about
> the keyboard utilities under 2.6. How can I answer and tell them
> what the problem is? I need facts - raw data, so that I can
> trace the path of this raw data through the kernel.
>
> That is my reason I want a raw mode. Often I have to ask them
> to boot 2.4 first to get reality, so that one afterwards is
> in a better position to understand the fake reality of 2.6.
>
> But apart from such debugging use, there is also the more
> direct use: in order to assign a keycode to an unusual key
> one first asks for the scancode using scancode -s, and then
> assigns the keycode using setkeycodes. If scancode -s lies,
> this fails.
That's a good reason. I'll implement true rawmode support.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 13:46 ` Vojtech Pavlik
2004-05-29 14:30 ` Andries Brouwer
@ 2004-05-29 15:12 ` Giuseppe Bilotta
1 sibling, 0 replies; 80+ messages in thread
From: Giuseppe Bilotta @ 2004-05-29 15:12 UTC (permalink / raw)
To: linux-kernel
Vojtech Pavlik wrote:
> On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer wrote:
>
> > >>> But showkeys -s shows 0x5b when the key in question is pressed
> > >>> (and no release event!!??)
> >
> > 0x5b is 91 which is x86_keycodes[101].
> >
> > Yes, so all is clear:
> > The 2.6 kernel no longer has a raw mode - it has a simulated raw mode
> > that is not very raw. When you updated the table used for the
> > scancode->keycode translation, the table used to reconstruct what
> > might have been the original scancode was not changed accordingly.
> > Thus, showkeys -s gave a garbage answer.
> >
> > Thanks for the report. It shows that resurrecting raw mode is even
> > more desirable than I thought at first.
>
> What for?
One for all: X. Especially with multimedia keyboards. X has a
very exhaustive set of keyboard definitions for the many
multimedia keyboards. Each of them has multimedia keys in a
very wide and diverse range of strange scancodes. They all get
standard keysyms (XF86VolumeUp, etc).
Yes, the 'proper' solution would be to have the kernel provide
the abstraction layer: let the kernel have standard keycodes
for all the multimedia functions, and know, for the various
keyboard model, which scancodes generate them. And then have X
work on the keycodes.
But:
1. the Linux kernel does not (yet) have such an exhaustive
mapping as the xkbd models
2. the Linux kernel does not (yet) have any knowledge at all of
multimedia keys, for what I can see.
3. X works on non-Linux kernels and on older Linux kernels
The time to bring the new system to the same functionality
level as the old one is not short. The time to implement a
proper raw mode (e.g. by bleeding, see other post) would be
much shorter.
So, while we wait for complete support, at the kernel level,
for all the multimedia keyboards supported by X, we *need*
proper raw mode.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 13:12 ` Vojtech Pavlik
@ 2004-05-30 9:45 ` Sau Dan Lee
2004-05-30 10:19 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 9:45 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>> What I hate is only the part where mouse/keyboard drivers are
>> now in kernel space. The translation of raw byte streams into
>> input events should be better done in userland. One important
>> argument is: userland program may be swapped out. Kernel
>> modules can't.
Vojtech> Well, keyboard support was always in the kernel - you
Vojtech> need it there, because you need the keyboard always to
Vojtech> work
No. That's not the case (at least beginning from 2.6.6). If you
assume the keyboard is always there, they why make 'i8042' and 'atkbd'
modules?
I like the fact that 2.6.6 no longer assumes that the keyboard must be
there (and thanks for your work to modularize those pieces of code).
This assumption doesn't hold, for instance, in some embedded systems,
which has no keyboard controller and can only be controlled via an
RS232 port.
Vojtech> - even in the case of a crash, when all userspace
Vojtech> programs may already be dead.
There are still RS232 ports and the network.
Vojtech> That's also the reason why keyboard processing is done in
Vojtech> the interrupt context - even if nothing else works in the
Vojtech> kernel but interrupts, you still can get a register dump
Vojtech> for example, using the keyboard.
Can't SysRq be triggered from a program now, in addition to using a
keyboard?
Vojtech> Regarding mice: Yes, PS/2 and serial mice can be in
Vojtech> userspace, as is proven by reality. With USB mice it's
Vojtech> much tougher, and busmice and many other mice on non-PC
Vojtech> platforms need their drivers to be in the kernel, as they
Vojtech> access hardware directly and not via a byte stream
Vojtech> abstraction.
A kernel driver can turn it into a byte stream. What does 'evdev' do,
then? Isn't it turning those events into a stream of "struct
input_event"s? That's a byte stream, although you have to be careful
to call read()/write() with a suitable size parameter.
Vojtech> For serial mice, doing the processing in the kernel
Vojtech> brought us a 4 times better response rate for the
Vojtech> mousesystems kind of them and 2 times better for
Vojtech> microsoft mice. That actually makes both useable.
Is that "improvement" significant for 1200 baud devices? Even on a
386DX-33?
Vojtech> And here are the two main reasons to keep mouse and
Vojtech> keyboard processing in the kernel:
Vojtech> 1) Latency. The time it takes from keypress to giving it
Vojtech> to an application. Adding intermediate programs inbetween
Vojtech> doesn't help this at all.
Well... I believe 'pppd' is more sensitive to latencies problems (when
talking to the RS232 port) than a mouse driver. Why don't you migrate
pppd into the kernel, then? Remember, we have 56kbps modems (at 2400
baud?). I believe pppd should be kernelized before the mouse drivers.
Making pppd a kernel module also eliminates the current need for pppd
to communicate with a kernel driver to create the ppp0, ppp1,
... interfaces, too.
Actually, as long as the low-level byte-stream module has a big enough
buffer to handle the bursts of data, and the userland driver is quick
enough (on average) to consume the incoming data, what's the problem?
Vojtech> 2) Unified interface. If an application (X, QtEmbedded,
Vojtech> SDL ...) needs to talk to a mouse or keyboard, it can use
Vojtech> the event interface instead of knowing a gazillion of
Vojtech> different protocols.
I've demonstrated how a unified interface can be done using my atkbd.c
and psmouse userland drivers. These useland drivers translate the raw
byte stream, convert them into "struct input_event", and then refeed
them into the input system. It works!
Vojtech> This is a kernel job.
No. This can be done in userspace. We should keep the kernel code to
a minimal size. Most other "drivers" in Linux has a kernel half
(a.k.a. bottom-half?) and a userland half. The kernel half is to do
what must be done in kernel: creating a device, reacting to
interrupts, putting the stream of data in a buffer. Mostly simple
tasks that must be done quickly. The userland half, which is more
computation-intensitive, gets the data and do the complicated
processing.
If you think those are kernel jobs, then you have an argument for
implementing Ghostscript completely in kernel, so that we can cat
mythesis.ps > /dev/psprinter, whether or not my printer is a
Postscript printer, and whether or not it is connected locally or
remotely, right?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 9:45 ` Sau Dan Lee
@ 2004-05-30 10:19 ` Vojtech Pavlik
2004-05-30 11:25 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 10:19 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
On Sun, May 30, 2004 at 11:45:02AM +0200, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>
> >> What I hate is only the part where mouse/keyboard drivers are
> >> now in kernel space. The translation of raw byte streams into
> >> input events should be better done in userland. One important
> >> argument is: userland program may be swapped out. Kernel
> >> modules can't.
>
> Vojtech> Well, keyboard support was always in the kernel - you
> Vojtech> need it there, because you need the keyboard always to
> Vojtech> work
>
> No. That's not the case (at least beginning from 2.6.6). If you
> assume the keyboard is always there, they why make 'i8042' and 'atkbd'
> modules?
>
> I like the fact that 2.6.6 no longer assumes that the keyboard must be
> there (and thanks for your work to modularize those pieces of code).
> This assumption doesn't hold, for instance, in some embedded systems,
> which has no keyboard controller and can only be controlled via an
> RS232 port.
I meant that keyboard handling was never done in userspace. Of course it
is modular now, but that still counts as 'in the kernel'. ;) On embedded
systems, or when you have an USB keyboard, you can leave the whole PS/2
stuff out.
But still, if you have a working keyboard, the handling is done in the
kernel, and you can do a register dump, process listing, etc, even when
the system is crashed. You wouldn't be able to do that if the processing
of the byte stream was done in an userspace program.
> Vojtech> - even in the case of a crash, when all userspace
> Vojtech> programs may already be dead.
>
> There are still RS232 ports and the network.
Sure. How convenient it is to have to find an RS232 cable, when your
keyboard is just next to you on the table? I don't advocate _always_
having keyboard support, just the fact that if you have it, that it
should work regardless of system state.
> Vojtech> That's also the reason why keyboard processing is done in
> Vojtech> the interrupt context - even if nothing else works in the
> Vojtech> kernel but interrupts, you still can get a register dump
> Vojtech> for example, using the keyboard.
>
> Can't SysRq be triggered from a program now, in addition to using a
> keyboard?
It can. But if your userspace is dead, you cannot run that program. And
that's usually when you need sysrq.
> Vojtech> Regarding mice: Yes, PS/2 and serial mice can be in
> Vojtech> userspace, as is proven by reality. With USB mice it's
> Vojtech> much tougher, and busmice and many other mice on non-PC
> Vojtech> platforms need their drivers to be in the kernel, as they
> Vojtech> access hardware directly and not via a byte stream
> Vojtech> abstraction.
>
> A kernel driver can turn it into a byte stream.
Sure. You can turn anything into a byte stream. But you already have to
process it in the kernel. There is no point in creating a device
specific bytestream and then disassembling it again in userspace only to
again create a generic format bytestream.
> What does 'evdev' do,
> then? Isn't it turning those events into a stream of "struct
> input_event"s? That's a byte stream, although you have to be careful
> to call read()/write() with a suitable size parameter.
Sure. But it's a generic one, that's able to cover _any_ device. And all
with the same format. That's why it's much better to export this to
userspace than the raw mouse data.
> Vojtech> For serial mice, doing the processing in the kernel
> Vojtech> brought us a 4 times better response rate for the
> Vojtech> mousesystems kind of them and 2 times better for
> Vojtech> microsoft mice. That actually makes both useable.
>
> Is that "improvement" significant for 1200 baud devices? Even on a
> 386DX-33?
Yes. Very much significant. Exactly because they're running at 1200
baud, you need get most of that little data they're sending to you. With
the new kernel driver, MouseSystems mice are actually nice to work with,
and not the pain they used to be. Even on 386SX-16.
> Vojtech> And here are the two main reasons to keep mouse and
> Vojtech> keyboard processing in the kernel:
>
> Vojtech> 1) Latency. The time it takes from keypress to giving it
> Vojtech> to an application. Adding intermediate programs inbetween
> Vojtech> doesn't help this at all.
>
> Well... I believe 'pppd' is more sensitive to latencies problems (when
> talking to the RS232 port) than a mouse driver. Why don't you migrate
> pppd into the kernel, then? Remember, we have 56kbps modems (at 2400
> baud?). I believe pppd should be kernelized before the mouse drivers.
> Making pppd a kernel module also eliminates the current need for pppd
> to communicate with a kernel driver to create the ppp0, ppp1,
> ... interfaces, too.
Surprise: PPP handling _is_ in the kernel. pppd does the initial
handshaking, and then switches the kernel line discipline, and then the
characters are going straight from the port to the kernel, and then
they're packetized and appear in the ppp0 interface. No pppd interaction
inbetween at all.
> Actually, as long as the low-level byte-stream module has a big enough
> buffer to handle the bursts of data, and the userland driver is quick
> enough (on average) to consume the incoming data, what's the problem?
The problem is that you get jerky mouse movement. It stays for a while
on one place (when the buffer is filled), and then jumps elsewhere (when
it's processed). You need to do the processing byte by byte, as they
arrive.
> Vojtech> 2) Unified interface. If an application (X, QtEmbedded,
> Vojtech> SDL ...) needs to talk to a mouse or keyboard, it can use
> Vojtech> the event interface instead of knowing a gazillion of
> Vojtech> different protocols.
>
> I've demonstrated how a unified interface can be done using my atkbd.c
> and psmouse userland drivers. These useland drivers translate the raw
> byte stream, convert them into "struct input_event", and then refeed
> them into the input system. It works!
Yes, it does. Because it uses the _kernel_ input system to do the
interfacing work. But I don't see any benefit of having to go to
userspace and back again into the kernel.
> Vojtech> This is a kernel job.
>
> No. This can be done in userspace. We should keep the kernel code to
> a minimal size. Most other "drivers" in Linux has a kernel half
> (a.k.a. bottom-half?) and a userland half. The kernel half is to do
> what must be done in kernel: creating a device, reacting to
> interrupts, putting the stream of data in a buffer. Mostly simple
> tasks that must be done quickly. The userland half, which is more
> computation-intensitive, gets the data and do the complicated
> processing.
Care to name any? Everything from raw SCSI handling to presenting files
to processes is done in the kernel. Everything from talking to Ethernet
HW to processing IP and TCP and routing and firewalling to presenting
read()able sockets to applications is done in the kernel. No userspace
support there.
> If you think those are kernel jobs, then you have an argument for
> implementing Ghostscript completely in kernel, so that we can cat
> mythesis.ps > /dev/psprinter, whether or not my printer is a
> Postscript printer, and whether or not it is connected locally or
> remotely, right?
Good argument. There are limits of what makes sense to do in the kernel.
Ghostscript is easier to do in userspace, because it needs access to
fonts, has a nontrivial configuration, isn't time critical, etc. Good
candidate for userspace.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-05-30 10:39 Sau Dan Lee
2004-05-30 11:18 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 10:39 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
Vojtech> On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen
Vojtech> wrote:
>> Giuseppe Bilotta wrote: >The new system has some ups and
>> downs. The biggest "down", >which is that of RAW mode not being
>> available anymore (it's >emulated!) could be circumvented by
>> having both the RAW and >translated codes move between layers.
>>
>> Ouch! If the user asks for raw mode, he doesn't get it, but
>> some emulated mode? To me this sounds like a big
>> incompatibility.
Vojtech> Q1: What would you do if the user has an USB keyboard?
If he was raw mode from a USB keyboard, he should get the raw data.
Of course, he should know what he's doing.
Vojtech> Q2: What application should be looking at the raw data
Vojtech> outside the kernel and why?
What application should be looking at the raw data from an RS232 port
outside the kernel and why?
Why do you leave 'efax' in userspace, letting it read/write raw data
to/from the modem via the RS232?
>> Fortunately this patch (written together with Sau Dan Lee)
>> should give _really_ raw mode in 2.6.x too (but it's not
>> compatible with the raw mode in 2.4.x):
>>
>> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
In a nutshell, I hate to be restricted by YOUR own imaginations of how
people should hack the system.
Raw keyboard data, for instance, can be captured for analyzing how
people use the keyboard and coming up with a more efficient keyboard
layout (c.f. Dvorak). That's already beyond your imaginations.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-05-30 10:45 Sau Dan Lee
2004-05-30 11:20 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 10:45 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Tuukka Toivonen, linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
On Sat, May 29, 2004 at 03:23:20PM +0200, Andries Brouwer
>> Thanks for the report. It shows that resurrecting raw mode is
>> even more desirable than I thought at first.
Vojtech> What for?
For more imaginative innovations.
e.g. try my keyboard driver across 2 machines (using the SERIO_USERDEV
patch from Tuukka Toivonen and me):
master$ cat /dev/misc/isa0060/serio0 | ssh slave atkbd /proc/self/fd/0
The patch is here:
http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
The driver is here:
http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/atkbd.c
(I haven't tried this, as I don't have 2 machines under my control
(==root) to try it out. Please tell me the results.)
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-05-30 10:57 Sau Dan Lee
2004-06-01 11:31 ` Pavel Machek
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 10:57 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: linux-kernel
>>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
Giuseppe> So, while we wait for complete support, at the kernel
Giuseppe> level, for all the multimedia keyboards supported by X,
Giuseppe> we *need* proper raw mode.
My question is: why do everything inside the kernel?
Even 'khttpd' has been removed from the kernel, because the same
efficiency has been achieved in the *userland* apache module. Why is
the input layer moving _backwards_?
I don't think converting between keyboard/mouse protocols and the
input system's "struct input_event" has a tighter real-time
requirement than a heavily loaded web server. How many keys per
second can you type at? (Even if you type extremely fast and the
hardware constraints (velocity, etc.) are not reached yet, there is
still a limit that the keyboard controller, e.g. i8042, cannot
exceed.) How many mouse movements are you making per second? Is a
userland driver unable to handle that data rate? (I don't think so.
I believe enve a 386-DX 33MHz can handle it with ease.) If not, then
please do it in userland, so as not to waste kernel memory (which is
*NON-swappable*).
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 10:39 Sau Dan Lee
@ 2004-05-30 11:18 ` Vojtech Pavlik
2004-05-30 11:40 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 11:18 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: linux-kernel
On Sun, May 30, 2004 at 12:39:40PM +0200, Sau Dan Lee wrote:
> Vojtech> Q1: What would you do if the user has an USB keyboard?
>
> If he was raw mode from a USB keyboard, he should get the raw data.
> Of course, he should know what he's doing.
The USB communication is not byte-oriented, so that wouldn't work.
Anyway, if we could pass the USB data in some form through the console
in raw mode, this would of course break XFree86, as it wouldn't
understand it.
> Vojtech> Q2: What application should be looking at the raw data
> Vojtech> outside the kernel and why?
>
> What application should be looking at the raw data from an RS232 port
> outside the kernel and why?
Terminal. Terminals use the data directly.
Actually it's pretty annoying there isn't a higher level abstraction of
modem than a RS232 port, because when you have a softmodem, the driver
needs to implement a fake RS232 port, including fake RTS/CTS, DSR/DTR
lines, and completely fake AT commands, so that applications that expect
to talk to a RS232 port work with it.
Anyway, the RS232 port is a multi purpose port, where you can attach
many different devices to it. For the keyboard port, there is only one
option, the keyboard. Of course, unless you create a device that can use
it, but in that case you can easily write a kernel driver for it.
> Why do you leave 'efax' in userspace, letting it read/write raw data
> to/from the modem via the RS232?
Because I draw the line of what is supposed to be in the kernel and what
belongs to userspace on a different place than you.
> >> Fortunately this patch (written together with Sau Dan Lee)
> >> should give _really_ raw mode in 2.6.x too (but it's not
> >> compatible with the raw mode in 2.4.x):
> >>
> >> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
>
> In a nutshell, I hate to be restricted by YOUR own imaginations of how
> people should hack the system.
You're not. You're free to hack the kernel drivers. You can do whatever
you wish. But I also have the option to not use your creations in the
input system.
> Raw keyboard data, for instance, can be captured for analyzing how
> people use the keyboard and coming up with a more efficient keyboard
> layout (c.f. Dvorak). That's already beyond your imaginations.
The raw data not what you want to use there. You want the keystroke
data, and for that you can use the /dev/input/event interface, where you
get them in a sane format (as opposed to the PS/2 rawmode, which can
send up ot 8 bytes for a single keystroke).
Then your statistic analyser will work just fine even on a Sun, Mac, or
with an USB keyboard.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 10:45 Sau Dan Lee
@ 2004-05-30 11:20 ` Vojtech Pavlik
0 siblings, 0 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 11:20 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Tuukka Toivonen, linux-kernel
On Sun, May 30, 2004 at 12:45:02PM +0200, Sau Dan Lee wrote:
> For more imaginative innovations.
>
> e.g. try my keyboard driver across 2 machines (using the SERIO_USERDEV
> patch from Tuukka Toivonen and me):
>
> master$ cat /dev/misc/isa0060/serio0 | ssh slave atkbd /proc/self/fd/0
>
> The patch is here:
> http://www.ee.oulu.fi/~tuukkat/tmp/linux-2.6.5-userdev.20040507.patch
>
> The driver is here:
> http://www.informatik.uni-freiburg.de/~danlee/fun/psaux/atkbd.c
>
> (I haven't tried this, as I don't have 2 machines under my control
> (==root) to try it out. Please tell me the results.)
You can do this trivially without any patches, just by forwarding the
input events between the machines, reading evdev on one and using uinput
on the other. It will work without modification for mice, joysticks,
whatever you wish.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 10:19 ` Vojtech Pavlik
@ 2004-05-30 11:25 ` Sau Dan Lee
2004-05-30 11:40 ` Brad Campbell
` (3 more replies)
0 siblings, 4 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 11:25 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>> >> What I hate is only the part where mouse/keyboard drivers
>> >> are now in kernel space. The translation of raw byte
>> >> streams into input events should be better done in userland.
>> >> One important argument is: userland program may be swapped
>> >> out. Kernel modules can't.
>>
Vojtech> Well, keyboard support was always in the kernel
Once in kernel space, forever in kernel space? What's the logic?
Where it is now possible to move it out of kernel space WITHOUT
performance problems, why not move it out?
Vojtech> - you need it there, because you need the keyboard
Vojtech> always to work
Then, why make 'i8042' and 'atkbd' modules? I still remember reading
web pages that early pioneers who migrated from 2.4 to 2.6.0-test*
encountered a problem: they didn't compile-in these modules, and hence
the system boot up without a responding keyboard. Despite that, the
system does work and daemons are running!
So, why is a the keyboard need to always work?
I've been testing 'i8042' module and my atkbd driver (and the
SERIO_USERDEV patch) through the network. I've been doing 'rmmod
i8042' many many times. The system DOES work without that module (and
keyboard functionality). Why are you saying that "you need the
keyboard always to work"? Again, is that the limit of your
imagination?
Are you aware of the i8042_shutdown bug, which I discovered and fixed?
How could I have found such a bug, if "keyboard has to always work"?
And how about mouse drivers? They used to be in userland (gpm,
XFree86 3.x -- 4.x, etc.) Why move it into the kernel?
>> I like the fact that 2.6.6 no longer assumes that the keyboard
>> must be there (and thanks for your work to modularize those
>> pieces of code). This assumption doesn't hold, for instance,
>> in some embedded systems, which has no keyboard controller and
>> can only be controlled via an RS232 port.
Vojtech> I meant that keyboard handling was never done in
Vojtech> userspace.
OK. Then, it's time to consider moving it to userspace.
Vojtech> Of course it is modular now, but that still counts as 'in
Vojtech> the kernel'.
How about my atkbd.c?
Vojtech> ;) On embedded systems, or when you have an USB
Vojtech> keyboard, you can leave the whole PS/2 stuff out.
Is it impossible to run daemons driving the keyboard (my atkbd.c,
should be invoked from inittab) and mouse (e.g. gpm) on embedded
systems? I mean, why MUST the keyboard and mouse drivers be in kernel
space?
Vojtech> But still, if you have a working keyboard, the handling
Vojtech> is done in the kernel, and you can do a register dump,
Vojtech> process listing, etc, even when the system is
Vojtech> crashed.
Why just the keyboard? For that purpose, we can use mouse buttons,
the power button, a joystick button, or even a home-brewed button
connected to the RS232 port or parallel port. Why *limit* that to the
keyboard?
Vojtech> You wouldn't be able to do that if the processing of the
Vojtech> byte stream was done in an userspace program.
Isn't it possible to monitor the kernel via a tty connected to the
serial line?
Vojtech> - even in the case of a crash, when all userspace
Vojtech> programs may already be dead.
>> There are still RS232 ports and the network.
Vojtech> Sure. How convenient it is to have to find an RS232
Vojtech> cable, when your keyboard is just next to you on the
Vojtech> table?
The keyboard should be made an *option*, not a *requirement* for that.
As an optional feature, yo shouldn't assume it for granted.
>> Can't SysRq be triggered from a program now, in addition to
>> using a keyboard?
Vojtech> It can. But if your userspace is dead, you cannot run
Vojtech> that program. And that's usually when you need sysrq.
So, why limit that to the keyboard only? Why can't my LED lid switch
do it?
>> Is that "improvement" significant for 1200 baud devices? Even
>> on a 386DX-33?
Vojtech> Yes. Very much significant. Exactly because they're
Vojtech> running at 1200 baud, you need get most of that little
Vojtech> data they're sending to you.
I don't understand this. The slower a device is, the lesser is the
need to handle the incoming data in kernel space. I can't understand
how 1200baud is fast enough to cause significant delays. Maybe, you
can enlighten me on that?
Vojtech> The problem is that you get jerky mouse movement. It
Vojtech> stays for a while on one place (when the buffer is
Vojtech> filled), and then jumps elsewhere (when it's
Vojtech> processed). You need to do the processing byte by byte,
Vojtech> as they arrive.
Yeah. At what rate are they arriving? 1200baud. Let's say that'
9600bps. So, 1200 bytes per second. 1 byte in every 833
microseconds. How come a processor at 33MHz (0.030 microseconds per
clock cycle) cannot cope with that? Assuming that the processing of
the data plus context switching plus other overhead taks 1000
microseconds, that still shouldn't be felt by a HUMAN user. Who has a
reaction time of less than 100 _milli_seconds?
Vojtech> Yes, it does. Because it uses the _kernel_ input system
Vojtech> to do the interfacing work. But I don't see any benefit
Vojtech> of having to go to userspace and back again into the
Vojtech> kernel.
Flexibility. The keyboard driver can talk to another machine via a
TCP connection, for instance. The keyboard driver can be easily
modified and debugged -- all in user space -- without hanging the
kernel due to stupid bugs (e.g. NULL pointers). The keyboard driver
could be prototyped in Perl, C++, or any other high-level languages.
(It'd be possible to design a specific language to make it easier to
describe the state machine, than in a general purpose language like C,
making it possible to less programming-proficient users to change the
keyboard behaviours.)
Vojtech> Care to name any? Everything from raw SCSI handling to
Vojtech> presenting files to processes is done in the
Vojtech> kernel.
So, raw access is still available, just in case the kernel code
developers' imaginations are exceeded in some applications.
>> If you think those are kernel jobs, then you have an argument
>> for implementing Ghostscript completely in kernel, so that we
>> can cat mythesis.ps > /dev/psprinter, whether or not my printer
>> is a Postscript printer, and whether or not it is connected
>> locally or remotely, right?
Vojtech> Good argument. There are limits of what makes sense to do
Vojtech> in the kernel. Ghostscript is easier to do in userspace,
Vojtech> because it needs access to fonts, has a nontrivial
Vojtech> configuration, isn't time critical, etc. Good candidate
Vojtech> for userspace.
Keyboard and mouse drivers are also easier to do in userspace, because
that makes access to keymaps, mouse protocol modules, etc. easier.
Neither do I think keyboard/mouse drivers are time critical enough to
be absolutely placed in kernel space. Human beings do not work in
units of milliseconds.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:18 ` Vojtech Pavlik
@ 2004-05-30 11:40 ` Sau Dan Lee
2004-05-30 11:53 ` Russell King
` (2 more replies)
0 siblings, 3 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 11:40 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
Vojtech> Q2: What application should be looking at the raw data
Vojtech> outside the kernel and why?
>> What application should be looking at the raw data from an
>> RS232 port outside the kernel and why?
Vojtech> Terminal. Terminals use the data directly.
Now, what prevents people from connecting terminals to a computer via
the PS/2 mouse port?
There are mice which can be attached to both the RS232 port AND the
PS/2 mouse port, needing only an adaptor. It should also be possible
to use a similar technique to connect a terminal to the PS/2 mouse
port. This would be useful when you run out of RS232 ports.
Your approach in the input system completely rules out this
possibility.
Vojtech> Anyway, the RS232 port is a multi purpose port, where you
Vojtech> can attach many different devices to it. For the keyboard
Vojtech> port, there is only one option, the keyboard.
What a big assumption. Yes, I admit that I don't know of any hardware
implementations that use the PS/2 (or AT) keyboard port for other
purposes. Maybe there are POS systems like that?
Vojtech> Of course, unless you create a device that can use it,
Vojtech> but in that case you can easily write a kernel driver for
Vojtech> it.
How about the PS/2 mouse port? It's not just for mice. There ARE
implementations using it for other things: touchpad, touchscreen, etc.
Your input driver places that stupid assumption that there can't be
other devices outside your support list that may use the PS/2 mouse
port, and you make the stupid assumption on HOW the port should be
used. That's within your imaginations. You're limiting other people
to your own imaginations. Worse still, there are ALREADY things
beyond your imaginations.
>> In a nutshell, I hate to be restricted by YOUR own imaginations
>> of how people should hack the system.
Vojtech> You're not. You're free to hack the kernel drivers.
Not everyone using Linux is patient enough to explore the Wonderland
of kernel hacking. Many immigrants from 2.4 are highly disappointed
by the new but incompatible mouse/keyboard behaviours. Some of them
returned to their 2.4 homeland because of this.
Not every new immigrant are that devoted to make the new country good.
Many simply hop back to the original country, or hop to another that
_may_ suit them better.
>> Raw keyboard data, for instance, can be captured for analyzing
>> how people use the keyboard and coming up with a more efficient
>> keyboard layout (c.f. Dvorak). That's already beyond your
>> imaginations.
Vojtech> The raw data not what you want to use there. You want the
Vojtech> keystroke data,
No. I want the raw bytes. (That's also useful for debugging a
hardware, in case people are making or experimenting with new
hardware.)
Vojtech> and for that you can use the /dev/input/event interface,
But that's polluted with some (0,0,0) events. In some situations, I
NEED the raw, uninterpreted bytes, much like people liking to watch a
film or read a book in the *original* language version, not a dubbed
or translated version.
Vojtech> where you get them in a sane format (as opposed to the
Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
Vojtech> keystroke).
Sane != helpful or more useful.
I could study the I-Ching in English, but I would prefer to do it in
Chinese. Now, your approach is forcing me to do it in English. And
you believe that's a good idea.
Vojtech> Then your statistic analyser will work just fine even on
Vojtech> a Sun, Mac, or with an USB keyboard.
But it will not be able to handle the specifics. (That's the problem
with generic tools in general. But you shouldn't be restricting
people to only those tools. Some people have specific needs, and they
should not be ignored.)
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:25 ` Sau Dan Lee
@ 2004-05-30 11:40 ` Brad Campbell
2004-05-30 12:01 ` Oliver Neukum
` (2 subsequent siblings)
3 siblings, 0 replies; 80+ messages in thread
From: Brad Campbell @ 2004-05-30 11:40 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Vojtech Pavlik, Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
Sau Dan Lee wrote:
>
> Once in kernel space, forever in kernel space? What's the logic?
>
> Where it is now possible to move it out of kernel space WITHOUT
> performance problems, why not move it out?
I'd just like to comment on this particular point.
One application I have used utilises the keyboard as a trigger for audio processing and lighting
control. Having the keyboard processed in the kernel gives me pretty precise timing and low latency.
(Think setting CUE points in audio tracks. 10ms matters!). I'm not going to get that with a
userspace keyboard driver. Timing is still a little jittery, but then Linux is not a RTOS, but with
the driver in userspace I'm going to get a whole lot worse response for input events.
If you want to move the keyboard processing in userspace, why not just start with a microkernel.
There has to be a kernel/user line somewhere, and the grey areas are always going to be subject to
discussion.
Brad
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
[not found] ` <20040530112138.GC1377@ucw.cz>
@ 2004-05-30 11:43 ` Sau Dan Lee
2004-05-30 12:45 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 11:43 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
Vojtech> On Sun, May 30, 2004 at 12:50:05PM +0200, Sau Dan Lee
Vojtech> wrote:
>> >> But apart from such debugging use, there is also the more
>> >> direct use: in order to assign a keycode to an unusual key one
>> >> first asks for the scancode using scancode -s, and then
>> >> assigns the keycode using setkeycodes. If scancode -s lies,
>> >> this fails.
>>
Vojtech> That's a good reason. I'll implement true rawmode
Vojtech> support.
>> How about mouse?
Vojtech> Not planned yet. If you can modify your driver to be able
Vojtech> to coexist with the kernel mouse drivers, like for
Vojtech> example SCSI drivers can, then I can include it as
Vojtech> well. But I've not yet found a simple way to do that.
My driver (psmouse.tgz) can already coexist with the kernel one. The
SERIO_USERDEV patch is also designed to work _hands in hands_ with
your kernel-space drivers.
I'm quite disappointed that you are still not aware of that. Sigh...
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:40 ` Sau Dan Lee
@ 2004-05-30 11:53 ` Russell King
2004-05-30 12:43 ` Vojtech Pavlik
2004-06-04 14:11 ` Pavel Machek
2 siblings, 0 replies; 80+ messages in thread
From: Russell King @ 2004-05-30 11:53 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Vojtech Pavlik, linux-kernel
On Sun, May 30, 2004 at 01:40:03PM +0200, Sau Dan Lee wrote:
> Now, what prevents people from connecting terminals to a computer via
> the PS/2 mouse port?
Apart from electrically blowing the PS/2 port, the data format of PS/2
is well defined and fixed, whereas a UART (8250-based) port is more
flexible. PS/2 also has the idea of acknowledgement from the peripheral
device for each byte transferred, and is synchronous, whereas UARTs
have no acknowledgement and are asyncrhonous.
So, any thought that the two ports are similar compatible with each other,
either from the electrical or protocol points of view is just a dead loss.
How do these mice work on both ports then? They can detect which port
they're connected to and the electronics inside automatically configures
itself depending on which port they're connected to.
> Your approach in the input system completely rules out this
> possibility.
As from above, its more than just the input system - its the protocol
and electrical characteristics which completely rules out the
possibility - which in turn makes it nonsensible to support such an
idea in software.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:25 ` Sau Dan Lee
2004-05-30 11:40 ` Brad Campbell
@ 2004-05-30 12:01 ` Oliver Neukum
2004-05-30 12:22 ` Sau Dan Lee
2004-05-30 12:16 ` Vojtech Pavlik
2004-06-04 13:58 ` Pavel Machek
3 siblings, 1 reply; 80+ messages in thread
From: Oliver Neukum @ 2004-05-30 12:01 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Vojtech Pavlik, Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
Am Sonntag, 30. Mai 2004 13:25 schrieb Sau Dan Lee:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>
> >> >> What I hate is only the part where mouse/keyboard drivers
> >> >> are now in kernel space. The translation of raw byte
> >> >> streams into input events should be better done in userland.
> >> >> One important argument is: userland program may be swapped
> >> >> out. Kernel modules can't.
> >>
>
> Vojtech> Well, keyboard support was always in the kernel
>
> Once in kernel space, forever in kernel space? What's the logic?
>
> Where it is now possible to move it out of kernel space WITHOUT
> performance problems, why not move it out?
Two reasons: security and robustness.
1. sysreq must work, always work. Ideally you even do the dump
in hard irq. USB has been modified to support this.
2. A true SAK key must be processed in kernel space
There are additional reasons that make it nice to have a kernel driver,
but these reasons make it necessary.
> Vojtech> - you need it there, because you need the keyboard
> Vojtech> always to work
>
> Then, why make 'i8042' and 'atkbd' modules? I still remember reading
> web pages that early pioneers who migrated from 2.4 to 2.6.0-test*
> encountered a problem: they didn't compile-in these modules, and hence
> the system boot up without a responding keyboard. Despite that, the
> system does work and daemons are running!
>
> So, why is a the keyboard need to always work?
>
>
> I've been testing 'i8042' module and my atkbd driver (and the
> SERIO_USERDEV patch) through the network. I've been doing 'rmmod
> i8042' many many times. The system DOES work without that module (and
> keyboard functionality). Why are you saying that "you need the
> keyboard always to work"? Again, is that the limit of your
> imagination?
It does not support all features it is supposed to without that module.
There's nothing preventing you from using uinput if you want to. But full
function needs a kernel driver, either statically compiled or as a loaded
module.
Regards
Oliver
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:25 ` Sau Dan Lee
2004-05-30 11:40 ` Brad Campbell
2004-05-30 12:01 ` Oliver Neukum
@ 2004-05-30 12:16 ` Vojtech Pavlik
2004-05-30 12:40 ` Sau Dan Lee
2004-06-04 13:58 ` Pavel Machek
3 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 12:16 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
On Sun, May 30, 2004 at 01:25:24PM +0200, Sau Dan Lee wrote:
> Vojtech> Well, keyboard support was always in the kernel
>
> Once in kernel space, forever in kernel space? What's the logic?
>
> Where it is now possible to move it out of kernel space WITHOUT
> performance problems, why not move it out?
Because it just works.
1) Upgrading the kernel will make your keyboard stop working. Noone has
installed your userspace daemons on the system.
2) The keyboard (and other input devices, so that you don't complain
about limiting this to the keyboard) should work without requiring
userspace to be running.
And, it works just fine in the kernel, doesn't take up any more space
than as a program, so why to move it out?
> Vojtech> - you need it there, because you need the keyboard
> Vojtech> always to work
>
> Then, why make 'i8042' and 'atkbd' modules? I still remember reading
> web pages that early pioneers who migrated from 2.4 to 2.6.0-test*
> encountered a problem: they didn't compile-in these modules, and hence
> the system boot up without a responding keyboard. Despite that, the
> system does work and daemons are running!
>
> So, why is a the keyboard need to always work?
This is getting really annoying. Let me rephrase it again:
I don't have a keyboard on every of my systems. But when I have it and I
have the driver running, I expect it to work. Regardless of what
happened to the system. Regardless of userspace programs dying. Just
work.
> I've been testing 'i8042' module and my atkbd driver (and the
> SERIO_USERDEV patch) through the network. I've been doing 'rmmod
> i8042' many many times. The system DOES work without that module (and
> keyboard functionality). Why are you saying that "you need the
> keyboard always to work"? Again, is that the limit of your
> imagination?
Yes. The system doesn't need the keyboard drivers to function. The user
does.
> Are you aware of the i8042_shutdown bug, which I discovered and fixed?
> How could I have found such a bug, if "keyboard has to always work"?
Thanks for the fix.
> And how about mouse drivers? They used to be in userland (gpm,
> XFree86 3.x -- 4.x, etc.) Why move it into the kernel?
You wanted to use a mouse click to dump registers?
> Vojtech> I meant that keyboard handling was never done in
> Vojtech> userspace.
>
> OK. Then, it's time to consider moving it to userspace.
I'm not interested.
I'd have an interesting idea for you, though: If you want moving stuff
to userspace, move the whole console there. The font handling, the
keymap handling, colors, resolution, all that.
Just a simple program that uses the evdev interface to get the keyboard
data for input, the fbdev interface for output, and the pty interface to
communicate with the system.
Now *that* would be a great project moving stuff to userspace.
> Vojtech> Of course it is modular now, but that still counts as 'in
> Vojtech> the kernel'.
>
> How about my atkbd.c?
It's in userspace. It's not running in the kernel space. It's subject to
the scheduler and swapping. It doesn't react to interrupts immediately.
I think that's quite clear.
> Vojtech> ;) On embedded systems, or when you have an USB
> Vojtech> keyboard, you can leave the whole PS/2 stuff out.
>
> Is it impossible to run daemons driving the keyboard (my atkbd.c,
> should be invoked from inittab) and mouse (e.g. gpm) on embedded
> systems? I mean, why MUST the keyboard and mouse drivers be in kernel
> space?
Of course it's possible. There is not much that'd be impossible in
operating systems. It's not convenient, that's all.
> Vojtech> But still, if you have a working keyboard, the handling
> Vojtech> is done in the kernel, and you can do a register dump,
> Vojtech> process listing, etc, even when the system is
> Vojtech> crashed.
>
> Why just the keyboard? For that purpose, we can use mouse buttons,
> the power button, a joystick button, or even a home-brewed button
> connected to the RS232 port or parallel port. Why *limit* that to the
> keyboard?
Use whatever device you wish. I don't restrict you to just the keyboard.
The above argument works for a mouse, for a joystick, for an infrared
remote all the same.
> Vojtech> You wouldn't be able to do that if the processing of the
> Vojtech> byte stream was done in an userspace program.
>
> Isn't it possible to monitor the kernel via a tty connected to the
> serial line?
It is. Surprise, the SAK and SysRq handling for that is done
_in_the_kernel_, because it doesn't want to depend on userspace.
> Vojtech> - even in the case of a crash, when all userspace
> Vojtech> programs may already be dead.
> >> There are still RS232 ports and the network.
>
> Vojtech> Sure. How convenient it is to have to find an RS232
> Vojtech> cable, when your keyboard is just next to you on the
> Vojtech> table?
>
> The keyboard should be made an *option*, not a *requirement* for that.
> As an optional feature, yo shouldn't assume it for granted.
It IS an option, not a requirement. But I WANT THE OPTION. If the
keyboard handling is in userspace, I don't have the option of pressing a
key combination and getting a register dump, because the daemon doing
the processing may be dead already.
> Vojtech> It can. But if your userspace is dead, you cannot run
> Vojtech> that program. And that's usually when you need sysrq.
>
> So, why limit that to the keyboard only? Why can't my LED lid switch
> do it?
Go ahead. It's just a matter of adding a few lines to the ACPI drivers,
registering the lid switch as an input device.
> >> Is that "improvement" significant for 1200 baud devices? Even
> >> on a 386DX-33?
>
> Vojtech> Yes. Very much significant. Exactly because they're
> Vojtech> running at 1200 baud, you need get most of that little
> Vojtech> data they're sending to you.
>
> I don't understand this. The slower a device is, the lesser is the
> need to handle the incoming data in kernel space. I can't understand
> how 1200baud is fast enough to cause significant delays. Maybe, you
> can enlighten me on that?
> Yeah. At what rate are they arriving? 1200baud. Let's say that'
> 9600bps. So, 1200 bytes per second. 1 byte in every 833
> microseconds. How come a processor at 33MHz (0.030 microseconds per
> clock cycle) cannot cope with that? Assuming that the processing of
> the data plus context switching plus other overhead taks 1000
> microseconds, that still shouldn't be felt by a HUMAN user. Who has a
> reaction time of less than 100 _milli_seconds?
Can you say swap?
> Vojtech> Yes, it does. Because it uses the _kernel_ input system
> Vojtech> to do the interfacing work. But I don't see any benefit
> Vojtech> of having to go to userspace and back again into the
> Vojtech> kernel.
>
> Flexibility. The keyboard driver can talk to another machine via a
> TCP connection, for instance. The keyboard driver can be easily
> modified and debugged -- all in user space -- without hanging the
> kernel due to stupid bugs (e.g. NULL pointers). The keyboard driver
> could be prototyped in Perl, C++, or any other high-level languages.
> (It'd be possible to design a specific language to make it easier to
> describe the state machine, than in a general purpose language like C,
> making it possible to less programming-proficient users to change the
> keyboard behaviours.)
Go play with microkernel systems. You'll meet people with similar views
there. Linux is not a microkernel, though.
> Vojtech> Care to name any? Everything from raw SCSI handling to
> Vojtech> presenting files to processes is done in the
> Vojtech> kernel.
>
> So, raw access is still available, just in case the kernel code
> developers' imaginations are exceeded in some applications.
Yes, and it's good. And I don't object to having raw access available. I
really don't. I just want to have it done in a sane way that doesn't
conflict with the kernel drivers. Like in SCSI.
> Vojtech> Good argument. There are limits of what makes sense to do
> Vojtech> in the kernel. Ghostscript is easier to do in userspace,
> Vojtech> because it needs access to fonts, has a nontrivial
> Vojtech> configuration, isn't time critical, etc. Good candidate
> Vojtech> for userspace.
>
> Keyboard and mouse drivers are also easier to do in userspace, because
> that makes access to keymaps, mouse protocol modules, etc. easier.
> Neither do I think keyboard/mouse drivers are time critical enough to
> be absolutely placed in kernel space. Human beings do not work in
> units of milliseconds.
The keyboard and mouse drivers don't handle keymaps. Those are handled
in the console. The keyboard/mouse drivers are not necessarily _time_
critical, but they're critical. When your keyboard stops working, this
often means your system is dead. (Think a laptop on an airplane.)
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:01 ` Oliver Neukum
@ 2004-05-30 12:22 ` Sau Dan Lee
2004-05-30 12:32 ` Oliver Neukum
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 12:22 UTC (permalink / raw)
To: Oliver Neukum
Cc: Vojtech Pavlik, Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
>>>>> "Oliver" == Oliver Neukum <oliver@neukum.org> writes:
>> Where it is now possible to move it out of kernel space WITHOUT
>> performance problems, why not move it out?
Oliver> Two reasons: security and robustness.
Oliver> 1. sysreq must work, always work. Ideally you even do the
Oliver> dump in hard irq. USB has been modified to support this.
It doesn't always work. Try to compile 'i8042' and 'atkbd' as
modules. rmmod one of them, and voila: SysRq doesn't work anymore.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:22 ` Sau Dan Lee
@ 2004-05-30 12:32 ` Oliver Neukum
0 siblings, 0 replies; 80+ messages in thread
From: Oliver Neukum @ 2004-05-30 12:32 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Vojtech Pavlik, Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
Am Sonntag, 30. Mai 2004 14:22 schrieb Sau Dan Lee:
> >>>>> "Oliver" == Oliver Neukum <oliver@neukum.org> writes:
>
> >> Where it is now possible to move it out of kernel space WITHOUT
> >> performance problems, why not move it out?
>
> Oliver> Two reasons: security and robustness.
>
> Oliver> 1. sysreq must work, always work. Ideally you even do the
> Oliver> dump in hard irq. USB has been modified to support this.
>
> It doesn't always work. Try to compile 'i8042' and 'atkbd' as
> modules. rmmod one of them, and voila: SysRq doesn't work anymore.
Yes. Remove the driver for your root fs and, lo, the kernel will panic.
You must not confuse kernel and user space. The notion that drivers
can be compiled into modules is not exactly new. In which context they
run is the all important question.
Oliver
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:16 ` Vojtech Pavlik
@ 2004-05-30 12:40 ` Sau Dan Lee
2004-05-30 12:52 ` Vojtech Pavlik
` (2 more replies)
0 siblings, 3 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 12:40 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>> Where it is now possible to move it out of kernel space WITHOUT
>> performance problems, why not move it out?
Vojtech> Because it just works.
Vojtech> 1) Upgrading the kernel will make your keyboard stop
Vojtech> working. Noone has installed your userspace daemons on
Vojtech> the system.
Many people has already fallen into this trap with YOUR input system:
they didn't know they had to enable the 'i8042' and 'atkbd' features,
or they did but made them modules and didn't have any clue to insmod
them in the bootup scripts.
Most package maintainers put dependencies in their 2.6 kernel image
packages to force the user to also install module-init-tools. I can't
see why that couldn't be done for userspace daemons.
Vojtech> 2) The keyboard (and other input devices, so that you
Vojtech> don't complain about limiting this to the keyboard)
Vojtech> should work without requiring userspace to be running.
Is a network interface an input device? Or do you just mean HID?
USB devices (including USB keyboards and mice) require hot-plug (or
similar mechanisms) to load the corresponding modules before they can
work. Both /sbin/hotplug and /sbin/modprobe on my system are
userspace programs.
Vojtech> And, it works just fine in the kernel, doesn't take up
Vojtech> any more space than as a program, so why to move it out?
To leave more *swappable* RAM to userspace.
Vojtech> This is getting really annoying. Let me rephrase it
Vojtech> again:
Vojtech> I don't have a keyboard on every of my systems. But when
Vojtech> I have it and I have the driver running, I expect it to
Vojtech> work.
So, you need to have a DRIVER running. How does putting the driver
into kernel space make it different (for this argument)?
Vojtech> Regardless of what happened to the system. Regardless of
Vojtech> userspace programs dying. Just work.
Userspace programs can die. Kernelspace code can Oops. Which is
easier to recover? What happens when getty dies and how to recover?
What happens when some kernel code oops? Do you lose data (held in
RAM by other apps) in these cases?
Vojtech> Yes. The system doesn't need the keyboard drivers to
Vojtech> function. The user does.
I don't, when I'm accessing via means other than a keyboard.
>> Are you aware of the i8042_shutdown bug, which I discovered and
>> fixed? How could I have found such a bug, if "keyboard has to
>> always work"?
Vojtech> Thanks for the fix.
I've been reporting this bug for 2.6.6 and 2.6.7-rc1, and it still
hasn't been included in 2.6.7-rc2. What's happening? Should I report
it again for 2.6.7-rc2?
>> And how about mouse drivers? They used to be in userland (gpm,
>> XFree86 3.x -- 4.x, etc.) Why move it into the kernel?
Vojtech> You wanted to use a mouse click to dump registers?
GPM can be configured to do it, given that the SysRq feature can now
be triggered from userland.
Vojtech> I'd have an interesting idea for you, though: If you want
Vojtech> moving stuff to userspace, move the whole console
Vojtech> there. The font handling, the keymap handling, colors,
Vojtech> resolution, all that.
Vojtech> Just a simple program that uses the evdev interface to
Vojtech> get the keyboard data for input, the fbdev interface for
Vojtech> output, and the pty interface to communicate with the
Vojtech> system.
I've never used fbdev. I don't plan to use it on any PC-type
machines. It's so slow. I prefer the (S)VGA text modes and
accelerated X11 drivers.
Vojtech> Now *that* would be a great project moving stuff to
Vojtech> userspace.
But that restricts to fbdev.
Vojtech> It's in userspace. It's not running in the kernel
Vojtech> space. It's subject to the scheduler and swapping. It
Vojtech> doesn't react to interrupts immediately. I think that's
Vojtech> quite clear.
Swappable is one of the features that I want. I often use my machines
via X11 from one desktop computer. If the keyboard driver has been
dormant for a long time, I'd prefer it to be swapped out, so as to
free up some RAM for other programs.
If you don't want it to be swappable, you can add some mlock() calls.
You don't have this *choice* for the kernel-space drivers.
Vojtech> Of course it's possible. There is not much that'd be
Vojtech> impossible in operating systems. It's not convenient,
Vojtech> that's all.
Now, it becomes a convenience issue, rather than a necessity issue.
Vojtech> It IS an option, not a requirement. But I WANT THE
Vojtech> OPTION. If the keyboard handling is in userspace, I don't
Vojtech> have the option of pressing a key combination and getting
Vojtech> a register dump,
Why not?
Vojtech> because the daemon doing the processing may be dead
Vojtech> already.
"may be". So, it's not always.
>> I don't understand this. The slower a device is, the lesser
>> is the need to handle the incoming data in kernel space. I
>> can't understand how 1200baud is fast enough to cause
>> significant delays. Maybe, you can enlighten me on that?
>> Yeah. At what rate are they arriving? 1200baud. Let's say
>> that' 9600bps. So, 1200 bytes per second. 1 byte in every 833
>> microseconds. How come a processor at 33MHz (0.030
>> microseconds per clock cycle) cannot cope with that? Assuming
>> that the processing of the data plus context switching plus
>> other overhead taks 1000 microseconds, that still shouldn't be
>> felt by a HUMAN user. Who has a reaction time of less than 100
>> _milli_seconds?
Vojtech> Can you say swap?
Can you say mlock()?
Vojtech> The keyboard and mouse drivers don't handle
Vojtech> keymaps. Those are handled in the console. The
Vojtech> keyboard/mouse drivers are not necessarily _time_
Vojtech> critical, but they're critical. When your keyboard stops
Vojtech> working, this often means your system is dead. (Think a
Vojtech> laptop on an airplane.)
I've used my laptop in an airplane, and it works without problems.
What would make the keyboard stop working in an airplane?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:40 ` Sau Dan Lee
2004-05-30 11:53 ` Russell King
@ 2004-05-30 12:43 ` Vojtech Pavlik
2004-05-30 13:25 ` Sau Dan Lee
2004-05-30 13:54 ` Eduard Bloch
2004-06-04 14:11 ` Pavel Machek
2 siblings, 2 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 12:43 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: linux-kernel
On Sun, May 30, 2004 at 01:40:03PM +0200, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>
> Vojtech> Q2: What application should be looking at the raw data
> Vojtech> outside the kernel and why?
> >> What application should be looking at the raw data from an
> >> RS232 port outside the kernel and why?
>
> Vojtech> Terminal. Terminals use the data directly.
>
> Now, what prevents people from connecting terminals to a computer via
> the PS/2 mouse port?
Their sanity.
Anyway, I don't oppose having the raw data available.
> There are mice which can be attached to both the RS232 port AND the
> PS/2 mouse port, needing only an adaptor. It should also be possible
> to use a similar technique to connect a terminal to the PS/2 mouse
> port. This would be useful when you run out of RS232 ports.
Go ahead and try it. You'll fry your KBD port.
> Your approach in the input system completely rules out this
> possibility.
Not such a big loss.
> Vojtech> Anyway, the RS232 port is a multi purpose port, where you
> Vojtech> can attach many different devices to it. For the keyboard
> Vojtech> port, there is only one option, the keyboard.
>
> What a big assumption. Yes, I admit that I don't know of any hardware
> implementations that use the PS/2 (or AT) keyboard port for other
> purposes. Maybe there are POS systems like that?
No. The KBD interface is asymetric, only works on short distances, is
slow, cannot pass arbitrary data through, as it's by default translated
by the keyboard contoller, already assuming it's sending keyboard data,
all in all, it's completely unsuitable for anything else than a
keyboard.
You even cannot connect a mouse over it in the default mode of the port.
> Vojtech> Of course, unless you create a device that can use it,
> Vojtech> but in that case you can easily write a kernel driver for
> Vojtech> it.
>
> How about the PS/2 mouse port? It's not just for mice. There ARE
> implementations using it for other things: touchpad, touchscreen, etc.
All simulate a mouse. Some have somewhat extended protocols, but those
protocols are still bound by mouse packet constraints, because the
controllers tend to do nasty things to the data passing through, like
merging input from multiple devices together into one stream by summing
the packets, etc.
> Your input driver places that stupid assumption that there can't be
> other devices outside your support list that may use the PS/2 mouse
> port, and you make the stupid assumption on HOW the port should be
> used. That's within your imaginations. You're limiting other people
> to your own imaginations. Worse still, there are ALREADY things
> beyond your imaginations.
No. I'm just saying - if you want something that's not in the kernel
drivers, just write a driver for it. But the driver must be able to
coexist with the other drivers.
Your psaux/userspace serio driver is fine, except it cannot coexist with
the other drivers.
> Not everyone using Linux is patient enough to explore the Wonderland
> of kernel hacking. Many immigrants from 2.4 are highly disappointed
> by the new but incompatible mouse/keyboard behaviours. Some of them
> returned to their 2.4 homeland because of this.
Life's a change.
Anyway, at least 99% setups just keep working in 2.6.
> Not every new immigrant are that devoted to make the new country good.
> Many simply hop back to the original country, or hop to another that
> _may_ suit them better.
That's their freedom to do.
> >> Raw keyboard data, for instance, can be captured for analyzing
> >> how people use the keyboard and coming up with a more efficient
> >> keyboard layout (c.f. Dvorak). That's already beyond your
> >> imaginations.
>
> Vojtech> The raw data not what you want to use there. You want the
> Vojtech> keystroke data,
>
> No. I want the raw bytes. (That's also useful for debugging a
> hardware, in case people are making or experimenting with new
> hardware.)
Sure. For debugging purposes, yes. But for analyzing the typing
behavior, the abstract data is better.
> Vojtech> and for that you can use the /dev/input/event interface,
>
> But that's polluted with some (0,0,0) events. In some situations, I
> NEED the raw, uninterpreted bytes, much like people liking to watch a
> film or read a book in the *original* language version, not a dubbed
> or translated version.
Polluted. ;) Sorry, they're intentional. They're EV_SYN, SYN_REPORT
events, as you can find in input.h. They inform you that this is the end
of the whole report, which is useful for example for mice, where you
have more than one event (REL_X, REL_Y) per a report.
The application reading the device is supposed to queue all events up to
the SYN_REPORT event, and then process them, so that a mouse pointer
will move diagonally instead of following the sides of a rectangle,
which would be very annoying.
>
> Vojtech> where you get them in a sane format (as opposed to the
> Vojtech> PS/2 rawmode, which can send up ot 8 bytes for a single
> Vojtech> keystroke).
>
> Sane != helpful or more useful.
>
> I could study the I-Ching in English, but I would prefer to do it in
> Chinese. Now, your approach is forcing me to do it in English. And
> you believe that's a good idea.
In your example, you wanted to study the frequency of keypresses, and
their relations. For that, it's best to ask the kernel to report
keypresses to you.
Should you want to analyze the keyboard protocol, the raw data is the
way to go. But that's been done many times before anyway.
> Vojtech> Then your statistic analyser will work just fine even on
> Vojtech> a Sun, Mac, or with an USB keyboard.
>
> But it will not be able to handle the specifics. (That's the problem
> with generic tools in general. But you shouldn't be restricting
> people to only those tools. Some people have specific needs, and they
> should not be ignored.)
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:43 ` Sau Dan Lee
@ 2004-05-30 12:45 ` Vojtech Pavlik
2004-05-30 13:25 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 12:45 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: linux-kernel
On Sun, May 30, 2004 at 01:43:24PM +0200, Sau Dan Lee wrote:
> My driver (psmouse.tgz) can already coexist with the kernel one. The
> SERIO_USERDEV patch is also designed to work _hands in hands_ with
> your kernel-space drivers.
>
> I'm quite disappointed that you are still not aware of that. Sigh...
The last time I saw it, it wasn't able of that. Where I can find the
updated version?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:40 ` Sau Dan Lee
@ 2004-05-30 12:52 ` Vojtech Pavlik
2004-05-30 16:09 ` Stefan Seyfried
2004-05-30 17:26 ` Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 12:52 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
On Sun, May 30, 2004 at 02:40:31PM +0200, Sau Dan Lee wrote:
> > The keyboard/mouse drivers are not necessarily _time_ critical, but
> > they're critical. When your keyboard stops working, this often
> > means your system is as good as dead. (Think a laptop on an
> > airplane.)
>
> I've used my laptop in an airplane, and it works without problems.
> What would make the keyboard stop working in an airplane?
This discussion is futile. Bye.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:43 ` Vojtech Pavlik
@ 2004-05-30 13:25 ` Sau Dan Lee
2004-06-01 21:01 ` jsimmons
2004-05-30 13:54 ` Eduard Bloch
1 sibling, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 13:25 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>> How about the PS/2 mouse port? It's not just for mice. There
>> ARE implementations using it for other things: touchpad,
>> touchscreen, etc.
Vojtech> All simulate a mouse.
Yeah. All can fall back to PS/2 mouse emulation mode. But to enable
the extended features, you need to write to the port to enable them,
and then interpret the extended data formats.
Vojtech> No. I'm just saying - if you want something that's not in
Vojtech> the kernel drivers, just write a driver for it. But the
Vojtech> driver must be able to coexist with the other drivers.
It's easier to write a mouse driver in userspace than in kernel. But
with the input system in 2.6, I am *forced* to write it in kernel
space, and reboot and reboot and reboot when it oops. Writing the
driver in kernel space, I at most get a segfault. Plus I cannot use
everything from glibc. It simply takes more time and energy to write
a kernel space driver.
Vojtech> Your psaux/userspace serio driver is fine, except it
Vojtech> cannot coexist with the other drivers.
That's why I've abandoned it. It's obsolete.
Our (Tuukka and I) SERIO_USERDEV patch does work with kernel drivers,
and allow both kernel and userland drivers to coexist. Again, I'm
disappointed that you still haven't discovered this.
Now, it's time for you to try our SERIO_USERDEV patch, plus my crude
userspace atkbd.c and psmouse drivers.
Vojtech> Anyway, at least 99% setups just keep working in 2.6.
But not 100% compatibly. Mouse moving twice as fast, mouse not
accelerating, etc. And tp4d not working any more. And touch screen
not working. ...
Vojtech> The raw data not what you want to use there. You want the
Vojtech> keystroke data,
>> No. I want the raw bytes. (That's also useful for debugging
>> a hardware, in case people are making or experimenting with new
>> hardware.)
Vojtech> Sure. For debugging purposes, yes. But for analyzing the
Vojtech> typing behavior, the abstract data is better.
It depends on what level I want to analyze at. How come you have a
crystal ball telling you that you know what I want?
>> I could study the I-Ching in English, but I would prefer to do
>> it in Chinese. Now, your approach is forcing me to do it in
>> English. And you believe that's a good idea.
Vojtech> In your example, you wanted to study the frequency of
Vojtech> keypresses, and their relations. For that, it's best to
Vojtech> ask the kernel to report keypresses to you.
No. The kernel has already translated the data.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:45 ` Vojtech Pavlik
@ 2004-05-30 13:25 ` Sau Dan Lee
0 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-05-30 13:25 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
Vojtech> On Sun, May 30, 2004 at 01:43:24PM +0200, Sau Dan Lee
Vojtech> wrote:
>> My driver (psmouse.tgz) can already coexist with the kernel
>> one. The SERIO_USERDEV patch is also designed to work _hands
>> in hands_ with your kernel-space drivers.
>>
>> I'm quite disappointed that you are still not aware of that.
>> Sigh...
Vojtech> The last time I saw it, it wasn't able of that. Where I
Vojtech> can find the updated version?
See the previous mails on this thread. I've been giving URLs of the
SERIO_USERDEV patch as well as my userspace drivers a few times.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:43 ` Vojtech Pavlik
2004-05-30 13:25 ` Sau Dan Lee
@ 2004-05-30 13:54 ` Eduard Bloch
2004-05-30 14:03 ` Vojtech Pavlik
1 sibling, 1 reply; 80+ messages in thread
From: Eduard Bloch @ 2004-05-30 13:54 UTC (permalink / raw)
To: linux-kernel
Moin Vojtech!
Vojtech Pavlik schrieb am Sonntag, den 30. Mai 2004:
> > Vojtech> Of course, unless you create a device that can use it,
> > Vojtech> but in that case you can easily write a kernel driver for
> > Vojtech> it.
> >
> > How about the PS/2 mouse port? It's not just for mice. There ARE
> > implementations using it for other things: touchpad, touchscreen, etc.
>
> All simulate a mouse. Some have somewhat extended protocols, but those
> protocols are still bound by mouse packet constraints, because the
> controllers tend to do nasty things to the data passing through, like
> merging input from multiple devices together into one stream by summing
> the packets, etc.
Who says that merging (as it is currently done) is the best way to do?
For examle, I wish to create two terminals with my system, using two
monitors (on dual-head video card), two keyboards and two mices. I can
do the first part (X manages it well) but not beeing able to use
different input devices for different users simply SUCKS.
But http://linuxconsole.sourceforge.net/ lets me hope.
Regards,
Eduard.
--
Wenn ein Mensch ein Loch sieht, hat er das Bestreben, es auszufüllen.
Dabei fällt er meistens hinein.
-- Kurt Tucholsky
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 13:54 ` Eduard Bloch
@ 2004-05-30 14:03 ` Vojtech Pavlik
2004-06-01 21:03 ` jsimmons
0 siblings, 1 reply; 80+ messages in thread
From: Vojtech Pavlik @ 2004-05-30 14:03 UTC (permalink / raw)
To: Eduard Bloch; +Cc: linux-kernel
On Sun, May 30, 2004 at 03:54:45PM +0200, Eduard Bloch wrote:
> Moin Vojtech!
>
> Vojtech Pavlik schrieb am Sonntag, den 30. Mai 2004:
>
> > > Vojtech> Of course, unless you create a device that can use it,
> > > Vojtech> but in that case you can easily write a kernel driver for
> > > Vojtech> it.
> > >
> > > How about the PS/2 mouse port? It's not just for mice. There ARE
> > > implementations using it for other things: touchpad, touchscreen, etc.
> >
> > All simulate a mouse. Some have somewhat extended protocols, but those
> > protocols are still bound by mouse packet constraints, because the
> > controllers tend to do nasty things to the data passing through, like
> > merging input from multiple devices together into one stream by summing
> > the packets, etc.
>
> Who says that merging (as it is currently done) is the best way to do?
I definitely don't. But many notebooks do that in hardware.
My point was that it's not always possible to transfer arbitrary data
over the PS/2 port - it's not a general purpose serial port.
> For examle, I wish to create two terminals with my system, using two
> monitors (on dual-head video card), two keyboards and two mices. I can
> do the first part (X manages it well) but not beeing able to use
> different input devices for different users simply SUCKS.
> But http://linuxconsole.sourceforge.net/ lets me hope.
I wrote most of the input handling in that project. It's what is in 2.6 now.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:40 ` Sau Dan Lee
2004-05-30 12:52 ` Vojtech Pavlik
@ 2004-05-30 16:09 ` Stefan Seyfried
2004-05-30 17:26 ` Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Stefan Seyfried @ 2004-05-30 16:09 UTC (permalink / raw)
To: linux-kernel
On Sun, May 30, 2004 at 12:43:26PM +0000, Sau Dan Lee wrote:
> Now, it becomes a convenience issue, rather than a necessity issue.
> Why not?
> "may be". So, it's not always.
> Vojtech> Can you say swap?
>
> Can you say mlock()?
can you say "troll"?
> I've used my laptop in an airplane, and it works without problems.
> What would make the keyboard stop working in an airplane?
--
seife
"Any ideas, John?"
"Well, surrounding thems out."
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 12:40 ` Sau Dan Lee
2004-05-30 12:52 ` Vojtech Pavlik
2004-05-30 16:09 ` Stefan Seyfried
@ 2004-05-30 17:26 ` Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Dmitry Torokhov @ 2004-05-30 17:26 UTC (permalink / raw)
To: linux-kernel
Cc: Sau Dan Lee, Vojtech Pavlik, Giuseppe Bilotta, Tuukka Toivonen
On Sunday 30 May 2004 07:40 am, Sau Dan Lee wrote:
> >>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>
> >> Where it is now possible to move it out of kernel space WITHOUT
> >> performance problems, why not move it out?
>
> Vojtech> Because it just works.
>
> Vojtech> 1) Upgrading the kernel will make your keyboard stop
> Vojtech> working. Noone has installed your userspace daemons on
> Vojtech> the system.
>
> Many people has already fallen into this trap with YOUR input system:
> they didn't know they had to enable the 'i8042' and 'atkbd' features,
> or they did but made them modules and didn't have any clue to insmod
> them in the bootup scripts.
This was in development series (2.5) and was resolved by the time 2.6 came
out so I really do not think it's a valid complaint.
> Vojtech> 2) The keyboard (and other input devices, so that you
> Vojtech> don't complain about limiting this to the keyboard)
> Vojtech> should work without requiring userspace to be running.
>
> Is a network interface an input device? Or do you just mean HID?
>
> USB devices (including USB keyboards and mice) require hot-plug (or
> similar mechanisms) to load the corresponding modules before they can
> work. Both /sbin/hotplug and /sbin/modprobe on my system are
> userspace programs.
>
>
> Vojtech> And, it works just fine in the kernel, doesn't take up
> Vojtech> any more space than as a program, so why to move it out?
>
> To leave more *swappable* RAM to userspace.
>
On average it will take much more considering that you better have your
keyboard daemon linked statically and residing.. umm.. initrd? initramfs?
as you want your keyboard working very early.
> >> Yeah. At what rate are they arriving? 1200baud. Let's say
> >> that' 9600bps. So, 1200 bytes per second. 1 byte in every 833
> >> microseconds. How come a processor at 33MHz (0.030
> >> microseconds per clock cycle) cannot cope with that? Assuming
> >> that the processing of the data plus context switching plus
> >> other overhead taks 1000 microseconds, that still shouldn't be
> >> felt by a HUMAN user. Who has a reaction time of less than 100
> >> _milli_seconds?
>
> Vojtech> Can you say swap?
>
> Can you say mlock()?
>
I though you wanted the thing to be swapped out? Btw, what are you going
to mlock? Entirety of glibc?
--
Dmitry
^ permalink raw reply [flat|nested] 80+ messages in thread
* BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
2004-05-26 7:54 ` Sau Dan Lee
` (3 preceding siblings ...)
2004-05-28 19:57 ` keyboard problem with 2.6.6 Andries Brouwer
@ 2004-06-01 8:21 ` Sau Dan Lee
2004-06-01 9:13 ` BUG FIX: " Sau Dan Lee
[not found] ` <200406010904.i5194pSo010367@fire-2.osdl.org>
6 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-01 8:21 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Vojtech Pavlik, linux-kernel
Andries> Sau Dan Lee wrote:
>> Actually, I have a side issue with input/i8042 related things:
>> The keyboard on my laptop worked slightly different: On 2.4.*,
>> SysRq is activated using a [Fn] key-combo, which agrees with
>> the keycap labels on the laptop keyboard. After upgrading to
>> 2.6, that key-combo no longer works. Instead, I must use
>> Alt-PrintScreen as the key for SysRq. (And unfortunately,
>> PrintScreen is a [Fn] combo on the laptop, thus requiring press
>> 3 keys at the same time for SysRq, and a fourth key to use the
>> various SysRq features. Very inconvenient.) Is this again due
>> to some dirty translation processes down in the input layer?
>> Is the input layer always assuming that Alt-PrintScreen ==
>> SysRq? This is not always true. Can the input layer be so
>> configured that it never tries to interpret the scancodes, but
>> pass them to the upper layers?
Andries> So, what scancodes do you get in 2.4? And in 2.6? (Use
Andries> scancode -s.)
Here they are:
On Linux 2.4.*:
PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
SysRq: 0x54 0xd4
On Linux 2.6.*:
PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
SysRq: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
No wonder: "showkey -s" in 2.6.* is deceiving: it shows what an
emulated keyboard generates, not the *real* scancodes. Fortunately,
the SERIO_USERDEV patch is very very helpful here.
Using the SERIO_USERDEV patch from Tuukka Toivonen and me, the correct
scancodes are displayed:
On Linux 2.6.*: od -t x1 /dev/misc/isa0060/serio0
PrintScreen: 0xe0 0x2a 0xe0 0x37 0xe0 0xb7 0xe0 0xaa
SysRq: 0x54 0xd4
So, obviously, it is the fault of the Linux 2.6.* keyboard driver.
The story continues:
I've studied the 2.6 keyboard driver atkbd.c and found the bug: The
keyboard driver is UNABLE to distinguish SysRq and PrintScreen!!!
I've checked this with the help of the 'evbug' module. The driver
reports both keys to be KEY_SYSRQ, which is obviously wrong.
I've got a patch for this bug already. See Bugzilla #2808.
Relatedly, drivers/char/keyboard.c assumes that SysRq cannot be
activated unless the Alt key(s) is/are pressed (and not yet released).
I'm going to fix this. But since this not a module, I need to reboot
to test it. So, please be patient.
See http://bugzilla.kernel.org/show_bug.cgi?id=2808 for more info.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
2004-05-26 7:54 ` Sau Dan Lee
` (4 preceding siblings ...)
2004-06-01 8:21 ` BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6] Sau Dan Lee
@ 2004-06-01 9:13 ` Sau Dan Lee
[not found] ` <200406010904.i5194pSo010367@fire-2.osdl.org>
6 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-01 9:13 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Vojtech Pavlik, linux-kernel
Dan> Relatedly, drivers/char/keyboard.c assumes that SysRq cannot
Dan> be activated unless the Alt key(s) is/are pressed (and not
Dan> yet released). I'm going to fix this. But since this not a
Dan> module, I need to reboot to test it. So, please be patient.
Fixed. The patch is already added to Bugzilla.
Using these patches, the keyboard behaviour is correct again on my
notebook:
SysRq ==> Input Event with code KEY_SYSRQ
PrintScreen ==> Input Event with code KEY_KPASTERISK
(because PrintScreen is Alt-KP_ASTERISK)
SysRq SPACE gives sysrq help screen
Alt-PrintScreen SPACE gives sysrq help screen
PrintScreen SPACE gives "*" and no sysrq help screen
Dan> See http://bugzilla.kernel.org/show_bug.cgi?id=2808 for more
Dan> info.
Both patches are there at the Bugzilla site.
(BTW, why did Vojtech REJECT this bug report at Bugzilla? Give me a
reason! I do observe the bug and I have even found a fix.)
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
[not found] ` <200406010904.i5194pSo010367@fire-2.osdl.org>
@ 2004-06-01 9:44 ` Sau Dan Lee
2004-06-01 9:55 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-01 9:44 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Andries Brouwer, linux-kernel
>>>>> "bugme-daemon" == bugme-daemon <bugme-daemon@osdl.org> writes:
bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
bugme-daemon> vojtech@suse.cz changed:
bugme-daemon> What |Removed |Added
bugme-daemon> ----------------------------------------------------
bugme-daemon> Status|NEW |REJECTED
bugme-daemon> Resolution| |INVALID
Vojtech> I'm sorry you can't use the fn+printscreen function on
Vojtech> your LifeBook, but such is life.
Disappointed.
Vojtech> Is using Alt+printscreen such a big difference?
That means I need to press FOUR keys to use sysrq, because PrintScreen
is only available via [Fn]. That becomes [Fn]+Alt+PrintScreen+X,
where "X" is the sysrq function. :(
Vojtech> On USB keyboards (and many others, too), there is no
Vojtech> specific SysRq keycode, and thus the kernel magic-sysrq
Vojtech> handler uses the alt-printscreen combination, to make it
Vojtech> work on ALL keyboards. This is intentional.
Isn't the keyboard driver supposed to iron out such differences?
Isn't it your philosophy that the drivers should know the devices
well, and present a consistent interface to the upper layers? Then,
the correct way to do it is:
USB keyboard driver: generate a "sysrq" event in reaction to
Alt-PrintScreen
AT/PS2 keyboard driver: generate a "sysrq" when receiving a
0x54 keycode
The kernel keyboard handler shouldn't see or bother about the
difference. It is insane that the handler has to care about the
status of the Alt keys.
Vojtech> Further, keycode 99 is KEY_SYSRQ, as defined in input.h,
Then, why use it for PrintScreen? With the 'evbug' facility, I see a
keyboard event with code KEY_SYSRQ when I press PrintScreen. Just
PrintScreen, not Alt-PrintScreen. So, this is a feature and not a
bug?
Vojtech> and is used for the PrtScr/SysRq key.
So, why not have seperate keycodes for the two?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
2004-06-01 9:44 ` Sau Dan Lee
@ 2004-06-01 9:55 ` Vojtech Pavlik
2004-06-01 10:03 ` Sau Dan Lee
2004-06-01 12:42 ` Giuseppe Bilotta
0 siblings, 2 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-06-01 9:55 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Andries Brouwer, linux-kernel
On Tue, Jun 01, 2004 at 11:44:44AM +0200, Sau Dan Lee wrote:
> >>>>> "bugme-daemon" == bugme-daemon <bugme-daemon@osdl.org> writes:
>
> bugme-daemon> http://bugme.osdl.org/show_bug.cgi?id=2808
> bugme-daemon> vojtech@suse.cz changed:
>
> bugme-daemon> What |Removed |Added
> bugme-daemon> ----------------------------------------------------
> bugme-daemon> Status|NEW |REJECTED
> bugme-daemon> Resolution| |INVALID
>
> Vojtech> I'm sorry you can't use the fn+printscreen function on
> Vojtech> your LifeBook, but such is life.
>
> Disappointed.
>
> Vojtech> Is using Alt+printscreen such a big difference?
>
> That means I need to press FOUR keys to use sysrq, because PrintScreen
> is only available via [Fn]. That becomes [Fn]+Alt+PrintScreen+X,
> where "X" is the sysrq function. :(
>
>
> Vojtech> On USB keyboards (and many others, too), there is no
> Vojtech> specific SysRq keycode, and thus the kernel magic-sysrq
> Vojtech> handler uses the alt-printscreen combination, to make it
> Vojtech> work on ALL keyboards. This is intentional.
>
> Isn't the keyboard driver supposed to iron out such differences?
The atkbd.c driver does exactly that. It hides the fact that there is a
special scancode for the PrintScreen key, if you press it together with
some other keys.
There is no special scancode on any other keyboard type for it,
including PS/2 keyboards in their native Set3 mode.
It's a hack by IBM engineers, the PC/XT keyboard had a SysRq key, the
PC/AT keyboard did not, yet some old DOS programs needed it, so they
made the AT keyboard generate the keycode for alt-sysrq when running in
XT compatibility mode.
Unfortunately, the XT compatibility mode stuck, and that's what we're
using now.
> Isn't it your philosophy that the drivers should know the devices
> well, and present a consistent interface to the upper layers? Then,
> the correct way to do it is:
>
> USB keyboard driver: generate a "sysrq" event in reaction to
> Alt-PrintScreen
> AT/PS2 keyboard driver: generate a "sysrq" when receiving a
> 0x54 keycode
>
> The kernel keyboard handler shouldn't see or bother about the
> difference. It is insane that the handler has to care about the
> status of the Alt keys.
The kernel works with real keys. There is no real sysrq key. My
definition of sanity is to base your thinking on reality where possible.
> Vojtech> Further, keycode 99 is KEY_SYSRQ, as defined in input.h,
>
> Then, why use it for PrintScreen? With the 'evbug' facility, I see a
> keyboard event with code KEY_SYSRQ when I press PrintScreen. Just
> PrintScreen, not Alt-PrintScreen. So, this is a feature and not a
> bug?
Ok, it's probably a bad name for it, it should have been named
KEY_PRTSCR, but it wasn't, and it'd only cause breakage now to change
it.
> Vojtech> and is used for the PrtScr/SysRq key.
>
> So, why not have seperate keycodes for the two?
Because there is only one key.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
2004-06-01 9:55 ` Vojtech Pavlik
@ 2004-06-01 10:03 ` Sau Dan Lee
2004-06-01 12:42 ` Giuseppe Bilotta
1 sibling, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-01 10:03 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Andries Brouwer, linux-kernel
>>>>> "Vojtech" == Vojtech Pavlik <vojtech@suse.cz> writes:
>> Isn't the keyboard driver supposed to iron out such
>> differences?
Vojtech> The atkbd.c driver does exactly that. It hides the fact
Vojtech> that there is a special scancode for the PrintScreen key,
Vojtech> if you press it together with some other keys.
No, it doesn't do that. I press PrintScreen (without Alt) and it
tells the input system that it is a KEY_SYSRQ.
Vojtech> It's a hack by IBM engineers, the PC/XT keyboard had a
Vojtech> SysRq key, the PC/AT keyboard did not, yet some old DOS
Vojtech> programs needed it, so they made the AT keyboard generate
Vojtech> the keycode for alt-sysrq when running in XT
Vojtech> compatibility mode.
It's a simple SysRq (0x54), not Alt-SysRq (0x38 0x54) in my notebook.
Vojtech> Unfortunately, the XT compatibility mode stuck, and
Vojtech> that's what we're using now.
I know this part of the history, and hence why PrintScreen is emulated
by Alt-KPAsterisk.
Vojtech> The kernel works with real keys. There is no real sysrq
Vojtech> key.
On my notebook, there IS a real SysRq. (The [Fn] part is not visible
to the kernel. So, that's irrelevant.)
Vojtech> Ok, it's probably a bad name for it, it should have been
Vojtech> named KEY_PRTSCR, but it wasn't, and it'd only cause
Vojtech> breakage now to change it.
Deprecate the old one.
Vojtech> and is used for the PrtScr/SysRq key.
>> So, why not have seperate keycodes for the two?
Vojtech> Because there is only one key.
On some keyboards (e.g. my notebook), they're separate. Is that
enough a reason to have 2 different keycodes, then?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 10:57 Sau Dan Lee
@ 2004-06-01 11:31 ` Pavel Machek
2004-06-01 14:06 ` John Bradford
0 siblings, 1 reply; 80+ messages in thread
From: Pavel Machek @ 2004-06-01 11:31 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel
Hi!
> >>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
>
> Giuseppe> So, while we wait for complete support, at the kernel
> Giuseppe> level, for all the multimedia keyboards supported by X,
> Giuseppe> we *need* proper raw mode.
>
> My question is: why do everything inside the kernel?
>
>
> Even 'khttpd' has been removed from the kernel, because the same
> efficiency has been achieved in the *userland* apache module. Why is
> the input layer moving _backwards_?
>
> I don't think converting between keyboard/mouse protocols and the
> input system's "struct input_event" has a tighter real-time
> requirement than a heavily loaded web server. How many keys per
> second can you type at? (Even if you type extremely fast and the
> hardware constraints (velocity, etc.) are not reached yet, there is
> still a limit that the keyboard controller, e.g. i8042, cannot
> exceed.) How many mouse movements are you making per second? Is a
> userland driver unable to handle that data rate? (I don't think so.
> I believe enve a 386-DX 33MHz can handle it with ease.) If not, then
> please do it in userland, so as not to waste kernel memory (which is
> *NON-swappable*).
It would be nice to have keyboard in kernel because that means
keyboard works even on heavilly overloaded system, in case of oops
etc. (Unfortunately steps back were already taken; console switching
is no longer so robust w.r.t. kernel crashes :-( ).
Are you able to provide accurate timestamps for input events from
userland?
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: BUG FIX: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6]
2004-06-01 9:55 ` Vojtech Pavlik
2004-06-01 10:03 ` Sau Dan Lee
@ 2004-06-01 12:42 ` Giuseppe Bilotta
1 sibling, 0 replies; 80+ messages in thread
From: Giuseppe Bilotta @ 2004-06-01 12:42 UTC (permalink / raw)
To: linux-kernel
Vojtech Pavlik wrote:
> The kernel works with real keys. There is no real sysrq key. My
> definition of sanity is to base your thinking on reality where possible.
My keyboard has a separate key for SysRq (as much as
'separate' makes sense for laptop keyboards; it's a Fn-
activated key).
If you want to go the route you're going, all laptop keyboards
should have the numeric keypad produce the same emulated
scancodes as some alphanumeric keys. This does sound a little,
uhm, ridiculous to me.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-01 11:31 ` Pavel Machek
@ 2004-06-01 14:06 ` John Bradford
0 siblings, 0 replies; 80+ messages in thread
From: John Bradford @ 2004-06-01 14:06 UTC (permalink / raw)
To: Pavel Machek, Sau Dan Lee; +Cc: Giuseppe Bilotta, linux-kernel
Quote from Pavel Machek <pavel@ucw.cz>:
> Hi!
>
> > >>>>> "Giuseppe" == Giuseppe Bilotta <bilotta78@hotpop.com> writes:
> >
> > Giuseppe> So, while we wait for complete support, at the kernel
> > Giuseppe> level, for all the multimedia keyboards supported by X,
> > Giuseppe> we *need* proper raw mode.
> >
> > My question is: why do everything inside the kernel?
> >
> >
> > Even 'khttpd' has been removed from the kernel, because the same
> > efficiency has been achieved in the *userland* apache module. Why is
> > the input layer moving _backwards_?
> >
> > I don't think converting between keyboard/mouse protocols and the
> > input system's "struct input_event" has a tighter real-time
> > requirement than a heavily loaded web server. How many keys per
> > second can you type at? (Even if you type extremely fast and the
> > hardware constraints (velocity, etc.) are not reached yet, there is
> > still a limit that the keyboard controller, e.g. i8042, cannot
> > exceed.) How many mouse movements are you making per second? Is a
> > userland driver unable to handle that data rate? (I don't think so.
> > I believe enve a 386-DX 33MHz can handle it with ease.) If not, then
> > please do it in userland, so as not to waste kernel memory (which is
> > *NON-swappable*).
>
> It would be nice to have keyboard in kernel because that means
> keyboard works even on heavilly overloaded system, in case of oops
> etc. (Unfortunately steps back were already taken; console switching
> is no longer so robust w.r.t. kernel crashes :-( ).
I think it's nice to have input handling for the _console_ in the kernel
for the above reasons. In most cases a PS/2 keyboard and mouse are the
console input devices, but where they aren't, userspace processing might
be more logical.
I think that Vojtech mentioned at some time that the in-kernel PS/2 emulation
was mostly a workaround for X until X was capable of accessing the keyboard
directly. Well, I would take this one stage further and say that the way I
see it, in normal use, an X-based system shouldn't need a console configured
in the kernel at all.
Of course, I probably wouldn't use a system like that, it wouldn't be likely
to interest me at all, but I can see that it might suit normal desktop
machines quite well.
So, in my opinion, it's all about X, and nothing about the kernel.
However, I don't even have much interest in X itself these days, prefering
to work on the console :-).
John.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 13:25 ` Sau Dan Lee
@ 2004-06-01 21:01 ` jsimmons
2004-06-01 21:12 ` Valdis.Kletnieks
0 siblings, 1 reply; 80+ messages in thread
From: jsimmons @ 2004-06-01 21:01 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Vojtech Pavlik, linux-kernel
> Vojtech> No. I'm just saying - if you want something that's not in
> Vojtech> the kernel drivers, just write a driver for it. But the
> Vojtech> driver must be able to coexist with the other drivers.
>
> It's easier to write a mouse driver in userspace than in kernel. But
> with the input system in 2.6, I am *forced* to write it in kernel
> space, and reboot and reboot and reboot when it oops. Writing the
> driver in kernel space, I at most get a segfault. Plus I cannot use
> everything from glibc. It simply takes more time and energy to write
> a kernel space driver.
Why not use UML (user mode linux). Jon Smirl was using it to work on fbdev
drivers in userland. Interrupts where tricky to handle but it might
work fine now. I have to give it a try again. Once it is setup you can
develope kernel driver in userland.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 14:03 ` Vojtech Pavlik
@ 2004-06-01 21:03 ` jsimmons
0 siblings, 0 replies; 80+ messages in thread
From: jsimmons @ 2004-06-01 21:03 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Eduard Bloch, linux-kernel
> > For examle, I wish to create two terminals with my system, using two
> > monitors (on dual-head video card), two keyboards and two mices. I can
> > do the first part (X manages it well) but not beeing able to use
> > different input devices for different users simply SUCKS.
> > But http://linuxconsole.sourceforge.net/ lets me hope.
>
> I wrote most of the input handling in that project. It's what is in 2.6 now.
Yeap. The majority of the fbdev stuff went in from this project as well.
The linuxconsole project is using the current input layer with multiple
users with no problems.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-01 21:01 ` jsimmons
@ 2004-06-01 21:12 ` Valdis.Kletnieks
0 siblings, 0 replies; 80+ messages in thread
From: Valdis.Kletnieks @ 2004-06-01 21:12 UTC (permalink / raw)
To: jsimmons; +Cc: Sau Dan Lee, Vojtech Pavlik, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
On Tue, 01 Jun 2004 22:01:10 BST, jsimmons@pentafluge.infradead.org said:
> Why not use UML (user mode linux). Jon Smirl was using it to work on fbdev
> drivers in userland. Interrupts where tricky to handle but it might
> work fine now. I have to give it a try again. Once it is setup you can
> develope kernel driver in userland.
UML helps the "boot/crash/reboot" cycle (and that sort of debugging was in
fact one of the early design goals of IBM's CP/67 and VM/370 systems). but
it doesn't help the fact that the infrastructure provided to kernel functions
is vastly different than the glibc-based infrastructure available in userspace....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:25 ` Sau Dan Lee
` (2 preceding siblings ...)
2004-05-30 12:16 ` Vojtech Pavlik
@ 2004-06-04 13:58 ` Pavel Machek
2004-06-04 18:17 ` Horst von Brand
3 siblings, 1 reply; 80+ messages in thread
From: Pavel Machek @ 2004-06-04 13:58 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Vojtech Pavlik, Giuseppe Bilotta, linux-kernel, Tuukka Toivonen
Hi!
> >> >> What I hate is only the part where mouse/keyboard drivers
> >> >> are now in kernel space. The translation of raw byte
> >> >> streams into input events should be better done in userland.
> >> >> One important argument is: userland program may be swapped
> >> >> out. Kernel modules can't.
> >>
>
> Vojtech> Well, keyboard support was always in the kernel
>
> Once in kernel space, forever in kernel space? What's the logic?
>
> Where it is now possible to move it out of kernel space WITHOUT
> performance problems, why not move it out?
You get pretty nasty managment problems. How do you do init=/bin/bash
if your keyboard is userspace?
> Vojtech> But still, if you have a working keyboard, the handling
> Vojtech> is done in the kernel, and you can do a register dump,
> Vojtech> process listing, etc, even when the system is
> Vojtech> crashed.
>
> Why just the keyboard? For that purpose, we can use mouse buttons,
> the power button, a joystick button, or even a home-brewed button
> connected to the RS232 port or parallel port. Why *limit* that to the
> keyboard?
Keyboard is historically used for that. It seems to work, no reason to
change it.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-30 11:40 ` Sau Dan Lee
2004-05-30 11:53 ` Russell King
2004-05-30 12:43 ` Vojtech Pavlik
@ 2004-06-04 14:11 ` Pavel Machek
2 siblings, 0 replies; 80+ messages in thread
From: Pavel Machek @ 2004-06-04 14:11 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Vojtech Pavlik, linux-kernel
Hi!
> >> In a nutshell, I hate to be restricted by YOUR own imaginations
> >> of how people should hack the system.
>
> Vojtech> You're not. You're free to hack the kernel drivers.
>
> Not everyone using Linux is patient enough to explore the Wonderland
> of kernel hacking. Many immigrants from 2.4 are highly disappointed
> by the new but incompatible mouse/keyboard behaviours. Some of them
> returned to their 2.4 homeland because of this.
How can you propose moving keyboard handling to userland in one thread
and complain about 2.4-vs-2.6 incompatibility of inputs in another?!
2.4-vs-2.6 broke few strange keyboards. What you are proposing would
break everyone who has a keyboard.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-05-29 13:14 ` Vojtech Pavlik
@ 2004-06-04 14:54 ` Tuukka Toivonen
2004-06-04 16:06 ` Vojtech Pavlik
0 siblings, 1 reply; 80+ messages in thread
From: Tuukka Toivonen @ 2004-06-04 14:54 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Giuseppe Bilotta, linux-kernel
On Sat, 29 May 2004, Vojtech Pavlik wrote:
>On Fri, May 28, 2004 at 04:59:55PM +0300, Tuukka Toivonen wrote:
>> Giuseppe Bilotta wrote:
>> >The new system has some ups and downs. The biggest "down",
>> >which is that of RAW mode not being available anymore (it's
>> >emulated!) could be circumvented by having both the RAW and
>> >translated codes move between layers.
>> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
>> mode? To me this sounds like a big incompatibility.
>
>Q1: What would you do if the user has an USB keyboard?
If an application wants to access directly the keyboard, and the keyboard
happens to be USB, it should use other means to access it. I believe usbfs
provides some kind of interface for driving directly USB devices.
>Q2: What application should be looking at the raw data outside the
> kernel and why?
If there are no such programs, why the raw mode emulation is there then?
And if there are such programs, you should ask from those who have made
the programs. But I'll give here couple of possible reasons.
One reason is that someone wants to use the kernel in a
microkernel-like fashion, implementing keyboard driver in userspace.
Keyboards sound like a good candidate for userspace because they are
low-speed. Yeah, I agree there are also reasons why they should not be driven in
userspace, but don't want to argue now which is better.
Another reason is that previously Linux didn't offer event-based
interface to keyboards without raw mode. So, if some program needed to know
all keypress and release events, the only choice might have been the raw
mode. For these programs emulation makes perfect sense for backwards
compatibility.
I was thinking the first reason when I said the above, but the second
is likely more important in practice.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 14:54 ` Tuukka Toivonen
@ 2004-06-04 16:06 ` Vojtech Pavlik
0 siblings, 0 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-06-04 16:06 UTC (permalink / raw)
To: Tuukka Toivonen; +Cc: Giuseppe Bilotta, linux-kernel
On Fri, Jun 04, 2004 at 05:54:10PM +0300, Tuukka Toivonen wrote:
> >> Giuseppe Bilotta wrote:
> >> >The new system has some ups and downs. The biggest "down",
> >> >which is that of RAW mode not being available anymore (it's
> >> >emulated!) could be circumvented by having both the RAW and
> >> >translated codes move between layers.
> >> Ouch! If the user asks for raw mode, he doesn't get it, but some emulated
> >> mode? To me this sounds like a big incompatibility.
> >
> >Q1: What would you do if the user has an USB keyboard?
>
> If an application wants to access directly the keyboard, and the keyboard
> happens to be USB, it should use other means to access it. I believe usbfs
> provides some kind of interface for driving directly USB devices.
Yes, sure, if an application wants to access the USB keyboard directly,
it can use usbfs. But if it asks for rawmode on the console, it needs to
be given PS/2 rawmode. And that inevitably means emulation in this case.
> >Q2: What application should be looking at the raw data outside the
> > kernel and why?
>
> If there are no such programs, why the raw mode emulation is there then?
Backward compatibility, namely with X. But even X doesn't have a good
reason using PS/2 protocol to talk to the kernel.
> And if there are such programs, you should ask from those who have made
> the programs. But I'll give here couple of possible reasons.
>
> One reason is that someone wants to use the kernel in a
> microkernel-like fashion, implementing keyboard driver in userspace.
> Keyboards sound like a good candidate for userspace because they are
> low-speed. Yeah, I agree there are also reasons why they should not be driven in
> userspace, but don't want to argue now which is better.
For this purpose is console rawmode (the thing this thread was about) is
completely useless, because you cannot feed the data to the console
again.
For that, you need the exported serio interface. [Which means it wasn't
possible on 2.4] I agree exporting serio's as char devices is useful.
> Another reason is that previously Linux didn't offer event-based
> interface to keyboards without raw mode. So, if some program needed to know
> all keypress and release events, the only choice might have been the raw
> mode.
The "medium raw" mode exists since ages, provides keycodes (as opposed
to scancodes), and is used even for X on many non-386 architectures.
This IMO was the right choice.
> For these programs emulation makes perfect sense for backwards
> compatibility.
Indeed. That's why it's there.
> I was thinking the first reason when I said the above, but the second
> is likely more important in practice.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 13:58 ` Pavel Machek
@ 2004-06-04 18:17 ` Horst von Brand
2004-06-04 18:37 ` Valdis.Kletnieks
2004-06-04 18:39 ` Pavel Machek
0 siblings, 2 replies; 80+ messages in thread
From: Horst von Brand @ 2004-06-04 18:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Sau Dan Lee, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
Pavel Machek <pavel@suse.cz> said:
[...]
> You get pretty nasty managment problems. How do you do init=/bin/bash
> if your keyboard is userspace?
You don't tell any kernel about that... it is the bootloader you are
talking to. And that one may very well have integrated kbd support.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 18:17 ` Horst von Brand
@ 2004-06-04 18:37 ` Valdis.Kletnieks
2004-06-04 19:33 ` Denis Vlasenko
2004-06-04 18:39 ` Pavel Machek
1 sibling, 1 reply; 80+ messages in thread
From: Valdis.Kletnieks @ 2004-06-04 18:37 UTC (permalink / raw)
To: Horst von Brand; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> Pavel Machek <pavel@suse.cz> said:
> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
>
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.
So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it loads
the kernel, the kernel launches init, /bin/bash gets loaded - and /bin/bash
can't talk to the keyboard because the userspace handler hasn't happened. At
that point you're stuck...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 18:17 ` Horst von Brand
2004-06-04 18:37 ` Valdis.Kletnieks
@ 2004-06-04 18:39 ` Pavel Machek
2004-06-04 18:46 ` Sau Dan Lee
1 sibling, 1 reply; 80+ messages in thread
From: Pavel Machek @ 2004-06-04 18:39 UTC (permalink / raw)
To: Horst von Brand
Cc: Sau Dan Lee, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
Hi!
> [...]
>
> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
>
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.
I know bootloader will hae its own kbd driver.
But when kernel boots, you'll not be able to enter commands into the bash.
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 18:39 ` Pavel Machek
@ 2004-06-04 18:46 ` Sau Dan Lee
2004-06-04 19:09 ` Pavel Machek
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-04 18:46 UTC (permalink / raw)
To: Pavel Machek
Cc: Horst von Brand, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
>>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:
Pavel> I know bootloader will hae its own kbd driver.
Pavel> But when kernel boots, you'll not be able to enter commands
Pavel> into the bash.
Funny. How did you type the command to start bash?
If you can arrange bash to be run, then why is it that difficult to
arrange "modprobe atkbd; modprobe i8042" to be executed?
Some distros even have the disk driver and filesystem for the root fs
compiled as modules. They do manage to load those modules correct to
mount the rootfs. How come it is so hard to imagine that 'i8042' and
'atkbd' can somehow be loaded without user attention at boot time?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 18:46 ` Sau Dan Lee
@ 2004-06-04 19:09 ` Pavel Machek
2004-06-06 9:01 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Pavel Machek @ 2004-06-04 19:09 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Horst von Brand, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
Hi!
> Pavel> I know bootloader will hae its own kbd driver.
>
> Pavel> But when kernel boots, you'll not be able to enter commands
> Pavel> into the bash.
>
> Funny. How did you type the command to start bash?
That was in comment you stripped.
> If you can arrange bash to be run, then why is it that difficult to
> arrange "modprobe atkbd; modprobe i8042" to be executed?
It would not be "modprobe atkbd" but "my-keyboard-daemon &". And AFAIK
you can't add that to "init=" commandline.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 18:37 ` Valdis.Kletnieks
@ 2004-06-04 19:33 ` Denis Vlasenko
2004-06-04 19:50 ` Valdis.Kletnieks
0 siblings, 1 reply; 80+ messages in thread
From: Denis Vlasenko @ 2004-06-04 19:33 UTC (permalink / raw)
To: Valdis.Kletnieks, Horst von Brand; +Cc: linux-kernel
On Friday 04 June 2004 21:37, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> > Pavel Machek <pavel@suse.cz> said:
> > > You get pretty nasty managment problems. How do you do init=/bin/bash
> > > if your keyboard is userspace?
> >
> > You don't tell any kernel about that... it is the bootloader you are
> > talking to. And that one may very well have integrated kbd support.
>
> So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it
> loads the kernel, the kernel launches init, /bin/bash gets loaded - and
> /bin/bash can't talk to the keyboard because the userspace handler hasn't
> happened. At that point you're stuck...
Using shell scripts instead of 'standard' init etc is
way more configurable. As an example, my current setup
at home:
My kernel params are:
root=/dev/ram
init=/linuxrc
devfs=mount
ROOTFS=/dev/ide/host0/bus0/target0/lun0/part7
IPCFG=mac,100mbit
INIT=/init
/linuxrc (in initrd):
#!/bin/sh
export PATH=/bin:/usr/bin
cd /
mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys
echo "# Configuring interfaces"
# Optional, for NFS happiness
ip l set dev lo up
ip a add 127.0.0.1/8 dev lo
/script/cfg_ip
echo "# Mounting root fs"
/script/mount_root
# Clean up
#umount /sys
umount /proc
echo "# Chrooting into root fs"
mount -n -t devfs none /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint
pivot_root . proc
echo "# Exec'ing init"
if ! test "$INIT"; then
INIT=/init
fi
exec \
chroot . \
sh -c \
'umount -n /proc/dev; umount -n /proc; exec /bin/env - $INIT'
echo "Error in 'exec chroot . sh': exit code $?"
while true; do
sleep 32000
done
And, finally, /init:
#!/bin/sh
fileprefix=/etc/rc.d
bootprog=3.runlevel
unset HOSTNAME
unset devfs
unset MACHTYPE
unset SHLVL
unset SHELL
unset HOSTTYPE
unset OSTYPE
unset HOME
unset TERM
export PATH=/bin:/usr/bin
exec >/dev/console
exec 2>&1
exec </dev/null
(
cd "$fileprefix"
env - PATH="$PATH" "$fileprefix/$bootprog" start
)
# Close all descriptors
exec >&-
exec 2>&-
exec <&-
while true; do
env - sleep 32000
done
--
vda
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 19:33 ` Denis Vlasenko
@ 2004-06-04 19:50 ` Valdis.Kletnieks
2004-06-04 20:48 ` Denis Vlasenko
0 siblings, 1 reply; 80+ messages in thread
From: Valdis.Kletnieks @ 2004-06-04 19:50 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Horst von Brand, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
> Using shell scripts instead of 'standard' init etc is
> way more configurable. As an example, my current setup
> at home:
>
> My kernel params are:
Yes. Those are *YOUR* config setup parameters, that happen to work with *your*
specific configuration when everything is operational. Some problems:
1) Not all the world uses initrd....
2) I hope your /script/mount_root will Do The Right Thing if the mount fails
because it needs an fsck, for example. Answering those 'y' and 'n' prompts can
be a problem if your keyboard isn't working yet..
3) Bonus points if you can explain how to, *without* a working keyboard, modify
that /linuxrc on your initrd to deal with the situation where your keyboard
setup is wrong (think "booting with borrowed keyboard because your usual one
just suffered a carbonated caffeine overdose")...
There's a *BASIC* bootstrapping problem here - if you move "initialize and
handle the keyboard" into userspace, you then *require* that a significantly
larger chunk of userspace be operational in order to be able to even type at
the machine. If you're trying to recover a *broken* userspace, it gets a lot
harder.
And the embedded people who use "init=/onlyprogramthateverruns" are going
to have a significant collective cow about this....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 19:50 ` Valdis.Kletnieks
@ 2004-06-04 20:48 ` Denis Vlasenko
0 siblings, 0 replies; 80+ messages in thread
From: Denis Vlasenko @ 2004-06-04 20:48 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Horst von Brand, linux-kernel
On Friday 04 June 2004 22:50, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
> > Using shell scripts instead of 'standard' init etc is
> > way more configurable. As an example, my current setup
> > at home:
> >
> > My kernel params are:
>
> Yes. Those are *YOUR* config setup parameters, that happen to work with
> *your* specific configuration when everything is operational. Some
> problems:
In *any* setup, kernelspace or userspace, it's typically possible
to find some silly way to break boot sequence. Unplugging
keyboard and removing (unneded for server) videocard are my
favorites ;)
> 1) Not all the world uses initrd....
I stayed away from it too, but I always knew I'll need it sooner
or later.
> 2) I hope your /script/mount_root will Do The Right Thing if the mount
> fails because it needs an fsck, for example. Answering those 'y' and 'n'
> prompts can be a problem if your keyboard isn't working yet..
My init scripts are (trying to) recover from any failure.
They ignore non-fatal error conditions.
I'll fix your fsck example like this: make script check
FSCK_ACTION env var for N (never do fsck), ASK (ask user
if serious trouble), and AUTO (fix automagically without
user). Set FSCK_ACTION as needed per box via kernel command line.
Fixing/tailoring init written in C is harder (more time-consuming).
Fixing/tailoring kernel bootstrap sequence is harder still.
As an example, NFS boot. How can you force your ethernet into,
say, 100 Mbit FDX _before_ kernel do DHCP thing via ip= kernel
parameter?
That's one of reasons why moving to userspace might be a good idea.
> 3) Bonus points if you can explain how to, *without* a working keyboard,
> modify that /linuxrc on your initrd to deal with the situation where your
> keyboard setup is wrong (think "booting with borrowed keyboard because your
> usual one just suffered a carbonated caffeine overdose")...
I just did that yesterday when I needed to make USB keyboard to
work on my box, first time ever for me. I let it boot, ssh'ed in,
and built new kernel. I could modify my initrd too, but that wasn't
needed.
> There's a *BASIC* bootstrapping problem here - if you move "initialize and
> handle the keyboard" into userspace, you then *require* that a
> significantly larger chunk of userspace be operational in order to be able
> to even type at the machine. If you're trying to recover a *broken*
> userspace, it gets a lot harder.
Bootstrapping problem exist no matter how you are bootstrapping.
When something is broken, difficulty of repairs cannot be estimated
that simple. I don't think "you are using intird -> fixing will be hard"
always holds true.
BTW, in my case, booting my box was not just hard, it was impossible.
It had broken PS2 ports. I needed to "only" enter BIOS setup and tell
it to ignore keyboard errors on boot, but I couldn't enter it
without keyboard! But I digress...
--
vda
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-04 19:09 ` Pavel Machek
@ 2004-06-06 9:01 ` Sau Dan Lee
2004-06-06 16:40 ` Pavel Machek
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-06 9:01 UTC (permalink / raw)
To: Pavel Machek
Cc: Horst von Brand, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
>>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:
>> If you can arrange bash to be run, then why is it that
>> difficult to arrange "modprobe atkbd; modprobe i8042" to be
>> executed?
Pavel> It would not be "modprobe atkbd" but "my-keyboard-daemon
Pavel> &".
What's the difference? Both are commands. Commands can be put in
shell scripts, which can be put in shell scripts, ... Eventually, you
only need one root script to spawn all the offsprings.
Pavel> And AFAIK you can't add that to "init=" commandline.
That's getting funny. You can't start 6 copies of getty on
/dev/tty[1-6] on "init=", can you?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-06-06 9:37 Sau Dan Lee
2004-06-06 11:29 ` Martin Schlemmer
` (2 more replies)
0 siblings, 3 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-06 9:37 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
>> You don't tell any kernel about that... it is the bootloader
>> you are talking to. And that one may very well have integrated
>> kbd support.
Valdis> So GRUB knows about keyboards, lets you type in the
Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
Valdis> init, /bin/bash gets loaded
If init can launch /bin/bash (actually, it lauches getty in most
setups), why can't it start the userland keyboard driver daemon?
Back in the old days before the introduction of /etc/rc.d/, every
daemon was started from by init.
Valdis> - and /bin/bash can't talk to the keyboard because the
Valdis> userspace handler hasn't happened.
As soon as the daemon is running, /bin/bash can talk to the keyboard.
There is not much concurrency problems here. The current input system
makes it possible for /bin/bash to start opening the keyboard and
waiting for input before the userspace handler is ready.
Valdis> At that point you're stuck...
I can't see how stuck it is. And if you fear that the userland
keyboard driver would crash (maybe due to bugs), use the 'respawn'
option in /etc/inittab.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
@ 2004-06-06 9:43 Sau Dan Lee
0 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-06 9:43 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
Valdis> On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
>> Using shell scripts instead of 'standard' init etc is way more
>> configurable. As an example, my current setup at home:
>>
>> My kernel params are:
Valdis> Yes. Those are *YOUR* config setup parameters, that happen
Valdis> to work with *your* specific configuration when everything
Valdis> is operational. Some problems:
Valdis> 1) Not all the world uses initrd....
Does ever /etc/rcS.d/* require initrd?
Moreover, not all the world uses a keyboard, either.
Valdis> 2) I hope your /script/mount_root will Do The Right Thing
Valdis> if the mount fails because it needs an fsck, for example.
Valdis> Answering those 'y' and 'n' prompts can be a problem if
Valdis> your keyboard isn't working yet..
Things even worse can happen, too, such as harddisk dying. In those
problematic situations, you'd rather boot a failsafe partition, or a
rescue floppy, or Knoppix CD.
Valdis> 3) Bonus points if you can explain how to, *without* a
Valdis> working keyboard, modify that /linuxrc on your initrd to
Valdis> deal with the situation where your keyboard setup is wrong
Valdis> (think "booting with borrowed keyboard because your usual
Valdis> one just suffered a carbonated caffeine overdose")...
How do you do the same if you had only SCSI disks, but the SCSI
modules are not loaded or compiled in?
Valdis> There's a *BASIC* bootstrapping problem here - if you move
Valdis> "initialize and handle the keyboard" into userspace, you
Valdis> then *require* that a significantly larger chunk of
Valdis> userspace be operational in order to be able to even type
Valdis> at the machine. If you're trying to recover a *broken*
Valdis> userspace, it gets a lot harder.
Valdis> And the embedded people who use
Valdis> "init=/onlyprogramthateverruns" are going to have a
Valdis> significant collective cow about this....
Does embedded systems always have a keyboard?
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-06 9:37 Sau Dan Lee
@ 2004-06-06 11:29 ` Martin Schlemmer
2004-06-06 12:07 ` Vojtech Pavlik
2004-06-06 15:09 ` Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Martin Schlemmer @ 2004-06-06 11:29 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Valdis.Kletnieks, Linux Kernel Mailing Lists
[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]
On Sun, 2004-06-06 at 11:37, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
>
>
> Valdis> - and /bin/bash can't talk to the keyboard because the
> Valdis> userspace handler hasn't happened.
>
> As soon as the daemon is running, /bin/bash can talk to the keyboard.
> There is not much concurrency problems here. The current input system
> makes it possible for /bin/bash to start opening the keyboard and
> waiting for input before the userspace handler is ready.
>
>
> Valdis> At that point you're stuck...
>
> I can't see how stuck it is. And if you fear that the userland
> keyboard driver would crash (maybe due to bugs), use the 'respawn'
> option in /etc/inittab.
The point is that 'init=/bin/bash' is usually used as a method to
do some _unexpected_ rescue work - meaning you usually do not think
about it (or write a shell script to start a keyboard daemon) until
you need it. Thats it - a rescue method - and its got nothing to do
with what is in inittab, or if getty's are started or not. Some
distro's even have sash installed by default (statically linked) in
case your glibc is borked or such, and you need to cp/mv/gunzip things.
Anyhow, the other point that should be made, is that your are really
getting boring/annoying. Please face the fact that many of us (most?)
do not want a silly daemon for keyboard, but an in-kernel driver.
Guess what else ... Valdis, etc do not even argue with you for wanting
this silliness (besides not wanting to get rid of the in-kernel driver),
but are prepared to add raw access, so that you can go and code/use your
daemon (Ok, so maybe the raw access is for more than what you want, but
anyhow ...).
So please stop being selfish and continuing to spam the list.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-06 9:37 Sau Dan Lee
2004-06-06 11:29 ` Martin Schlemmer
@ 2004-06-06 12:07 ` Vojtech Pavlik
2004-06-06 15:09 ` Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Vojtech Pavlik @ 2004-06-06 12:07 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: Valdis.Kletnieks, linux-kernel
On Sun, Jun 06, 2004 at 11:37:41AM +0200, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
At the risk of being flamed, here is an explanation.
If you, at the kernel command line, type "init=/bin/bash", the bash
shell will be used _instead_ of the regular init program. This is very
useful when you made a mistake in the inittab, something deleted your
root entry in passwd/shadow, your filesystem is in trouble and in many
other cases.
This also means that there will be no other program run before or after
bash. All you get is a prompt.
This means the keyboard will have to work without any setup - or you
won't be able to type in anything, like a command to run the daemon, or
a command to insert a module.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-06 9:37 Sau Dan Lee
2004-06-06 11:29 ` Martin Schlemmer
2004-06-06 12:07 ` Vojtech Pavlik
@ 2004-06-06 15:09 ` Dmitry Torokhov
2004-06-06 16:13 ` Sau Dan Lee
[not found] ` <200406061929.45169.vda@port.imtp.ilyichevsk.odessa.ua>
2 siblings, 2 replies; 80+ messages in thread
From: Dmitry Torokhov @ 2004-06-06 15:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Sau Dan Lee, Valdis.Kletnieks
On Sunday 06 June 2004 04:37 am, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
Init does not start bash, in the case above bash started by the kernel
_instead_ of init. The only thing you have is bash. No regular init scripts
will be executed, nothing.
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
>
>
> Valdis> - and /bin/bash can't talk to the keyboard because the
> Valdis> userspace handler hasn't happened.
>
> As soon as the daemon is running, /bin/bash can talk to the keyboard.
But nothing has started driver (no scriprs were run, remember?) so it's not
running and bash can't get keyboard input.
--
Dmitry
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-06 15:09 ` Dmitry Torokhov
@ 2004-06-06 16:13 ` Sau Dan Lee
[not found] ` <200406061929.45169.vda@port.imtp.ilyichevsk.odessa.ua>
1 sibling, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-06 16:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel, Valdis.Kletnieks
>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
>> If init can launch /bin/bash (actually, it lauches getty in
>> most setups), why can't it start the userland keyboard driver
>> daemon?
>>
Dmitry> Init does not start bash, in the case above bash started
Dmitry> by the kernel _instead_ of init. The only thing you have
Dmitry> is bash. No regular init scripts will be executed,
Dmitry> nothing.
If you can launch /bin/bash using init= from GRUB or LILO, you can
equally lauch a bash script that starts the userspace keyboard driver
daemon before and then "exec /bin/bash".
Of course, you can argue that this daemon may rest on a fs that hasn't
be mounted yet, or on a fs that has been corrupted. But so can the
/bin/bash executable!
Moreover, I can also argue the kernel image may also have been
corrupted due to disk errors, and the keyboard driver code lies in
those corrupted sectors, unfortunately.
Further, a kernel keyboard driver can coexist with a userspace one.
The kernel one can be made simpler, providing only the very basic
needs. Once the userspace daemon starts successfully, it can take
over. Programs like X11 may drive the keyboard directly and provide
many sophisticated features that a simple kernel driver doesn't
provide. Take a look at xkb.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-06 9:01 ` Sau Dan Lee
@ 2004-06-06 16:40 ` Pavel Machek
0 siblings, 0 replies; 80+ messages in thread
From: Pavel Machek @ 2004-06-06 16:40 UTC (permalink / raw)
To: Sau Dan Lee
Cc: Horst von Brand, Vojtech Pavlik, Giuseppe Bilotta, linux-kernel,
Tuukka Toivonen
Hi!
> Pavel> And AFAIK you can't add that to "init=" commandline.
>
> That's getting funny. You can't start 6 copies of getty on
> /dev/tty[1-6] on "init=", can you?
No, but you can do init=/bin/bash. [Are you reading my mails at all?!]
And init=/bin/bash is enough to recover broken system.
What you are proposing is incompatible update that would break 99% of
all systems, for gain of 8K of unswappable memory or something like
that. That's no-no in 2.6 series, and probably bad idea for 2.7, too.
Now, can we end the thread here? Userland keyboard driver is not going
to happen in 2.6.X.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
[not found] ` <200406061140.35929.dtor_core@ameritech.net>
@ 2004-06-06 16:51 ` Sau Dan Lee
0 siblings, 0 replies; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-06 16:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Denis Vlasenko, linux-kernel, Valdis.Kletnieks
>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
Dmitry> Here you are talking about regular startup procedure for a
Dmitry> very special setup - yours. We were talking about
Dmitry> emergency recovery of a "standard" Linux box.
Well... it'd be a long thread to discuss what constitutes a "standard"
Linux box, let alone what "emergency situation" should mean.
As a matter of fact, more and more people are using a Knoppix CD as an
emergency recovery boot disk, not only for repairing Linux boxes, but
also for repairing Windows boxes.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
[not found] ` <200406081502.i58F2gF3013622@turing-police.cc.vt.edu>
@ 2004-06-09 8:17 ` Sau Dan Lee
2004-06-09 16:56 ` Valdis.Kletnieks
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-09 8:17 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
Valdis> The whole 'init=/bin/bash' style of recovery has been
Valdis> widely documented and often used (for instance, it's
Valdis> covered in the RHCE class and used in one of the hands-on
Valdis> labs to recover a non-booting system). That's a lot of
Valdis> people to retrain, and a lot of systems that need
Valdis> changing...
Valdis> (Trust me - if it's 3AM, and you type 'init=/bin/sh' and
Valdis> it outputs the '#' but won't take input, you WONT think of
Valdis> that kernel and initscripts change from 3 months ago...)
Explain to me how a kernel compiled with
CONFIG_SERIO=m
CONFIG_KEYBOARD_ATKBD=m
would be able to boot with "init=/bin/sh" and still have the keyboard
working.
I've just verified that "make allmodconfig", which is what many people
are tempted to do once they've learnt about it, will produce such a
.config.
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-09 8:17 ` Sau Dan Lee
@ 2004-06-09 16:56 ` Valdis.Kletnieks
2004-06-09 17:12 ` Sau Dan Lee
0 siblings, 1 reply; 80+ messages in thread
From: Valdis.Kletnieks @ 2004-06-09 16:56 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:
> Explain to me how a kernel compiled with
> CONFIG_SERIO=m
> CONFIG_KEYBOARD_ATKBD=m
> would be able to boot with "init=/bin/sh" and still have the keyboard
> working.
Explain to me why you think that example is a good reason why
a kernel compiled with
CONFIG_SERIO=y
CONFIG_KEYBOARD_ATKBD=y
should *NOT* be able to boot with 'init=/bin/sh'.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-09 16:56 ` Valdis.Kletnieks
@ 2004-06-09 17:12 ` Sau Dan Lee
2004-06-09 17:29 ` Valdis.Kletnieks
0 siblings, 1 reply; 80+ messages in thread
From: Sau Dan Lee @ 2004-06-09 17:12 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
Valdis> On Wed, 09 Jun 2004 10:17:04 +0200, Sau Dan Lee said:
>> Explain to me how a kernel compiled with CONFIG_SERIO=m
>> CONFIG_KEYBOARD_ATKBD=m would be able to boot with
>> "init=/bin/sh" and still have the keyboard working.
Valdis> Explain to me why you think that example is a good reason
Valdis> why a kernel compiled with
Valdis> CONFIG_SERIO=y
Valdis> CONFIG_KEYBOARD_ATKBD=y
Valdis> should *NOT* be able to boot with 'init=/bin/sh'.
"make help" shows:
...
Configuration targets:
oldconfig - Update current config utilising a line-oriented program
menuconfig - Update current config utilising a menu based program
xconfig - Update current config utilising a QT based front-end
gconfig - Update current config utilising a GTK based front-end
defconfig - New config with default answer to all options
allmodconfig - New config selecting modules when possible
allyesconfig - New config where all options are accepted with yes
allnoconfig - New minimal config
A person trying to upgrade from 2.4 would suppose that the 2.4 .config
won't work and would likely start with "make allmodconfig", and then
"make {menu/x}config". With 100s (or 1000s) of configuration items,
it is not easy for a 2.4-er to discover that one now has to explicitly
enable i8042 and atkbd. So, it is likely for him to have:
CONFIG_SERIO=m
CONFIG_KEYBOARD_ATKBD=m
--
Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: keyboard problem with 2.6.6
2004-06-09 17:12 ` Sau Dan Lee
@ 2004-06-09 17:29 ` Valdis.Kletnieks
0 siblings, 0 replies; 80+ messages in thread
From: Valdis.Kletnieks @ 2004-06-09 17:29 UTC (permalink / raw)
To: Sau Dan Lee; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Wed, 09 Jun 2004 19:12:09 +0200, Sau Dan Lee said:
> A person trying to upgrade from 2.4 would suppose that the 2.4 .config
> won't work and would likely start with "make allmodconfig", and then
> "make {menu/x}config". With 100s (or 1000s) of configuration items,
> it is not easy for a 2.4-er to discover that one now has to explicitly
> enable i8042 and atkbd. So, it is likely for him to have:
>
> CONFIG_SERIO=m
> CONFIG_KEYBOARD_ATKBD=m
*plonk* <add to killfile>
OK. You proved that it's possible to create a kernel configuration that won't
boot on your hardware (hey, people who boot off IDE or SCSI and build those
drivers as modules have to play initrd games too).
Let me know when you actually answer the question - which was "Why does that
mean it's OK to break users who *do* answer with 'y' for those options?" (An
alternate way of looking at it is that you will mandate a situation where the
only *useful* values are equivalent to 'm' and 'n' - either you don't have it
at all (n) or you need userspace assistance before you have it (m).
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2004-06-09 17:29 UTC | newest]
Thread overview: 80+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-07 20:55 [PATCH] SERIO_USERDEV: direct userspace access to mouse/keyboard psaux serial ports Tuukka Toivonen
2004-05-08 2:35 ` Andrew Morton
2004-05-25 20:16 ` keyboard problem with 2.6.6 Chris Osicki
2004-05-26 7:54 ` Sau Dan Lee
2004-05-28 13:33 ` Giuseppe Bilotta
2004-05-28 17:37 ` Sau Dan Lee
2004-05-29 13:12 ` Vojtech Pavlik
2004-05-30 9:45 ` Sau Dan Lee
2004-05-30 10:19 ` Vojtech Pavlik
2004-05-30 11:25 ` Sau Dan Lee
2004-05-30 11:40 ` Brad Campbell
2004-05-30 12:01 ` Oliver Neukum
2004-05-30 12:22 ` Sau Dan Lee
2004-05-30 12:32 ` Oliver Neukum
2004-05-30 12:16 ` Vojtech Pavlik
2004-05-30 12:40 ` Sau Dan Lee
2004-05-30 12:52 ` Vojtech Pavlik
2004-05-30 16:09 ` Stefan Seyfried
2004-05-30 17:26 ` Dmitry Torokhov
2004-06-04 13:58 ` Pavel Machek
2004-06-04 18:17 ` Horst von Brand
2004-06-04 18:37 ` Valdis.Kletnieks
2004-06-04 19:33 ` Denis Vlasenko
2004-06-04 19:50 ` Valdis.Kletnieks
2004-06-04 20:48 ` Denis Vlasenko
2004-06-04 18:39 ` Pavel Machek
2004-06-04 18:46 ` Sau Dan Lee
2004-06-04 19:09 ` Pavel Machek
2004-06-06 9:01 ` Sau Dan Lee
2004-06-06 16:40 ` Pavel Machek
2004-05-28 19:39 ` 2.6.* useland replacements of the atkbd and psmouse modules Sau Dan Lee
2004-05-28 19:57 ` keyboard problem with 2.6.6 Andries Brouwer
2004-06-01 8:21 ` BUG: atkbd.c keyboard driver bug [Was: keyboard problem with 2.6.6] Sau Dan Lee
2004-06-01 9:13 ` BUG FIX: " Sau Dan Lee
[not found] ` <200406010904.i5194pSo010367@fire-2.osdl.org>
2004-06-01 9:44 ` Sau Dan Lee
2004-06-01 9:55 ` Vojtech Pavlik
2004-06-01 10:03 ` Sau Dan Lee
2004-06-01 12:42 ` Giuseppe Bilotta
2004-05-28 19:41 ` keyboard problem with 2.6.6 Andries Brouwer
2004-05-28 20:10 ` Andries Brouwer
[not found] ` <20040528214620.GA2352@gucio>
2004-05-29 13:23 ` Andries Brouwer
2004-05-29 13:46 ` Vojtech Pavlik
2004-05-29 14:30 ` Andries Brouwer
2004-05-29 14:41 ` Vojtech Pavlik
2004-05-29 15:12 ` Giuseppe Bilotta
[not found] <xb7oenxyqly.fsf@savona.informatik.uni-freiburg.de>
[not found] ` <200406071551.i57Fpl89023562@turing-police.cc.vt.edu>
[not found] ` <xb7zn7fwdia.fsf@savona.informatik.uni-freiburg.de>
[not found] ` <200406071636.i57Gafh7024942@turing-police.cc.vt.edu>
[not found] ` <xb7r7sqwncc.fsf@savona.informatik.uni-freiburg.de>
[not found] ` <200406081502.i58F2gF3013622@turing-police.cc.vt.edu>
2004-06-09 8:17 ` Sau Dan Lee
2004-06-09 16:56 ` Valdis.Kletnieks
2004-06-09 17:12 ` Sau Dan Lee
2004-06-09 17:29 ` Valdis.Kletnieks
-- strict thread matches above, loose matches on Subject: below --
2004-06-06 9:43 Sau Dan Lee
2004-06-06 9:37 Sau Dan Lee
2004-06-06 11:29 ` Martin Schlemmer
2004-06-06 12:07 ` Vojtech Pavlik
2004-06-06 15:09 ` Dmitry Torokhov
2004-06-06 16:13 ` Sau Dan Lee
[not found] ` <200406061929.45169.vda@port.imtp.ilyichevsk.odessa.ua>
[not found] ` <200406061140.35929.dtor_core@ameritech.net>
2004-06-06 16:51 ` Sau Dan Lee
[not found] <xb7ekp2b34y.fsf@savona.informatik.uni-freiburg.de>
[not found] ` <20040530112138.GC1377@ucw.cz>
2004-05-30 11:43 ` Sau Dan Lee
2004-05-30 12:45 ` Vojtech Pavlik
2004-05-30 13:25 ` Sau Dan Lee
2004-05-30 10:57 Sau Dan Lee
2004-06-01 11:31 ` Pavel Machek
2004-06-01 14:06 ` John Bradford
2004-05-30 10:45 Sau Dan Lee
2004-05-30 11:20 ` Vojtech Pavlik
2004-05-30 10:39 Sau Dan Lee
2004-05-30 11:18 ` Vojtech Pavlik
2004-05-30 11:40 ` Sau Dan Lee
2004-05-30 11:53 ` Russell King
2004-05-30 12:43 ` Vojtech Pavlik
2004-05-30 13:25 ` Sau Dan Lee
2004-06-01 21:01 ` jsimmons
2004-06-01 21:12 ` Valdis.Kletnieks
2004-05-30 13:54 ` Eduard Bloch
2004-05-30 14:03 ` Vojtech Pavlik
2004-06-01 21:03 ` jsimmons
2004-06-04 14:11 ` Pavel Machek
2004-05-28 13:59 Tuukka Toivonen
2004-05-29 13:14 ` Vojtech Pavlik
2004-06-04 14:54 ` Tuukka Toivonen
2004-06-04 16:06 ` Vojtech Pavlik
[not found] <MPG.1b2111558bc2d299896a2@news.gmane.org.suse.lists.linux.kernel>
[not found] ` <20040525201616.GE6512@gucio.suse.lists.linux.kernel>
[not found] ` <xb7hdu3fwsj.fsf@savona.informatik.uni-freiburg.de.suse.lists.linux.kernel>
[not found] ` <xb7aczscv0q.fsf@savona.informatik.uni-freiburg.de.suse.lists.linux.kernel>
[not found] ` <20040529131233.GA6185@ucw.cz.suse.lists.linux.kernel>
[not found] ` <xb7y8nab65d.fsf@savona.informatik.uni-freiburg.de.suse.lists.linux.kernel>
[not found] ` <20040530101914.GA1226@ucw.cz.suse.lists.linux.kernel>
[not found] ` <xb765aeb1i3.fsf@savona.informatik.uni-freiburg.de.suse.lists.linux.kernel>
[not found] ` <20040530121606.GA1496@ucw.cz.suse.lists.linux.kernel>
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox