general remote control mechanism (was: Re: [linux-dvb] Hauppauge Nova-T PCI on Fedora Core 3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 08 March 2005 00:42, Oliver Endriss wrote:
> Patrick Boettcher wrote:
> > On Mon, 7 Mar 2005, Oliver Endriss wrote:
> > 
> > > In kernel 2.6 there are 2 ioctls to manipulate keymaps
> > > - EVIOCGKEYCODE
> > > - EVIOCSKEYCODE
> > > Fine, they could be used to implement generic keymaps. But...
> > 
> > I think this is what Gerd is using in his 
> > http://dl.bytesex.org/cvs-snapshots/input-<version>.tar.gz 
> > keymap-upload-tool. (He just pointed that out in another mail)
> 
> Yes, exactly.
> 
> Unfortunately, there is no user-friendly way to *create* a keymap.
> Remote controls are not keyboards, there is no standardization.

Remote controls are as close to keyboards as it can be any other device,
so why not leverage on that and put any missing pieces into the kernel?

> An user must be able to create a keymap without reading log files.

Well, this is mostly not possible even with special keyboards..ie you
read the dmesg to tell what key was pressed that did not register
with the kernel, and then use scancode to input info..

> Well, I have no problem if the keymap support would be improved.
> Anyway, most problems could be avoided if we would simply fill the gaps
> in the keymap (if the keymap is small enough, of course).

I'm still convinced that a standard keyboard input device would do..

> The budget-ci driver has a fixed keymap of size 64 (2^6).
> The gaps will cause dead keys if you use a generic RC5 remote control
> or the vendor delivers a new type of remote control.
> It's very easy to fill these gaps, and it would not break anything.

Which is not uncommon on keyboards not known to the kernel..

> The input driver supports keymaps with 8/16/32 bit scan codes.
> Unfortunately, these key maps must be contiguous.
> Not a problem for 8 bit keymaps, but memory is wasted if 16/32 bit scan
> codes are being used...

Are you beeing serious, we're talking bits here?

> I'd really like to improve keymap support but imho the input driver does
> not provide a good infrastructure to do this:
> - no way to read raw scan codes

There is a utility to output keycodes to the terminal, only I can't remember
what name it got, even with a quick shell test..

> - no way to pass setup information to the driver

Setup options is passed wia setkeycodes or sysfs.

> - no support for sparse keymaps

What, please explain..

Kenneth



[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux