As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label xinput. Show all posts

· · · · · ·

Last week, We Wish You a Merry Christmas was playing somewhere, an idea came to me, what if your computer sings one note on every key you press? That would be fun, wouldn’t it?

And here is the merryxmas.sh and a video to demonstrate.

https://i.ytimg.com/vi/D1gXN7wZ7IM/maxresdefault.jpg

1   About the code

I decided to write it entirely in Bash with some tools, such as xinput and play from Sox.

I could have forked the xinput to modify and strip it for this purpose, it would be cleaner since I really don’t have any idea how to handle the buffer issue1. But with shell scripting, it’s easier to modify if there are suitable tools.

Originally, I was going for only keyboard presses, but then I added mouse clicks, and then the movements. It turned out pretty nice.

As for xinput and its test, unfortunately, it can only monitor one device and you also need to specify the device name. I needed to get both keyboard and mouse events in altogether at the same time, I tried to use mkfifo, but that didn’t work, so I resolved with regular files and those would increase in file size.

Its test-xi2 works for all input devices, but it pops up a window like xev and that wouldn’t be a good surprise for your family and friends, right?

The choice of sound playing is play from Sox, which I don’t believe many computer would have it, but at least it’s included in almost all distributions’ package managers. I could go with wave, but you would have to download and compile it. But it might be a better option, because I doubt anyone would have your target’s computer’s password to gain root access for using package manager to install Sox

[1]As you are required to run with stdbuf, without it, due to the buffer size, you will have to press a lot to get the song singing.

2   Some ideas

This script is just a basic one. I could think of a few more that you can wish your family and friends:

  1. Run Xsnow while or after playing.
  2. Pop up a message box or using xdotool2 to type in the message.
  3. Only play a note when hitting one of “xmas” or “christmas” keys.
  4. Play the whole song at once if “xmas” or “christmas” is exactly spelled.

I personally, like 1 and 4, especially 4, because during this holiday season, you can be sure the chance that a user would type the word in is very high, almost unavoidable. They can be writing an email to family and friends, just as typing in the subject line, the computer sings. Wouldn’t that be fun?

[2]I use xdotool to enter timestamp.

· · · · · ·

I recently found out you can use xinput to enable or disable an input device. I used to use synclient to disable my touchpad, or using this tricky way to disable my laptop keyboard.

The first step to get device name or id of the device:


% xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ USB Optical Mouse                         id=8    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=7    [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ Power Button                              id=10   [slave  keyboard (3)]
    ↳ Video Bus                                 id=11   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=6    [slave  keyboard (3)]

For touchpad, the device name is 'SynPS/2 Synaptics TouchPad' and id is 7; for keyboard, they are 'AT Translated Set 2 keyboard' and 6. Next step is to know the properties of a device:


% xinput list-props 'AT Translated Set 2 keyboard'
Device 'AT Translated Set 2 keyboard':
        Device Enabled (127):   1

This keyboard only has a property 'Device Enabled' whose value is 1, that means this keyboard is enabled. To test disabling:


sleep 0.1 ; xinput set-prop 'AT Translated Set 2 keyboard' 'Device Enabled' 0 ; sleep 5 ; xinput set-prop 'AT Translated Set 2 keyboard' 'Device Enabled' 1

The first sleep 0.1 is to prevent enter keypress being repeatedly sent somehow when you directly disable the keyboard, I am guessing when you hit the enter and the command is executed, meaning the keyboard is disabled, but the keyup event is not yet sent, so X still thinks the enter key is pressed down.

Another simple way is to use id, so you don’t need long device name:


sleep 0.1 ; xinput set-prop 8 127 0 ; sleep 5 ; xinput set-prop 8 127 1

8 is id of this keyboard and 127 is the property id of 'Device Enabled'. When you list properties of device using list-props, the numbers after property names are the property ids. It seems that 'Device Enabled' always has id 127, but device id is not always the same. It depends on device attached time, who shows up first who gets next available id.

One more thing to note: I don’t need root privilege to set property value.

Subscribe to: Posts (Atom)