|
From: Vojtech P. <vo...@su...> - 2000-07-04 11:24:02
|
On Tue, Jul 04, 2000 at 12:25:17PM +0200, Franz Sirl wrote: > >Creating /dev/input/events is the wrong approach. Creating a way how to > >make an already-open disappearing and appearing again device to appear > >back at the same device number. > > Seems like a quite difficult task to me... But something like that will be badly needed for other parts of the system as well. For example the USB Storage driver already does it. So it's possible. > Hmm. Let me think about that... What will the application see? I don't see > a type like EV_STATUSCHANGE with events like CONNECT, DISCONNECT, CHANGED? Right now, the events from the device will just stop coming in. > I see. Actually, what I'm looking for is a reasonable simple way to port > some legacy (but unfortunately still needed) applications to the input > layer... Hmm, I can live with mice and keyboards being separate, so would > you accept if I added a keyboard mixer device to keybdev.c? Keybdev.c already does that, and keyboard.c (in the complete input drivers) is doing it as well. > >The ioctls should modify the event->keymap structure. > > Sure. But you mean event->keycode, or? Sorry, I meant struct input_dev->keycode. I should have checked the sources first. > >Ok. Implementing setkeycode with USB keyboards won't be easy, since > >hid.c has a quite complicated structure for this. If you won't be able > >to find any such initialization (and even if you will) I think an > >exception in the hid.c driver for this keyboard will be needed. > > I'll try to find out more. > > BTW, are there any known problems with the current backport and console > switching? It seems to lock down some of the modifier keys from time to > time, then you have to press all of them to get them back in a known state. > And it seems the LED status sent to USB keyboards is inverted. There seems to be a problem with some keys not getting released correctly. I wasn't able to find the cause yet. -- Vojtech Pavlik SuSE Labs |