Mailing List Archive: MythTV: Users

different key remappings for different keyboards?

Index | Next | Previous | View Threaded

j2u44u at gmail

Feb 8, 2010, 9:37 AM

Post #1 of 13 (1387 views)
Permalink

different key remappings for different keyboards?

My myth frontend has two keyboards -- the regular one, and a nice VRC-1100
remote control (all buttons register as keypresses).

I would like the buttons that generate ESC and BACKSPACE remapped on the
remote control, which I can do easily enough with xmodmap. But I'd also like
the buttons on the regular keyboard to *not* be remapped. I don't think
there is any way to do that with xmodmap, since the mappings are not
device-specific. But maybe it can be done lower down, like with setkeycodes?
Has anyone played with this?

Thanks,
-j

foceni at gmail

Feb 8, 2010, 10:50 AM

Post #2 of 13 (1347 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 02/08/2010 06:37 PM, j2u4 j2u4 wrote:
> My myth frontend has two keyboards -- the regular one, and a nice
> VRC-1100 remote control (all buttons register as keypresses).
>
> I would like the buttons that generate ESC and BACKSPACE remapped on the
> remote control, which I can do easily enough with xmodmap. But I'd also
> like the buttons on the regular keyboard to *not* be remapped. I don't
> think there is any way to do that with xmodmap, since the mappings are
> not device-specific. But maybe it can be done lower down, like with
> setkeycodes? Has anyone played with this?
>
> Thanks,
> -j
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

You could consider routing your two devices via lircd's dev/input driver
and identifying them using /dev/input/by-path, which is guaranteed to
survive reboot and USB hot-plug as long as it's physically in the same
USB port.

This might involve some serious re-configuration of key mapping (well,
depending on your setup), but then you could assign completely different
actions to each device - for different applications. Lirc also allows
neat stuff like state machines - one buttons enters a "nested" mode,
allowing for example to execute & operate another application (while the
original doesn't know about it) and then another button-event returns
you back to top-level configuration. It's quite useful, even when you
have just MythTV (single application). I use a similar setup to have one
button enter a special "admin" mode - from there I can start
mythtv-setup on a different workspace, tune it and return back after
exitting; or start a DB cleanup (reset default channels, etc); or
restart DVB-related daemons. The possibilities are endless.

It might not be for you, though, it takes time to set up and all you
really want is changing one keyboard's key code. :) If so, use keyfuzz
(if it still works?) to update scan & key code translation tables for
individual /dev/input devices.

So in short: yes, it's possible. ;)

--
David Kubicek
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Feb 8, 2010, 2:01 PM

Post #3 of 13 (1345 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 02/08/2010 12:37 PM, j2u4 j2u4 wrote:
> My myth frontend has two keyboards -- the regular one, and a nice
> VRC-1100 remote control (all buttons register as keypresses).
>
> I would like the buttons that generate ESC and BACKSPACE remapped on
> the remote control, which I can do easily enough with xmodmap. But I'd
> also like the buttons on the regular keyboard to *not* be remapped. I
> don't think there is any way to do that with xmodmap, since the
> mappings are not device-specific. But maybe it can be done lower down,
> like with setkeycodes? Has anyone played with this?

This is the entire reason LIRC was invented.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

foceni at gmail

Feb 8, 2010, 2:06 PM

Post #4 of 13 (1350 views)
Permalink

Re: different key remappings for different keyboards? [kernel-level SOLUTION] [In reply to]

On 02/08/2010 07:50 PM, David Kubicek wrote:
> On 02/08/2010 06:37 PM, j2u4 j2u4 wrote:
>> My myth frontend has two keyboards -- the regular one, and a nice
>> VRC-1100 remote control (all buttons register as keypresses).
>>
>> I would like the buttons that generate ESC and BACKSPACE remapped on the
>> remote control, which I can do easily enough with xmodmap. But I'd also
>> like the buttons on the regular keyboard to *not* be remapped. I don't
>> think there is any way to do that with xmodmap, since the mappings are
>> not device-specific. But maybe it can be done lower down, like with
>> setkeycodes? Has anyone played with this?
>>

I checked keyfuzz out (I mentioned it earlier) and it works great, I
just had to find a few things which changed in kernel since then make
two changes in the source accordingly. Remember, you're changing the
runtime translation tables in the very heart on the Linux INPUT system,
so this mapping is completely transparent on all levels. No other
configuration is necessary.

You need to install these packages: xmltoman, gengetopt, gperf,
joystick. Plus, of course, gcc, autoconf, automake and similar tools
(some are in pkg "build-essential" in Debian/Ubuntu). Then get the
source and apply my attached patch:

# git clone git://git.0pointer.de/keyfuzz.git
# cd keyfuzz
# ./bootstrap.sh
# ./configure
# cd src
# patch -p1 < keyfuzz.patch
# make

Done. Now find which /dev/input device corresponds to which keyboard
(using "lsinput" from input-utils) or "lshal" can tell you directly if
you don't mind searching for a while.

Now to scancode/keycode mapping. The following will print out the
complete mapping table. Save it. :)

# src/keyfuzz -d /dev/input/event4 --get

You need to find a line like this if you want to remap ESC:

0x70029 KEY_ESC

Think of another mapping you want that scan code (HW button) to map to
and when ready (let's say ESC key should be TAB), run:

# echo "0x70029 KEY_TAB" | src/keyfuzz -d /dev/input/event4 --set

You can include several commands like this in your /etc/rc.local or
similar location to make them permanent. Possibly copy the keyfuzz
binary into /usr/local/bin/ (or run "make install" if you don't mind the
unnecessary mess).

The complete list of KEY_* values is in /usr/include/linux/input.h
For testing your results, use "evtest" tool from the joystick package I
listed.

That's it, easy. Except this won't work for input devices requiring
"uinput" module. It's a kernel INPUT driver for user-space daemons (like
BlueZ) which allows them to plug into kernel INPUT. So most IR and BT
keyboards cannot be remapped in this way. Uinput doesn't keep a keymap
table, it's a responsibility of the user-space application. You'd have
to hack on BlueZ or Lirc daemon sources to change the mapping.

--
David Kubicek

Attachments:

keyfuzz.patch (0.94 KB)

j2u44u at gmail

Feb 8, 2010, 3:57 PM

Post #5 of 13 (1345 views)
Permalink

Re: different key remappings for different keyboards? [kernel-level SOLUTION] [In reply to]

This looks *exactly* like what I was looking for. Thanks for the work and
the explanation David -- I'll try it out tonight!

-j

On Mon, Feb 8, 2010 at 3:06 PM, David Kubicek <foceni [at] gmail> wrote:

> On 02/08/2010 07:50 PM, David Kubicek wrote:
>
>> On 02/08/2010 06:37 PM, j2u4 j2u4 wrote:
>>
>>> My myth frontend has two keyboards -- the regular one, and a nice
>>> VRC-1100 remote control (all buttons register as keypresses).
>>>
>>> I would like the buttons that generate ESC and BACKSPACE remapped on the
>>> remote control, which I can do easily enough with xmodmap. But I'd also
>>> like the buttons on the regular keyboard to *not* be remapped. I don't
>>> think there is any way to do that with xmodmap, since the mappings are
>>> not device-specific. But maybe it can be done lower down, like with
>>> setkeycodes? Has anyone played with this?
>>>
>>>
> I checked keyfuzz out (I mentioned it earlier) and it works great, I just
> had to find a few things which changed in kernel since then make two changes
> in the source accordingly. Remember, you're changing the runtime translation
> tables in the very heart on the Linux INPUT system, so this mapping is
> completely transparent on all levels. No other configuration is necessary.
>
> You need to install these packages: xmltoman, gengetopt, gperf, joystick.
> Plus, of course, gcc, autoconf, automake and similar tools (some are in pkg
> "build-essential" in Debian/Ubuntu). Then get the source and apply my
> attached patch:
>
> # git clone git://git.0pointer.de/keyfuzz.git
> # cd keyfuzz
> # ./bootstrap.sh
> # ./configure
> # cd src
> # patch -p1 < keyfuzz.patch
> # make
>
> Done. Now find which /dev/input device corresponds to which keyboard (using
> "lsinput" from input-utils) or "lshal" can tell you directly if you don't
> mind searching for a while.
>
> Now to scancode/keycode mapping. The following will print out the complete
> mapping table. Save it. :)
>
> # src/keyfuzz -d /dev/input/event4 --get
>
> You need to find a line like this if you want to remap ESC:
>
> 0x70029 KEY_ESC
>
> Think of another mapping you want that scan code (HW button) to map to and
> when ready (let's say ESC key should be TAB), run:
>
> # echo "0x70029 KEY_TAB" | src/keyfuzz -d /dev/input/event4 --set
>
> You can include several commands like this in your /etc/rc.local or similar
> location to make them permanent. Possibly copy the keyfuzz binary into
> /usr/local/bin/ (or run "make install" if you don't mind the unnecessary
> mess).
>
> The complete list of KEY_* values is in /usr/include/linux/input.h
> For testing your results, use "evtest" tool from the joystick package I
> listed.
>
> That's it, easy. Except this won't work for input devices requiring
> "uinput" module. It's a kernel INPUT driver for user-space daemons (like
> BlueZ) which allows them to plug into kernel INPUT. So most IR and BT
> keyboards cannot be remapped in this way. Uinput doesn't keep a keymap
> table, it's a responsibility of the user-space application. You'd have to
> hack on BlueZ or Lirc daemon sources to change the mapping.
>
>
> --
> David Kubicek
>

j2u44u at gmail

Feb 8, 2010, 4:11 PM

Post #6 of 13 (1344 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
> This is the entire reason LIRC was invented.

This remote appears as a normal keyboard,* not as an IR device...
Maybe I don't understand LIRC -- does it control normal usb input
devices (mouse and keyboard) as well as IR controllers?

-j

* actually, it appears as two devices, one is a keyboard, and the
other is a mouse. It's quite the nice little jobber.

pebender at san

Feb 8, 2010, 5:29 PM

Post #7 of 13 (1330 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 2/8/2010 4:11 PM, j2u4 j2u4 wrote:
> On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
> > This is the entire reason LIRC was invented.
>
> This remote appears as a normal keyboard,* not as an IR device...
> Maybe I don't understand LIRC -- does it control normal usb input
> devices (mouse and keyboard) as well as IR controllers?
>
> -j
>
> * actually, it appears as two devices, one is a keyboard, and the
> other is a mouse. It's quite the nice little jobber.

LIRC handles many device types, including input devices. The LIRC
daemon's configuration file (lircd.conf) file can remap the KEY_* and
BTN_* events from an input device, so it can be easily used to do the
mapping you want. Alternatively, the mapping can be done from within the
LIRC client configuration file (lircrc) based on both device type and
application.

Also, the LIRC CVS version handles forwarding mouse events to a mouse
device created using uinput. As a result, it can easily split out the
BTN_*, REL_* and ABS_* events so they can be handled by something other
than LIRC.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

daworm at comcast

Feb 8, 2010, 8:32 PM

Post #8 of 13 (1310 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

j2u4 j2u4 wrote:
> I would like the buttons that generate ESC and BACKSPACE remapped on
> the remote control, which I can do easily enough with xmodmap. But I'd
> also like the buttons on the regular keyboard to *not* be remapped. I
> don't think there is any way to do that with xmodmap, since the
> mappings are not device-specific. But maybe it can be done lower down,
> like with setkeycodes? Has anyone played with this?

Looks perfect for gizmod.

http://gizmod.sourceforge.net/

Jeff.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

foceni at gmail

Feb 9, 2010, 3:40 AM

Post #9 of 13 (1279 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 02/09/2010 01:11 AM, j2u4 j2u4 wrote:
> On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
> > This is the entire reason LIRC was invented.
>
> This remote appears as a normal keyboard,* not as an IR device...
> Maybe I don't understand LIRC -- does it control normal usb input
> devices (mouse and keyboard) as well as IR controllers?
>
> -j
>
> * actually, it appears as two devices, one is a keyboard, and the
> other is a mouse. It's quite the nice little jobber.
>

It doesn't by default, but you can route dev/input devices via Lirc and
some Lirc drivers register their remotes into Linux INPUT framework as
regular mice/keyboards.

Usually, this uinput limitation doesn't concern you. It applies mostly
to BT devices (like my PS3 BD remote), but for those remapping is not
really required.

One device appearing as two is normal, all wireless kbd/mouse combos do
this. The important thing is keyfuzz can remap per device, so you're
covered.

--
David Kubicek
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

j2u44u at gmail

Feb 9, 2010, 8:47 AM

Post #10 of 13 (1258 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On Tue, Feb 9, 2010 at 4:40 AM, David Kubicek <foceni [at] gmail> wrote:

> On 02/09/2010 01:11 AM, j2u4 j2u4 wrote:
>
>> On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
>> > This is the entire reason LIRC was invented.
>>
>> This remote appears as a normal keyboard,* not as an IR device...
>> Maybe I don't understand LIRC -- does it control normal usb input
>> devices (mouse and keyboard) as well as IR controllers?
>>
>> -j
>>
>> * actually, it appears as two devices, one is a keyboard, and the
>> other is a mouse. It's quite the nice little jobber.
>>
>>
> It doesn't by default, but you can route dev/input devices via Lirc and
> some Lirc drivers register their remotes into Linux INPUT framework as
> regular mice/keyboards.
>
> Usually, this uinput limitation doesn't concern you. It applies mostly to
> BT devices (like my PS3 BD remote), but for those remapping is not really
> required.
>
> One device appearing as two is normal, all wireless kbd/mouse combos do
> this. The important thing is keyfuzz can remap per device, so you're
> covered.

Yeah, keyfuzz worked great. Exactly what I was looking for, and super easy
to set up (with your instructions). Thanks again!

-j

>

foceni at gmail

Feb 9, 2010, 10:25 AM

Post #11 of 13 (1240 views)
Permalink

Re: different key remappings for different keyboards? [In reply to]

On 02/09/2010 05:47 PM, j2u4 j2u4 wrote:
> On Tue, Feb 9, 2010 at 4:40 AM, David Kubicek <foceni [at] gmail
> <mailto:foceni [at] gmail>> wrote:
>
> On 02/09/2010 01:11 AM, j2u4 j2u4 wrote:
>
> On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
> > This is the entire reason LIRC was invented.
>
> This remote appears as a normal keyboard,* not as an IR device...
> Maybe I don't understand LIRC -- does it control normal usb input
> devices (mouse and keyboard) as well as IR controllers?
>
> -j
>
> * actually, it appears as two devices, one is a keyboard, and the
> other is a mouse. It's quite the nice little jobber.
>
>
> It doesn't by default, but you can route dev/input devices via Lirc
> and some Lirc drivers register their remotes into Linux INPUT
> framework as regular mice/keyboards.
>
> Usually, this uinput limitation doesn't concern you. It applies
> mostly to BT devices (like my PS3 BD remote), but for those
> remapping is not really required.
>
> One device appearing as two is normal, all wireless kbd/mouse combos
> do this. The important thing is keyfuzz can remap per device, so
> you're covered.
>
>
>
> Yeah, keyfuzz worked great. Exactly what I was looking for, and super
> easy to set up (with your instructions). Thanks again!
>

I actually prefer plain INPUT devices, e.g. like remotes supported by
v4l-dvb etc, because it's completely universal. You can also emulate
mouse, but the important thing is all applications can be controlled by
them (no lirc support required) and input focus/sharing is done
automatically by X & WM.

On the other hand, Lirc allows advanced configurations more in line with
the "remote control" concept we're used to from consumer electronics.
Each approach has its perks and disadvantages. I had to switch to Lirc
eventually to be able to implement everything I wanted.

--
David Kubicek
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Feb 9, 2010, 11:32 AM

Post #12 of 13 (1243 views)
Permalink

Re: different key remappings for different keyboards? [kernel-level SOLUTION] [In reply to]

On 02/08/2010 07:07 PM, Alen Peacock wrote:
> On 02/08/2010 10:01:54 PM, Michael T. Dean wrote:
>
>> This is the entire reason LIRC was invented.
>>
> This remote appears as a normal keyboard,* not as an IR device...
> Maybe I don't understand LIRC -- does it control normal usb input
> devices (mouse and keyboard) as well as IR controllers?
>
> -j
>
> * actually, it appears as two devices, one is a keyboard, and the
> other is a mouse. It's quite the nice little jobber.
>

See, that's the thing... Because the kernel developers are operating
under some false impression that you can remap keyboard keys in such a
ways as to make a) all applications and b) all users happy, they have
included drivers in the kernel that allow basically every remote in
existence to be used as a "normal keyboard, not as an IR device."
Fortunately, those who are willing to do a little bit of extra
configuration can cause that same remote to be used as a LIRC device
(through a variety of mechanisms--blacklisting the kernel keyboard
driver for the remote and instead installing a LIRC driver for the
remote, using the LIRC /dev/input driver with the remote, ...).

The specific configuration required is left as an exercise to the reader
(in other words, I have no clue how to make that specific remote work,
but I'd guess the easiest approach would be using the /dev/input driver
for LIRC).

With the kernel keyboard driver approach you're forced to change the
keysyms (symbolic name of a key on a keyboard) associated with the
keycodes (or scan codes--roughly corresponding to a physical key on the
keyboard), as interpreted by the kernel. With the LIRC approach, you
can actually specify on a /per-application/ basis the exact
string/message that's sent to the application (where Myth uses strings
that correspond to keysyms) when LIRC receives the input event from a
button press. Therefore, you don't have to reconfigure every single
application's key bindings such that they work the way you want them to
work for your "keyboard" and you don't have to use every "keyboard" the
same way (i.e. the physical position of the keys is irrelevant) and you
don't have to modify the kernel keyboard driver to interpret scan codes
as different key codes.

Basically, LIRC puts the configuration of keyboard/remote into a LIRC
configuration rather than requiring you to configure every app to use a
single, specific keyboard configuration. <my $0.02>Kernel keyboard
drivers for remotes are for users who want Plug 'n' Play (and you get
what you're given) configuration and would prefer to reconfigure
themselves/their way of thinking rather than reconfigure their
systems.</my $0.02>

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

foceni at gmail

Feb 9, 2010, 3:10 PM

Post #13 of 13 (1225 views)
Permalink

Re: different key remappings for different keyboards? [kernel-level SOLUTION] [In reply to]

On 02/09/2010 08:32 PM, Michael T. Dean wrote:
> With the kernel keyboard driver approach you're forced to change the
> keysyms (symbolic name of a key on a keyboard) associated with the
> keycodes (or scan codes--roughly corresponding to a physical key on the
> keyboard), as interpreted by the kernel. With the LIRC approach, you can
> actually specify on a /per-application/ basis the exact string/message
> that's sent to the application (where Myth uses strings that correspond
> to keysyms) when LIRC receives the input event from a button press.
> Therefore, you don't have to reconfigure every single application's key
> bindings such that they work the way you want them to work for your
> "keyboard" and you don't have to use every "keyboard" the same way (i.e.
> the physical position of the keys is irrelevant) and you don't have to
> modify the kernel keyboard driver to interpret scan codes as different
> key codes.
>
> Basically, LIRC puts the configuration of keyboard/remote into a LIRC
> configuration rather than requiring you to configure every app to use a
> single, specific keyboard configuration. <my $0.02>Kernel keyboard
> drivers for remotes are for users who want Plug 'n' Play (and you get
> what you're given) configuration and would prefer to reconfigure
> themselves/their way of thinking rather than reconfigure their
> systems.</my $0.02>
>

You're right and I agree, it depends on one's point of view and personal
requirements. Lirc isn't that easy and straightforward to configure, but
allows for a much greater deal freedom, creativity and complexity.
Srsly, we should rejoice for the gift of freedom of choice our kernel
devs provide. :)

--
David Kubicek
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads