can't control mouse while running pystromo

I notice that if I run pystromo with the extra verbose switches that it does recognize that I'm moving my mouse-- somehow the information is not getting passed along...

First, I believe you need to define your remapping section to the specific device, as in [map:g5]. This definition in section "[map:]" without a device is likely to lead to problems because it applies to all devices grabbed by the 'pystromo remapper' and you don't really want that in this instance if you are mapping anything else, such as a Speedpad. Situational awareness is critical in key mapping.

Note that "test.map" (in the installation "pystromo/config" directory) says delays don't block other events being processed. Mouse movement is one such "other event". Have you tried increasing the delay between keystrokes? 10 milliseconds is inhumanly fast (1/100 of a second), so a HID driver will probably filter it out as "noise". I would guess anything less than 150 (15/100 of a second) is (or should be) filtered out. If not, and you hold down the mouse button, the system might be spending so much time processing the "button pressed" event it doesn't have time to process other events. (A reason why you should try to have a key continuously output something.) This is supported by your evidence of the verbose switch, which would introduce it's own delays to output messages to the screen which is relatively slower. I have found "Key+250" to about as quick as the system will recognize a normal keystroke under Wine when it needs to poll the key being depressed long enough to determine it must be deliberate. That same delay between keystrokes also seems to be necessary for it to decide the key has been released, though I usually use 500. But your system may need more or less. Try halving the difference between your test values up or down until you find your "sweet spot".

You stated your intent was to repeat a key. As defined, you get a single output of the key followed by a 10 millisecond delay every time you press the left mouse button. If you wanted it to press the button once and have it spit out 5 instances of that keystroke and delay, you need to put that many instances into the definition, as in:
BTN_LEFT:KEY_O,10,KEY_O,10,KEY_O,10,KEY_O,10,KEY_O,10

All this is laid out in "test.map".

Most keys generate their value as a single event. Only certain keys appear to be "sticky" in that they act as "on/off" toggles. These are the ones that accept "key@1" and "key@0" definitions. These keys appear to be the LEDs (both on the Speedpad and the keyboard), and "state" keys such as "Shift", "Ctrl", and "Alt". As long as they are "on" (@1) they modify the state for all subsequent keys in the same definition. This is based upon an explain in an earlier Q&A here; it's not in "test.map".

Hope this helps.

--LaneW

Well-- perhaps I didn't adequately describe the problem. I describe what I wanted to do-- but my problem is that even if I have something as simple as this as my config:

#Logitech g5
[Device:g5]
vendor=0x046d
product=0xc049

[Map:g5]

Leaving the map blank still blocks pystromo from passing the mouse movements on-- regardless of trying to remap its keys.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

bump

I should also mention that I've gotten my keyboard to remap just fine... but for whatever reason the mouse doesn not =/

I'll have to look into this further.
Have you tried explicitly mapping the mouse motions back onto themselves?
REL_X: REL_X
REL_Y: REL_Y
etc.

And as a minor correction to Lane's otherwise awesome reply (thanks Lane!), any key (unless it's changed since I last tested) can be made 'sticky' by setting @1/@0 in the mapping.
This is often not a good idea though as, if you're not *very* careful, it can quite easily leave you in a position which is very difficult to get out of. I had to restart my machine once because it would do little but continually send "4" to whichever application had focus! XD

I just gave that a shot-- still no luck. Same result: when run with the -vv switch the mouse pointer is stationary but I can see relative mouse movement print lines fly by.

I confirmed this behaviour over the weekend. But I'm not entirely sure what's causing it at this point.