Jump to content
Flirc Forums


  • Posts

  • Joined

  • Last visited

Everything posted by luziferius

  1. Hi, below is the solution for your problem: You will need to use the command line. You should know how to navigate through your file system and call programs using the command line. ---Theory:--- For the OS, the numpad keys are different keys than the main field number-keys. The operating system maps the same symbol (the number) to both keys. To get your mouse emulation, you need to map the low level keypad values, instead of the main key field keys. The Flirc GUI can map the main field keys only, but not the numpad keys. ---Obtaining the needed values:--- To program the numpad keys, you need the raw USB-HID values as decimal numbers, and program them with the command line tool and the tool’s record_api function. You can get the raw values from here: http://www.freebsddiary.org/APC/usb_hid_usages I’ve quoted the relevant part below: For reference, this is the main keyboard that the GUI programs into Flirc: using a Hex to decimal number converter (like this online one: http://www.statman.info/conversions/hexadecimal.html), you can convert those to decimal numbers. This is range 30-39 decimal. But you will need those: the Keypad numbers 1-0 have decimal values of 89 to 98. You can calculate the other values (+, -, / keys, etc), if needed, by simply counting down from 89. --- Programming Flirc:--- First, unlearn all the keys you want to use for the mouse emulation (with the GUI or command line tool). (For linux, the command line tool we will use is called flirc_util. For windows it *might* be called flirc_util.exe. I don’t know, as I don’t use windows, look in the program’s install folder) Now you use the command line tool to program the Keypad keys, by using the program’s record_api function: Quote from the program’s internal help: You don’t want any modifiers, so the first argument is 0 and the command is: flirc_util record_api 0 <arg> or flirc_util.exe record_api 0 <arg>, where <arg> is a number between 89 and 98. eg.: flirc_util record_api 0 89 to program the keypad 1, flirc_util record_api 0 90 to program the keypad 2, etc… so you start the program with the proper arguments for the key you want to program, then the program waits until you press a key on your remote, programs it and exits. you redo that for every key you want to map, entering the correct value as a start parameter. BTW: note for windows users: you cannot simply click a command-line program, that won’t work. You have to start the command line from the menu, navigate to the exe’s folder (use cd command) and then type the program name and its parameters. <Tab> can be used for auto-completion, <Arrow up> and <Arrow down> to recall the last entered commands (so you don’t need to retype the command 10 times, but can use <Arrow up> and edit the last command.) I hope that helps
  2. Is there any error message when you try to start the GUI program from a terminal?
  3. Hi, how many commands need to be assigned? It should be doable by combining 3 things (I don’t know if this will work or not, but it should): Doing it the way described below does not leak any key press events to any other application we could use the remaining free 'usage page 7' HID commands for that purpose, although that can be considered a hack, as those are undefined and may be redefined to whatever later(unlikely). Those key values don’t generate any high-level key press event, so we define dead keys that will not interfere with existing applications. We will use them later at the RAW device level. look here for free values under usage page 7, everything above 0xE7 seems to be free: http://code.metager.de/source/xref/NetBSD/src/lib/libusbhid/usb_hid_usages use mpris-remote as a MPRIS CLI interface. We need to work out a set of commands that do what we want and note them down. link: http://incise.org/mpris-remote.html As a user daemon we can use Touché, that is designed for exactly this purpose, namely binding otherwise dead keys to useful features: link: https://github.com/GuLinux/Touche We use this program to connect the keys with the mpris-remote commands: Bind the keys at the HIDRAW level to those mpris-remote commands (look at the README below) Touché README (extract, second half is important): mpris-remote: The software is there (except for the Flirc GUI profile, but we can use the CLI to program the Flirc hardware using flirc_util record_api command) We just need to cleverly combine what is available
  4. Hi, +1 ---------- A bit background for everyone interested: ---Everything below is 'As Far As I Know' and assumptions about the Flirc device are guesses--- The Flirc connects itself as a USB HID(Human Interface Device) to the system. The HID-specification uses several byte long 'reports' to translate hardware events to system events in a standardized way. There is 1(?) byte for the 'usage page'; this one defines something like a device class, like keyboard, mouse, joystick, LED-device, whatever… Then there are 2 (or more ?) bytes that represent the actual value that comes from/goes to the device. The value is dependent on the usage page, so the value 0x04 is something different in different usage pages. Here is a nice table listing many values for the different usage pages, this comes from the NetBSD souce tree: http://code.metager.de/source/xref/NetBSD/src/lib/libusbhid/usb_hid_usages -What about the Flirc device?- The usage page for normal keyboard keys(A-Z, numbers, F-keys, etc) is decimal 7. To output a keyboard key, the Flirc device has to send a HID-report with usage page 7 for every normal keyboard key. This has to be verified by the dev: I assume that, to save a byte in the storage, the Flirc device uses a hardcoded usage page 7 to generate all HID reports. The multimedia keys are in a different usage page, namely decimal 12, 'Consumer'. To support multimedia keys, the Flirc device has to remove the hardcoded usage page from the report generator in the firmware and load the correct page for every saved key from the memory. That’s a problem: Best case: there is enough unused space available to store that additional byte. Unlikely, as free space should be used to store more usable data. Likely: The number of available slots for key storage will be reduced by ~20-50 Worst Case: Unlikely, but possibe: The microcontroller uses some sort of sectors for memory magagement (like HDDs do). Each sector is long enough to store one 'IR signal'+'key value' pair. It cannot adress across multiple sectors. Then adding an additional byte per saved key to store would halven the storage capacity or may be completely impossible. --- Question to the dev:--- Is it possible for the Flirc device to save different usage pages and use them for generating those multimedia keys? If this is impossible (Worst Case), would it be possible to put out another firmware that is almost identical, but uses usage page 12 instead? Then you could at least turn the Flirc device into a 'multimedia only'-keyboard that only supports those multimedia keys.
  • Create New...