DaemonForums  

Go Back   DaemonForums > Miscellaneous > General Hardware

General Hardware General hardware related questions.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 19th February 2019
new2BSDlol new2BSDlol is offline
Port Guard
 
Join Date: Jun 2018
Posts: 21
Default Found a nice programmable "MMO" gaming mouse for productivity in BSD

I recently bought a couple of gaming mice with 12 thumb buttons to compare... a Logitech G600, and a Redragon Perdition (M901), both off Amazon. The G600 has the ability to program one button to change the functions of all the other buttons, doubling the number of programmable buttons available, but unfortunately the G600 can only store multi-key macros in its Windows software. The Redragon Perdition stores macros in its onboard memory, so once you program it with the (buggy, inconsistent) Windows software you can use the macros on BSD. The macro programmer can accept a maximum of 31 keypresses, or 16 keypresses if you want a delay between them. I've programmed it to speed up mouse browsing with Firefox so I don't need to reach to the keyboard with my left hand for various functions. I think Redragon have released a later mouse they call the Redragon Impact (M908) that I found on their international site www.redragonzone.com but couldn't find on www.redragonusa.com but it's also available on Amazon for about the same price, ≈$30.

The first thing to do with it is turn down its fancy RGB LED lights, disable all the DPI settings except one so it has a fixed sensitivity and you can use the DPI switches as extra buttons, and remove the mouse weights from under the cover on the bottom (unless you like a heavy mouse).

There's another mouse I'm going to try called the Rytaki R6 that I think has two buttons beside the first mouse button (redragon perdition only has one), and I have uses for another button so long as it stores macros in internal memory.

Here are some images:
Attached Images
File Type: jpg 100_1734.JPG (132.5 KB, 61 views)
File Type: png redragon software front.png (122.3 KB, 36 views)
File Type: png redragon software side.png (110.6 KB, 31 views)
File Type: png redragon software macro.png (72.7 KB, 33 views)

Last edited by new2BSDlol; 20th April 2019 at 05:18 PM.
Reply With Quote
  #2   (View Single Post)  
Old 13th April 2019
new2BSDlol new2BSDlol is offline
Port Guard
 
Join Date: Jun 2018
Posts: 21
Default

So after spending some time getting used to using the Redragon I ordered a Rytaki R6 as I said I would in the previous post, and fortunately it also remembers bindings after being programmed in Windows. Unlike Redragon Rytaki doesn't seem to have a website, maybe it is coming, but the software on the included CD works.

The side buttons are bigger which I think is a big improvement, and it has an extra button beside the left mouse-button. I have found a new way of using it where you use the inside of your thumb to push the rearmost three side buttons, and push the other 9 buttons with the tip of your thumb. It makes pushing the three rearmost buttons much easier and the bigger Rytaki buttons help with that.

The macro editor is slightly simpler than the Redragon one, and allows up to 20 keypresses (vs 31 for the Redragon – fortunately my email address requires 20 keypresses including pressing Shift+2 so I can assign it to a button). It does not allow the insertion of a standard delay between the keypresses (which the Redragon does), although it can record the actual delay that you use between keypresses when you are recording a macro. Both mice insert a small (few millisecond) delay between key events anyway... the Rytaki delay is slightly longer. The Rytaki doesn't allow the insertion of mouse clicks as part of macros, but it does include "Doubleclick" and "Tripleclick" as options for the buttons, which is fortunate for me as I actually use them. I had to insert a 20ms delay between clicks with the Redragon for the double click action to be recognised by all the operating systems I use. You have to trick the Redragon software into providing the delays so you can set up the macro by entering keypresses with a delay between them and then deleting the keypresses and adding mouse actions.

Strangely I could not find how (or it is not possible) to assign single keys to mouse buttons, edit: I just found it, it's "assign a shortcut". For some reason assigning a shift key such as ctrl, alt or shift does not work for me in Server 2012 R2 and I have to set up such shortcuts as a macro, it does work in Server 2008 R2.

The Redragon allows you to program the left and right mousebuttons and the mousewheel, but the Rytaki doesn't. Curiously both mice include a spare set of mouse feet, which is an encouragment to disassemble the mouse because the screws are under the mouse feet and normally the feet get a bit deformed when you peel them off. Which I did for the Redragon, and removed some LEDs that I couldn't deactivate with the software and then cooked the right hand side slowly with a lighter and pushed it in to remove the ledge on the right hand side, and filed it down till it would fit the base again then removed the burn marks with a dremel and sandpaper (the paint burns but the plastic behaves quite well)... because it's designed for people who rest their ring and pinky fingers on the right, and use their index finger on the right mouse button, but I rest my index finger on the mousewheel and ring finger on the right mouse button and prefer a narrower mouse. The Rytaki has a similar ledge for the ring finger plus pinky but it's less pronounced, and it's much more comfortable for my finger position.

If you don't need the extra features of the Redragon the Rytaki has an extra button and larger buttons on the side pad and a more solid feel. And if you use the same finger position as me the Rytaki is really a lot more comfortable (for people who don't have all the tools they might like for melting the right hand side of the Redragon). But they're both pretty good, I won't be going back to a 5 button mouse. And what button layout to use would need its own thread.

Some pictures:
Attached Images
File Type: jpg 100_1920.JPG (333.1 KB, 32 views)
File Type: png rytaki r6.png (341.8 KB, 22 views)
File Type: png rytaki r6 macro.png (265.3 KB, 21 views)
File Type: jpg tidied with dremel+sandpaper.JPG (151.7 KB, 19 views)

Last edited by new2BSDlol; 16th May 2019 at 06:06 AM.
Reply With Quote
  #3   (View Single Post)  
Old 7th October 2019
Object23 Object23 is offline
New User
 
Join Date: Feb 2019
Posts: 1
Default

I have made a new forum account with a slightly less silly name, but I am new2BSDlol, the original poster.

I've worked out a system that can give you about 200 hotkeys on the Rytaki R6 (the second mouse I reviewed which has 4 buttons on top) and fewer on the Redragon Perdition (which has 3) by binding modifiers to the top buttons and setting up hotkeys for the side buttons with sxhkd (simple X hotkey daemon) and xdotool.

sxhkd listens for keyboard and mouse events and executes commands when it detects "hotkeys". An alternative to sxhkd is xbindkeys, but according to the FreeBSD manpages for these two programs xbindkeys was last updated in 2007 and sxhkd in 2019. xdotool can output text or a key combination (such as ctrl+c) or mouse button clicks (amongst other abilities). An alternative to xdotool for outputting text or key combinations is xvkbd... you can use:
xvkbd -text "Text to output."
... or:
xvkbd -text "\[Alt_L]\[Left]"
... to send Alt+Left. But I just use xdotool because it's smaller and more versatile. I am interested if anyone knows how to implement some of this functionality with "expect" or test "xmacro" (possibly Linux only) or "xte" (Linux only?) or other programs, as you want the smallest quickest tool possible... xdotool and xvkbd need a ~0.2 second delay before they can send a text string reliably... more on that later.

$ ls -lh $(which expect)
-rwxr-xr-x 1 root wheel 15K Aug 22 17:44 /usr/local/bin/expect
$ ls -lh $(which xdotool)
-rwxr-xr-x 1 root wheel 75K Aug 23 00:57 /usr/local/bin/xdotool
$ ls -lh $(which xvkbd)
-rwxr-xr-x 1 root wheel 147K Oct 5 08:22 /usr/local/bin/xvkbd

sxhkd can recognise the standard modifiers:
Quote:
Originally Posted by sxhkd manpage
The valid modifier names are: super, hyper, meta, alt, control, ctrl,
shift, mode_switch, lock, mod1, mod2, mod3, mod4, mod5 and any.

The keysym names are given by the output of xev -event keyboard.
You can find keysyms in /usr/local/include/X11/keysymdef.h (FreeBSD).
You make a hotkey in sxhkd by adding lines to the config file (default ~/.config/sxhkd/sxhkdrc) like:
Code:
shift + Home
 xterm
... which opens an xterm when you press shift + Home. Any line without a space is a hotkey, any line starting with a space is a command. The sxhkd github front page has a helpful example config at the bottom https://github.com/baskerville/sxhkd.

I started looking at modifiers in X11 a few weeks ago for this mouse system, and made quite a few mistakes along the way, including in previous versions of this post. I said in a previous version of this post that I couldn't get FreeBSD to recognise the super and hyper hotkeys but Debian did. I was mistaken, I had removed the default mapping of super and hyper to mod4 in FreeBSD while I was experimenting but hadn't in Debian, however neither FreeBSD nor Debian seem to be able to distinguish between them (a shortcut for hyper can be fired by super, and the other way round). This would probably change if you mapped them to different modifiers. I also said that you could remove "level3" (key bind ISO_Level3_Shift) from mod5, which was also mistaken, if you remove "level3" from mod5 (which is used in some keyboard layouts, such as colemak) it will stop working. I have since realised that Super_L and Hyper_L and Meta_L and ISO_Level3_Shift are not modifiers by themselves, they become modifiers once they are mapped to modifiers. There are 8 modifier bits in X, their default mappings as far as I can tell (although I have read that the associations for Mod1-5 are arbitrary) are:
Shift: Shift
Lock: Caps_Lock
Control: Control
Mod1: Alt, Meta
Mod2: Num_Lock
Mod3: ISO_Level5 (if applicable)
Mod4: Super, Hyper
Mod5: ISO_Level3 (if applicable)

I've used mod3 4 and 5 (shared with level3) for the mouse. I'm not sure if this is a bad idea, but it has worked for the last couple of days.

If you enter the command "xmodmap" you'll see your modifier layout. Other useful commands and tips I've found are "setxkbmap -print" gives you information about your current keyboard layout, "xev -event keyboard" (and "xev -event mouse") gives you a window you can give focus and press buttons on your keyboard or on these mice and examine the outputs, and to apply any changes you've made to xkb files without having to log out and back in you can simply use "setxkbmap -layout us" or just "setxkbmap us" (if you use the US keyboard layout). When you use xev you will see that it specifies a "keycode" which is a decimal number. If you look in (on FreeBSD) /usr/local/share/X11/xkb/keycodes/xfree86 (which I found in the output of "setxkbmap -print" in the xkb_keycodes line) you will find the keycodes, and if the key in question is bound to a modifier and you look at "xmodmap" you will find the keycode of the key is displayed in parentheses in hexadecimal beside what the key is bound to. When looking through these files you'll find lines like:
include "level3(ralt_switch)"
... which is in /usr/local/share/X11/xkb/symbols/us on my machine in the colemak keyboard layout section. It tells xkb to look up the file level3 in the same directory and include the section "ralt_switch". Most of the important xkb files seem to be in the subfolders of-
FreeBSD: /usr/local/share/X11/xkb/
OpenBSD: /usr/X11R6/share/X11/xkb/
Debian: /usr/share/X11/xkb/

You start by binding modifier keys to the top mouse buttons. You can program any key that is on a standard keyboard to any button on these mice and the first problem is finding spare keys. My Windows keys were unused, and because I use a small 75 key programmable keyboard (an ID75 from massdrop, which is a variant of the XD75 ortholinear keyboard) with no keypad my keypad buttons were unused, and shift is a good top button as it can be detected by sxhkd as a modifier and it lets you make text selections just with your right hand (a layout I'm using is in the attachment rytaki_r6.png). I found both mice could accept left and right Windows keys as button assignments, although only the Rytaki R6 software displayed them as "R_WIN" and "L_WIN". The Redragon Perdition software showed them both as "Win" but when tested with "xev" it had recorded the keys as Super_L and Super_R. The normal keyboards I had lying around only had a left-windows key on them, but I was able to program a right-windows key onto my programmable ID75 keyboard and program the mice with that. I have made a section at the end of this post "***Right-Windows-Key***". You may be able to bind RWIN to one of the mouse buttons directly from the config files. Both these mice have the ability to bind media keys to the buttons, which you can examine with "xev -event keyboard", but these worked in Debian and not in FreeBSD (with the default xkb layout at least). I think the output of "setxkbmap -print" gives some clue. Debian:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
FreeBSD:
xkb_keymap {
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(pc105)" };
xkb_geometry { include "pc(pc105)" };
};
It may be possible to use some unused keys from foreign keyboards if you normally just use the standard "us" layout, eg if you look at ...X11/xkb/keycodes/xfree86 it includes keys generated on Japanese and Korean keyboards, but I find some of the items there mentioned in keysymdef.h, so I am not sure if they are a key or a keybind. Someone else will know better than me what would be involved.

To assign whichever keys you put on the top buttons to modifiers you can edit /usr/local/share/X11/xkb/symbols/pc (or you can do it with commands with xmodmap).
You find lines like-
modifier_map Mod4 { Super_L, Super_R };
...and # them out, and replace them with the bindings you want. When I first wrote out this post hastily before I had fully tested my suggestions I recommended that if you use "level3" you should modify ...X11/xkb/symbols/level3 and hash out the line-
modifier_map Mod5 { <LVL3> };
...from the section "modifier_mapping", however that was a mistake, if you remove that line your level3 switch will stop working. I have written some notes about avoiding collisions between level3/mod5 and hotkeys later on.

The lines defining modifiers can use either a key name as <KEYNAME> or a key bind as found in keysymdef.h or the output of "xev -event keyboard". So you can write either:
modifier_map Mod5 { Super_L };
or
modifier_map Mod5 { <LWIN> };
... to assign left windows key to Mod5. I bound keys I was using as modifiers to VoidSymbol in ...X11/xkb/symbols/pc – I have:
key <LWIN> { [ VoidSymbol ] };
modifier_map Mod5 { <LWIN> };
key <RWIN> { [ VoidSymbol ] };
modifier_map Mod4 { <RWIN> };
... and when I check "xmodmap" "VoidSymbol" has been assigned to mod4 and mod5, but has a different hex keycode beside it for mod4 and mod5 (it is the keycode from "xev -event keyboard" (and on my system ...X11/xkb/keycodes/xfree86) converted from decimal to hex).

If you look at the attachment rytaki_r6.png you'll see the layout I'm using right now with LWIN (as mod3) and RWIN (as mod4) and shift and KP_2 (keypad 2 as mod5) on my top buttons.
In ...X11/xkb/symbols/keypad I have-
key <KP2> { [ VoidSymbol ] };
... and in ...X11/xkb/symbols/pc I have-
modifier_map Mod5 { <KP2> };
I have also removed the binding for Mod2 (formerly Num_Lock) so I can use it to make hotkeys on my keyboard (I have it on a thumbkey between ctrl and alt, so I can easily press mod2 or mod2+ctrl or mod2+alt with one finger, essentially giving me three modifier layers), so my xmodmap looks like:
Code:
shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Meta_L (0x9c)
mod2        VoidSymbol (0x57)
mod3        VoidSymbol (0x74)
mod4        VoidSymbol (0x73)
mod5        Mode_switch (0x8),  VoidSymbol (0x58),  ISO_Level3_Shift (0x7c)
When I used "xev" to detect a keypress and held down the key it would output the key once, then repeat it rapidly as we are used to. After I had bound a key to VoidSymbol and made it a modifier if I held the key down "xev" would detect the key being pressed, and there would be no more detections until it was released. It seems X is intelligent, changing a key's behaviour when it is turned into a modifier.

Once you've created some modifiers it's time to create an array of hotkeys. If you use my layout you'll have 12×15 possible hotkeys with the Rytaki R6's 4 top buttons (although in practice some of them are quite hard to press), and I think you'd have 12×7 hotkeys on a Redragon Perdition.
1 - 12 base keys
combined with-
2 - LWIN
3 - RWIN
4 - KP2
5 - LWIN+RWIN
6 - KP2+shift
7 - LWIN+KP2
8 - RWIN+KP2
9 - LWIN+shift
10 - RWIN+shift
11 - LWIN+RWIN+KP2
12 - LWIN+RWIN+shift
13 - LWIN+KP2+shift
14 - RWIN+KP2+shift
15 - LWIN+RWIN+KP2+shift
LWIN and RWIN (and LWIN+RWIN) plus mousewheelup and mousewheeldown are possible as well, as mwheel up and down are detected as button 4 and button 5 by "xev -event mouse" and sxhkd recognises button1 to button24. The extra buttons on these mice won't be detected as mouse buttons if they're bound to keyboard events.

There are various complications. If you bind shift to a top button so you can select text with it then you may not want to bind shortcuts to "shift + side-button" if shift+side-button is a combination you might accidentally press during keyboard usage, eg I could make binds for shift+space-
Code:
shift + space
 xterm
... but I would be too likely to press that key combination by mistake when typing rapidly and might end up opening random xterms.
You can get around this issue by binding a spare key to a mouse button and making a hotkey out of it in sxhkd, eg suppose KP_3 (keypad 3) is spare-
Code:
KP_3
 sleep .25;xdotool key space
... and then you can make a new hotkey for the shifted position-
Code:
shift + KP_3
 xterm
With those hotkeys shift+space won't open an xterm. This method has a downside. When you hold down a mouse button bound to a key it will output the key once, then after a pause start rapidly outputting the key like normal. This might be useful for a button like backspace. But if you bind a button to a key and turn the key into a hotkey with sxhkd that behaviour disappears. Perhaps you could program that behaviour back in using something like "xdotool click --delay 5000 --repeat 200 1", and maybe using xbindkeys or the sxhkd "@" feature to detect key release events to cancel the repeating.

You actually need to use this method to get certain shortcuts working on the Redragon which I uncovered by examining its output with "xev -event keyboard". Some of my side buttons were bound to single keys like Page_Up or Home or Backspace, and some were "Combo keys" (as the Redragon software calls them) like alt+Left (back in browser) or ctrl+c. If I made a hotkey like-
Code:
mod4 + ctrl + c
 xterm
... it would work when I pressed the mod4 button then the ctrl+c button with the Rytaki R6. It would be detected by "xev -event keyboard" as:
Mod4 down
Ctrl down
c down
c up
Ctrl up
Mod4 up
But with the Redragon when I tried a modifier plus a combo key the Redragon was releasing the modifier key as soon as the combo was started, so I would get:
Mod4 down
Ctrl down
Mod4 up
c down
c up
Ctrl up
... and the hotkey didn't work. You can get around that as described above by setting side buttons to keypad (or other) buttons, and then setting up hotkeys with xdotool... so if Ctrl+c becomes KP_7 then in sxhkdrc-
Code:
KP_7
 sleep 0.25;xdotool key ctrl+c
This successfully intercepts the KP_7 key and the number "7" is never outputted as far as I can tell. And then I could use combos with that button with the Redragon:
Code:
mod4 + KP_7
 sleep 0.25;xdotool type -delay 0 emailaddress@provider.com
Shifted versions of hotkeys need to be bound separately, eg if you have a combination like mod4 + Page_Up that outputs ctrl+z pressing shift + mod4 + Page_Up is treated as its own unique key and will not output ctrl+shift+z.

In the code above you may see I inserted a "sleep .25" before the xdotool command. I found that a delay was unfortunately necessary for both xdotool and xvkbd to output text reliably. I raced them against each other and both needed a slightly greater than .1 second delay to avoid the start of outputted text being clipped. xdotool with the "-delay 0" option "types" text out more quickly than xvkbd. I used a .2 second delay for a day and once one of my commands to output text only printed the last half of the message, so I've increased my standard delay to .25 seconds. I expect if my system load was high a higher delay would be needed. Needing a delay like this is a bit of a disappointment, I would be very interested in a better method of outputting text and mouse button clicks than xdotool if someone knows of or can invent one. I have considered moving xdotool to a RAM drive. I had a brief play around with setting the priority of sxhkd and xdotool with nice but it didn't seem to have any effect. You can set pauses in tiny increments eg sleep 0.092, sleep 0.093 etc so it is easy to accurately test the speed of different programs and methods, although there seems to be quite a bit of spread in the length of the pause needed, ranging from about .1 to over .2.

However some hotkeys did not need a delay to work, I'm not really sure why but they are all cases where xdotool has to send a single key. Doubleclick and tripleclick didn't need it.
Code:
mod4 + {Right,Up}
 xdotool click 1;xdotool click 1;{_,xdotool click 1}
A hotkey that turns mousewheel up/down into page up/down didn't need it (but it didn't work in one of my applications, Geany, and neither did a similar hotkey to bind mousewheel to left and right arrow, Firefox and mousepad and emacs were fine).
Code:
mod4 + {button4,button5}
 xdotool key {Page_Up,Page_Down}
For some reason the mod4 + mousewheel hotkey only worked when I removed Super_L and Hyper_L from mod4 in ...X11/xkb/symbols/pc.

You will want to make sure that a hotkey does not immediately trigger another hotkey, eg if a modifier plus a key types out a line of text with xdotool you are likely to still be holding the modifier while the text is typed.

If you're using level3 bound to mod5 in your keyboard layout then pressing a hotkey with mod5 that outputs text such as with "xdotool key ctrl+a" (outputs "a") or "xdotool type 'hello world'" then if you're still holding mod5 while the text is output it will be transformed by level3 into a string of strange characters. xdotool has a feature that we can use to get around that which is "keyup" and "keydown". "xdotool keydown <key>" only issues a keydown event, and similar for "keyup". So we can use mod5 in a hotkey like:
Code:
mod5 + BackSpace
 sleep 0.25;xdotool keyup ISO_Level3_Shift;xdotool type -delay 0 emailaddress
You could also try the xdotool "--clearmodifiers" switch:
Quote:
Originally Posted by xdotool manpage
CLEARMODIFIERS
Any command taking the --clearmodifiers flag will attempt to clear any active input modifiers during
the command and restore them afterwards.
I had some unstable behaviour with the --clearmodifiers flag and had to restart my window manager, while "xdotool keyup shift" worked fine. Or you can put a "@" before a key, this makes the command happen when the key is released instead of when it is depressed, which can ensure the key is not depressed when the command runs.
A scheme that I tried to let me use level3 shift to start commands with my keyboard was to put special characters into my keyboard layout, and try to turn them into hotkeys, eg ...X11/xkb/symbols/us:
key <AD01> { [ q, Q, adiaeresis, Adiaeresis ] };
Code:
adiaeresis
 xterm
This didn't work, sxhkd gave the output:
No keycodes found for keysym 228.
But some keys will work like that, eg:
Code:
ampersand
 xterm
... will start an xterm when you press shift+7.

Another behaviour of the Rytaki mouse that I was able to correct using xdotool keydown was in this hotkey:
Code:
mod3 + shift + {button4,button5}
 xdotool key {Home,End}
I found that when the hotkey was activated the shift key was released during the script, so if you held mod3 and shift and used the hotkey and were holding mod3 and shift down at the end of it only mod3 would still be registered. It was fixed with:
Code:
mod3 + shift + {button4,button5}
 xdotool key {Home,End};xdotool keydown shift
Another nuance is that if you have a hotkey like:
Code:
mod4 + shift + backspace
 sleep 0.25;xdotool key alt+1
... then the keycode sent will be alt+shift+1. If you want to send just alt+1 by holding down mod4+shift+backspace you must use:
Code:
mod4 + shift + backspace
 sleep 0.25;xdotool keyup shift;xdotool key alt+1
If you want to be able to repeat it you would need:
Code:
mod4 + shift + backspace
 sleep 0.25;xdotool keyup shift;xdotool key alt+1
I've added my sxhkrc as an attachment.

Sometimes behaviour can be unstable, eg for some of my complicated hotkeys I find I have to release the buttons quite quickly after pressing them or strange things start to happen.

If you want one of these mice and need a version of Windows to use to program them you may want to use the evaluation versions of Server 2008 R2 and Server 2012 R2 which you can download free from Microsoft. You can use them free for a while (180 days or so), and after that they'll stay on for an hour before shutting down. This is fine for doing odd jobs like programming a mouse, or some other small task that requires Windows. This expired site is useful https://web.archive.org/web/20161125...rkstation.com/.

With the way mechanical keyboards are evolving I suppose it be a matter of time till someone puts an arduino in a many-button mouse and we can program it in QMK with layers and all the features.

***Right-Windows-Key***

The two "normal" keyboards I have apart from my mechanical keyboard that uses programmable QMK firmware only have "left Window keys". I was able to program a right Windows key onto my keyboard and program that onto the mice. Looking at the output of the mice with "xev" showed that they had accurately recorded left and right Windows keys (the Rytaki R6 software showed them as "L_WIN" and "R_WIN", and the Redragon Perdition software showed them both as "Win"). Once I had programmed the mice I looked for config files to find where the RWIN button had been programmed, and hopefully you can use what I found if you want to use the RWIN/Super_R button but don't have a keyboard with a right Windows key to program the mouse with (once you get a RWIN key on any mouse button you can use it to program a new layout with RWIN on any other button).

On Server 2008 R2, for the Rytaki-
\Program Files (x86)\Gaming Mouse\config\Default0.gmp
...is profile 1 (there are 5 profiles). I programmed the mouse first with Win_L and Win_R on buttons B1 and 14, then reversed them, and compared the profiles.
Code:
$ diff Default0.gmp Default0.gmp.b
73c73
< MacroKeyInfo12=0C05000000000000000000000000000000000000000000000000000000000000000000000100E700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000F9
---
> MacroKeyInfo12=0C05000000000000000000000000000000000000000000000000000000000000000000000100E300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000F5
75c75
< MacroKeyInfo14=0E05000000000000000000000000000000000000000000000000000000000000000000000100E300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000F7
---
> MacroKeyInfo14=0E05000000000000000000000000000000000000000000000000000000000000000000000100E700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FB
Hopefully if you copy those into your config files you will have a right Windows key.
And for the Redragon, you can save a config or load a new one with the software... the configs appear in "Documents\PERDITION Gaming Mouse\" as .pfd files... and hopefully this will be enough information for you to get a right-windows key on the mouse if you want to (these are two pfd files I saved from the software):
Code:
$ diff 1.pfd 2.pfd 
28,29c28,29
< ButtonAssigned_4=E30000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000E3
< ButtonAssigned_5=E705801D05801D0500E0050000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015
---
> ButtonAssigned_4=E70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000E7
> ButtonAssigned_5=E305801D05801D0500E0050000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011
Attached Images
File Type: png rytaki_r6_20191106.png (398.1 KB, 2 views)
Attached Files
File Type: txt sxhkdrc_20191106.txt (3.4 KB, 2 views)

Last edited by Object23; 2 Weeks Ago at 10:28 AM.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference between"arp info overwritten" and " duplicate IP address " varag OpenBSD Security 1 6th April 2015 02:57 PM
"no root device found" while installing kondziq FreeBSD Installation and Upgrading 4 29th November 2011 10:01 AM
San Francisco's "network kidnapper" found guilty J65nko News 0 28th April 2010 09:49 PM
Fixed "xinit" after _7 _8, "how" here in case anyones' "X" breaks... using "nvidia" jb_daefo Guides 0 5th October 2009 09:31 PM
TIP:a nice way to make your pf more "stealth" marc OpenBSD Security 2 30th January 2009 09:39 PM


All times are GMT. The time now is 09:58 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick