search

pez2001 / razer_chroma_drivers

A collection of Linux drivers for Razer Chroma devices, it supports all lighting modes and includes a daemon for advanced effects + gui configuration app
GNU General Public License v2.0
231 stars 31 forks source link

Enhancement / Need Help - MACRO #76

Closed igorbb closed 5 years ago

igorbb commented 8 years ago

I have written a on-the-fly macro recorder/ player called MacroW It is working with a Razer Blackwidow Chroma.

1 - As you have more keyboards maybe could help extend the list of supported ones? Tell me if works with your devices ?

2 - Maybe add the MacroW script has one of its dependencies so that 'razer_chroma_drivers' have on the fly macro recording and playback ?

https://github.com/igorbb/MacroW

lah7 commented 8 years ago

Thank you for sharing, as feedback I can confirm this works no problems on Ubuntu MATE 15.10 on the Razer BlackWidow Chroma (the only one I have) and only when activating marco keys.

Are you planning to pull request this into this repository (under a GPL license)? it would make it easier later to maintain and possibly integrate with other existing features, such as:

... just as a few ideas.

igorbb commented 8 years ago

I have no problem changing the license. So that is no problem, ans yes I am planning to do a pull request. But I need some guidance.

Maybe a Pull request with a macro_handler.py would suffice ?

Maybe it would be a good idea to leave the original MacroW repository untouched because it has the potential to help users with other keyboards ( Logitech and any other ones with dedicated macro keys) ? What do you think ?

terricain commented 8 years ago

Looks nice, we should see if we could get the macro key working to use Fn+F9 (I think that's the combo).

As for the actual macro recording code, I'm not sure if it's worth having a separate script doing the recording or including it into the app or even including it into the dameon

Question 1 : The macro_handler script should be in /install_files/init.d/ to be automatically run ?

Would depend on how its included as above. Personally the less start up scripts the better. As remember we will need init.d, upstart and systemd scripts, all of which would need to be maintained.

Question 2 : How to update the dependencies list ?

If we re-arrange the packaging, we could include the dependencies into the .deb file which would take care of that. Other than that we would need to keep track of dependencies and include it into the readme.

Personally I would move to add macro functionality to the daemon. It already reads the keyboard device files to get key presses. Though it would be significantly easier to add it to a thread of the tray applet as that can run all the time.

Also if the whole script was to be included it would have to be converted to python 3 but I would suggest incorporating that functionality into our python library.

igorbb commented 8 years ago 
 Looks nice, we should see if we could get the macro key working to use Fn+F9 (I think that's the combo).

I could not make it work with the fn key, i can try some more...

I see that most of the things are running in python3...

It would be easier if the macro handling code is done in python 3? Then we can try append the functionality either to the tray or daemon.

I can migrate the code to macro python 3 and we think from there ?

terricain commented 8 years ago

I could not make it work with the fn key, i can try some more...

You might need to use the driver to enable macro keys, that way I think it might send different keycodes for Fn+F9. You can verify this with xev.

As everything apart from the daemon (is in C) is in python3 it would make sense and be far easier to package if it were python3 (plus my IDE doesn't like mixed python2/python3 ;) ).

It would be no easy feat putting it into the daemon but @pez2001 shouldn't have too much trouble as he knows the daemon better than I. Otherwise we could add it to our python library and the tray applet could utilise that in a thread.

igorbb commented 8 years ago

Okay. I will try to write the python3 package in the next weekend.

And we can discuss with @pez2001 if we go for daemon or for tray/applet.

igorbb commented 8 years ago

About FN+F9.

My FN key does not work as a modifier. ( Holding it generates lots of Key presses and not single one like ALT)

Maybe it needs further activation as the Mx Keys ?? Do any of you guys know if this is the intended behavior ? Also if there is a special way to turn on the macro led ?

terricain commented 8 years ago

I'll look into the Fn+F9

As for how to turn on the Macro LED its been bugging me for ages, can't seem to manage it, maybe @pez2001 has any ideas.

ghost commented 8 years ago

Throwing in my two cents here. Don't know if it will help:

Fn creates a lot of keysym 0x0, NoSymbol data for me. I know it functions properly in (physical) Windows, though. I don't know if it needs an update through Synapse as I've never installed it. Because of how sparse Linux support is for this keyboard I'm afraid to rock the boat with that.

igorbb commented 8 years ago

I can hack it to work with FN F9. That would not be a problem, just not elegant. :P It seems FN should act as modifier....

But still no idea about the LED. Let us see what @terrycain finds out.

terricain commented 8 years ago

Ahh yeah, Fn is not a modifier as the synapse app handles it as a regular key. What you would need to do is store if keycode 202 is down, then if keycode 75 is pressed whilst 202 is down then do macro.

Just for reference

M1 - keycode 191
M2 - keycode 192
M3 - keycode 193
M4 - keycode 194
M5 - keycode 195
Fn - keycode 202
F9 - keycode 75

As for the Macro LED i'll have another look this week but it has eluded me thus far.

igorbb commented 8 years ago

Cool @terrycain . Those are the same keycode that i got. Maybe later I will implement a modifier for Mx keys. So we can Have ALT+Mx as well.

pez2001 commented 8 years ago

i guess the macro led is implemented the 'old fashioned way'. x has a tool to change the led state (xkbsetled ?). i would start my investigation there.

terricain commented 8 years ago

@pez2001 will look into that. That blasted LED has been bugging me for a long time

terricain commented 8 years ago

Just a quick update, took a little break from my project today, I got FN working with your code. The only think is that it doesn't prevent the F9 key still being sent to whatever application is in focus when really we want to block the FN+F9 being sent to focused applications.

igorbb commented 8 years ago

I see.

So I suppose that you get FN as another key, not as a modifier, right ? In Windows F9 Is blocked whenever FN is pressed ? And it is coded as a modifier?

Maybe the solution would be to turn it to a key-modifier. I do not know how we can do this... maybe while FN is pressed we can high jack all key-presses until it is released.

If you want you can send a PR to MacroW. When all these things are settled we merge to the razer_chorma.

But if you are in a hurry I can just push the Macrow.py to the razer_chorma without integrating it.... And we modified form that. I am really pressed with my PhD to change MacroW any time soon.

01001001011001110110111101110010

On Tue, Mar 1, 2016 at 12:35 PM, Terry Cain notifications@github.com wrote:

Just a quick update, took a little break from my project today, I got FN working with your code. The only think is that it doesn't prevent the F9 key still being sent to whatever application is in focus when really we want to block the FN+F9 being sent to focused applications.

— Reply to this email directly or view it on GitHub https://github.com/pez2001/razer_chroma_drivers/issues/76#issuecomment-190680388 .

terricain commented 8 years ago

I'm not in a hurry yet as am finishing my final project at the moment.

As for how. I added a variable that is set when FN is down, its a normal key so we can get events on key down and key up. And then when F9 is pressed it checks if FN is down. On 1 Mar 2016 13:04, "igorbb" notifications@github.com wrote:

I see.

So I suppose that you get FN as another key, not as a modifier, right ? In Windows F9 Is blocked whenever FN is pressed ? And it is coded as a modifier?

Maybe the solution would be to turn it to a key-modifier. I do not know how we can do this... maybe while FN is pressed we can high jack all key-presses until it is released.

If you want you can send a PR to MacroW. When all these things are settled we merge to the razer_chorma.

But if you are in a hurry I can just push the Macrow.py to the razer_chorma without integrating it.... And we modified form that. I am really pressed with my PhD to change MacroW any time soon.

01001001011001110110111101110010

On Tue, Mar 1, 2016 at 12:35 PM, Terry Cain notifications@github.com wrote:

Just a quick update, took a little break from my project today, I got FN working with your code. The only think is that it doesn't prevent the F9 key still being sent to whatever application is in focus when really we want to block the FN+F9 being sent to focused applications.

— Reply to this email directly or view it on GitHub < https://github.com/pez2001/razer_chroma_drivers/issues/76#issuecomment-190680388

.

— Reply to this email directly or view it on GitHub https://github.com/pez2001/razer_chroma_drivers/issues/76#issuecomment-190715339 .

terricain commented 8 years ago

Ok, I've got macro's working on a side project I've been working on. It uses FN+F9 to start macro recording, you then press a key to be used as the macro key, then type the macro then FN+F9 again to stop. It also sets the macro LED to flashing or static. Also when I've made an interface for it, it can also do things like open url's etc... Will tidy it all up and add it to the repo at some point.