Binding Mouse Button to Another Mouse Button with xbindkeys - XEV bugs out





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







2















I have a Logitech M720 Mouse that I'm hoping to bind the side button (usually page forward) to the middle click button - something that I've done on my Windows with Logitech Options.



After researching, I've found that I will need to do it via xbindkeys and xautomation.



I tested out the key presses with xev and found that the side button is button 9, and middle scrollwheel button is button 2.



I then made my .xbindkeysrc file as such:



"xte 'mouseclick 2'"
b:9


However after repolling the rc file on xbindkeys, the key bind is not recognised anywhere on my system, and doing an xev test returns a peculiar result:



USUALS RESULT ON DEPRESSING BUTTON 9



ButtonPress event, serial 37, synthetic NO, window 0x4a00001,
root 0x1dd, subw 0x0, time 38400097, (160,106), root:(160,169),
state 0x0, button 9, same_screen YES

ButtonRelease event, serial 37, synthetic NO, window 0x4a00001,
root 0x1dd, subw 0x0, time 38400237, (160,106), root:(160,169),
state 0x0, button 9, same_screen YES


RESULTS AFTER XBINDKEYSRC FILE MODIFICATION (BUTTON 9)



KeymapNotify event, serial 37, synthetic NO, window 0x0,
keys: 4294967261 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


even after clearing out my .xbindkeysrc file, the output is still the same, and will only return to normal after i killall xbindkeys and restart by typing xbindkeys in the terminal.



I found this this thread with a potential solution but unfortunately did not work for me.



Binding the button press to anything else for example "xte 'key a'" works as expected.



Anyone with any pointers what I might be doing wrong?



Cheers.










share|improve this question





























    2















    I have a Logitech M720 Mouse that I'm hoping to bind the side button (usually page forward) to the middle click button - something that I've done on my Windows with Logitech Options.



    After researching, I've found that I will need to do it via xbindkeys and xautomation.



    I tested out the key presses with xev and found that the side button is button 9, and middle scrollwheel button is button 2.



    I then made my .xbindkeysrc file as such:



    "xte 'mouseclick 2'"
    b:9


    However after repolling the rc file on xbindkeys, the key bind is not recognised anywhere on my system, and doing an xev test returns a peculiar result:



    USUALS RESULT ON DEPRESSING BUTTON 9



    ButtonPress event, serial 37, synthetic NO, window 0x4a00001,
    root 0x1dd, subw 0x0, time 38400097, (160,106), root:(160,169),
    state 0x0, button 9, same_screen YES

    ButtonRelease event, serial 37, synthetic NO, window 0x4a00001,
    root 0x1dd, subw 0x0, time 38400237, (160,106), root:(160,169),
    state 0x0, button 9, same_screen YES


    RESULTS AFTER XBINDKEYSRC FILE MODIFICATION (BUTTON 9)



    KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys: 4294967261 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


    even after clearing out my .xbindkeysrc file, the output is still the same, and will only return to normal after i killall xbindkeys and restart by typing xbindkeys in the terminal.



    I found this this thread with a potential solution but unfortunately did not work for me.



    Binding the button press to anything else for example "xte 'key a'" works as expected.



    Anyone with any pointers what I might be doing wrong?



    Cheers.










    share|improve this question

























      2












      2








      2








      I have a Logitech M720 Mouse that I'm hoping to bind the side button (usually page forward) to the middle click button - something that I've done on my Windows with Logitech Options.



      After researching, I've found that I will need to do it via xbindkeys and xautomation.



      I tested out the key presses with xev and found that the side button is button 9, and middle scrollwheel button is button 2.



      I then made my .xbindkeysrc file as such:



      "xte 'mouseclick 2'"
      b:9


      However after repolling the rc file on xbindkeys, the key bind is not recognised anywhere on my system, and doing an xev test returns a peculiar result:



      USUALS RESULT ON DEPRESSING BUTTON 9



      ButtonPress event, serial 37, synthetic NO, window 0x4a00001,
      root 0x1dd, subw 0x0, time 38400097, (160,106), root:(160,169),
      state 0x0, button 9, same_screen YES

      ButtonRelease event, serial 37, synthetic NO, window 0x4a00001,
      root 0x1dd, subw 0x0, time 38400237, (160,106), root:(160,169),
      state 0x0, button 9, same_screen YES


      RESULTS AFTER XBINDKEYSRC FILE MODIFICATION (BUTTON 9)



      KeymapNotify event, serial 37, synthetic NO, window 0x0,
      keys: 4294967261 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


      even after clearing out my .xbindkeysrc file, the output is still the same, and will only return to normal after i killall xbindkeys and restart by typing xbindkeys in the terminal.



      I found this this thread with a potential solution but unfortunately did not work for me.



      Binding the button press to anything else for example "xte 'key a'" works as expected.



      Anyone with any pointers what I might be doing wrong?



      Cheers.










      share|improve this question














      I have a Logitech M720 Mouse that I'm hoping to bind the side button (usually page forward) to the middle click button - something that I've done on my Windows with Logitech Options.



      After researching, I've found that I will need to do it via xbindkeys and xautomation.



      I tested out the key presses with xev and found that the side button is button 9, and middle scrollwheel button is button 2.



      I then made my .xbindkeysrc file as such:



      "xte 'mouseclick 2'"
      b:9


      However after repolling the rc file on xbindkeys, the key bind is not recognised anywhere on my system, and doing an xev test returns a peculiar result:



      USUALS RESULT ON DEPRESSING BUTTON 9



      ButtonPress event, serial 37, synthetic NO, window 0x4a00001,
      root 0x1dd, subw 0x0, time 38400097, (160,106), root:(160,169),
      state 0x0, button 9, same_screen YES

      ButtonRelease event, serial 37, synthetic NO, window 0x4a00001,
      root 0x1dd, subw 0x0, time 38400237, (160,106), root:(160,169),
      state 0x0, button 9, same_screen YES


      RESULTS AFTER XBINDKEYSRC FILE MODIFICATION (BUTTON 9)



      KeymapNotify event, serial 37, synthetic NO, window 0x0,
      keys: 4294967261 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


      even after clearing out my .xbindkeysrc file, the output is still the same, and will only return to normal after i killall xbindkeys and restart by typing xbindkeys in the terminal.



      I found this this thread with a potential solution but unfortunately did not work for me.



      Binding the button press to anything else for example "xte 'key a'" works as expected.



      Anyone with any pointers what I might be doing wrong?



      Cheers.







      keyboard shortcut-keys mouse xbindkeys






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Mar 25 at 16:32









      Woon Wu ChyiWoon Wu Chyi

      111




      111






















          1 Answer
          1






          active

          oldest

          votes


















          1














          xbindkeys



          I think that you need a third line for each of your shortcuts. Maybe it's not a must, but I'm looking at the examples I have set up:



          "pactl set-sink-volume @DEFAULT_SINK@ +5%"
          m:0x4 + c:112
          Control + Prior

          "pactl set-sink-volume @DEFAULT_SINK@ -10%"
          m:0x4 + c:117
          Control + Next

          # xautomation package
          # Print Date
          '"xte "keyup Super_L" "keyup Insert" "str `date +%Y.%m.%d`" "usleep 10" "keydown Super_L""'
          m:0x40 + c:118
          Mod4 + Insert


          So, each of my entries has a third line, which defines the shortcut. Also, we have to release the pressed keys ourselves, and typically before the command we run. This is further complicated with Shift, as I've found releasing Shift causes problems.





          xmodmap (user specific)



          Typically, xbindkeys is used for complicated bindings, or to run scripts/commands. You could give modmap a try, which might be closer to the core of what you're trying to accomplish. Using xev, or evtest, you can determine the Key Code that is used by the mouse, and then tell X to interpret it as another Key Code.



          ~/.Xmodmap



          keycode 97 = Control_R NoSymbol Control_R


          ~/.xinitrc



          [[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmodmap


          This tells X how to handle Key Code 97 (random, non-mouse) when pressed normally, or with modifiers (Shift, Alt, etc). You'd have the mappings in ~/.Xmodmap and load it via $ modmap ~/.Xmodmap, typically alongside X, so in ~/.xinitrc. evtest is 'better' than xev in that it will help you to find the device you want to test, vs make you fumble around the system finding it in the /dev lists.





          udev (system-wide)



          Another solution is to use udev/evdev, and to have the system perform this translation, regardless of if/when you start X, and with each connection of the device. This is a bit more complicated, but once you get used to some settings, you can work to migrate them here.



          Custom rules are places in /etc/udev/hwdb.d/ This is the hardware database [configuration] directory. These are loaded in order, so files are normally prefixed with two digits, but this only matters when later rules overwrite earlier rules. This is a list of devices, by USB bus, device and vendor IDs. This method is ideal because you can remap keys for a specific keyboard, and not all keyboards.



          /etc/udev/hwdb.d/99-myMouse.hwdb



          evdev:input:bIDvIDpID1*
          KEYBOARD_KEY_210=menu

          evdev:input:bIDvIDpID2*
          KEYBOARD_KEY_210=menu


          This example finds two input devices, on the same USB bus, and from the same Vendor, but with different IDs. Both map Key Code 210 to the Menu button. You can learn to remap the keys on your mouse this way as well.



          The system will have hwdb files in another directory, /usr/lib/udev/hwdb.d. These files should not be edited, but you can use them as examples to help along the way.



          After making changes, the database needs to be updated:



          sudo systemd-hwdb update





          share|improve this answer


























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "89"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1128590%2fbinding-mouse-button-to-another-mouse-button-with-xbindkeys-xev-bugs-out%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            xbindkeys



            I think that you need a third line for each of your shortcuts. Maybe it's not a must, but I'm looking at the examples I have set up:



            "pactl set-sink-volume @DEFAULT_SINK@ +5%"
            m:0x4 + c:112
            Control + Prior

            "pactl set-sink-volume @DEFAULT_SINK@ -10%"
            m:0x4 + c:117
            Control + Next

            # xautomation package
            # Print Date
            '"xte "keyup Super_L" "keyup Insert" "str `date +%Y.%m.%d`" "usleep 10" "keydown Super_L""'
            m:0x40 + c:118
            Mod4 + Insert


            So, each of my entries has a third line, which defines the shortcut. Also, we have to release the pressed keys ourselves, and typically before the command we run. This is further complicated with Shift, as I've found releasing Shift causes problems.





            xmodmap (user specific)



            Typically, xbindkeys is used for complicated bindings, or to run scripts/commands. You could give modmap a try, which might be closer to the core of what you're trying to accomplish. Using xev, or evtest, you can determine the Key Code that is used by the mouse, and then tell X to interpret it as another Key Code.



            ~/.Xmodmap



            keycode 97 = Control_R NoSymbol Control_R


            ~/.xinitrc



            [[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmodmap


            This tells X how to handle Key Code 97 (random, non-mouse) when pressed normally, or with modifiers (Shift, Alt, etc). You'd have the mappings in ~/.Xmodmap and load it via $ modmap ~/.Xmodmap, typically alongside X, so in ~/.xinitrc. evtest is 'better' than xev in that it will help you to find the device you want to test, vs make you fumble around the system finding it in the /dev lists.





            udev (system-wide)



            Another solution is to use udev/evdev, and to have the system perform this translation, regardless of if/when you start X, and with each connection of the device. This is a bit more complicated, but once you get used to some settings, you can work to migrate them here.



            Custom rules are places in /etc/udev/hwdb.d/ This is the hardware database [configuration] directory. These are loaded in order, so files are normally prefixed with two digits, but this only matters when later rules overwrite earlier rules. This is a list of devices, by USB bus, device and vendor IDs. This method is ideal because you can remap keys for a specific keyboard, and not all keyboards.



            /etc/udev/hwdb.d/99-myMouse.hwdb



            evdev:input:bIDvIDpID1*
            KEYBOARD_KEY_210=menu

            evdev:input:bIDvIDpID2*
            KEYBOARD_KEY_210=menu


            This example finds two input devices, on the same USB bus, and from the same Vendor, but with different IDs. Both map Key Code 210 to the Menu button. You can learn to remap the keys on your mouse this way as well.



            The system will have hwdb files in another directory, /usr/lib/udev/hwdb.d. These files should not be edited, but you can use them as examples to help along the way.



            After making changes, the database needs to be updated:



            sudo systemd-hwdb update





            share|improve this answer






























              1














              xbindkeys



              I think that you need a third line for each of your shortcuts. Maybe it's not a must, but I'm looking at the examples I have set up:



              "pactl set-sink-volume @DEFAULT_SINK@ +5%"
              m:0x4 + c:112
              Control + Prior

              "pactl set-sink-volume @DEFAULT_SINK@ -10%"
              m:0x4 + c:117
              Control + Next

              # xautomation package
              # Print Date
              '"xte "keyup Super_L" "keyup Insert" "str `date +%Y.%m.%d`" "usleep 10" "keydown Super_L""'
              m:0x40 + c:118
              Mod4 + Insert


              So, each of my entries has a third line, which defines the shortcut. Also, we have to release the pressed keys ourselves, and typically before the command we run. This is further complicated with Shift, as I've found releasing Shift causes problems.





              xmodmap (user specific)



              Typically, xbindkeys is used for complicated bindings, or to run scripts/commands. You could give modmap a try, which might be closer to the core of what you're trying to accomplish. Using xev, or evtest, you can determine the Key Code that is used by the mouse, and then tell X to interpret it as another Key Code.



              ~/.Xmodmap



              keycode 97 = Control_R NoSymbol Control_R


              ~/.xinitrc



              [[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmodmap


              This tells X how to handle Key Code 97 (random, non-mouse) when pressed normally, or with modifiers (Shift, Alt, etc). You'd have the mappings in ~/.Xmodmap and load it via $ modmap ~/.Xmodmap, typically alongside X, so in ~/.xinitrc. evtest is 'better' than xev in that it will help you to find the device you want to test, vs make you fumble around the system finding it in the /dev lists.





              udev (system-wide)



              Another solution is to use udev/evdev, and to have the system perform this translation, regardless of if/when you start X, and with each connection of the device. This is a bit more complicated, but once you get used to some settings, you can work to migrate them here.



              Custom rules are places in /etc/udev/hwdb.d/ This is the hardware database [configuration] directory. These are loaded in order, so files are normally prefixed with two digits, but this only matters when later rules overwrite earlier rules. This is a list of devices, by USB bus, device and vendor IDs. This method is ideal because you can remap keys for a specific keyboard, and not all keyboards.



              /etc/udev/hwdb.d/99-myMouse.hwdb



              evdev:input:bIDvIDpID1*
              KEYBOARD_KEY_210=menu

              evdev:input:bIDvIDpID2*
              KEYBOARD_KEY_210=menu


              This example finds two input devices, on the same USB bus, and from the same Vendor, but with different IDs. Both map Key Code 210 to the Menu button. You can learn to remap the keys on your mouse this way as well.



              The system will have hwdb files in another directory, /usr/lib/udev/hwdb.d. These files should not be edited, but you can use them as examples to help along the way.



              After making changes, the database needs to be updated:



              sudo systemd-hwdb update





              share|improve this answer




























                1












                1








                1







                xbindkeys



                I think that you need a third line for each of your shortcuts. Maybe it's not a must, but I'm looking at the examples I have set up:



                "pactl set-sink-volume @DEFAULT_SINK@ +5%"
                m:0x4 + c:112
                Control + Prior

                "pactl set-sink-volume @DEFAULT_SINK@ -10%"
                m:0x4 + c:117
                Control + Next

                # xautomation package
                # Print Date
                '"xte "keyup Super_L" "keyup Insert" "str `date +%Y.%m.%d`" "usleep 10" "keydown Super_L""'
                m:0x40 + c:118
                Mod4 + Insert


                So, each of my entries has a third line, which defines the shortcut. Also, we have to release the pressed keys ourselves, and typically before the command we run. This is further complicated with Shift, as I've found releasing Shift causes problems.





                xmodmap (user specific)



                Typically, xbindkeys is used for complicated bindings, or to run scripts/commands. You could give modmap a try, which might be closer to the core of what you're trying to accomplish. Using xev, or evtest, you can determine the Key Code that is used by the mouse, and then tell X to interpret it as another Key Code.



                ~/.Xmodmap



                keycode 97 = Control_R NoSymbol Control_R


                ~/.xinitrc



                [[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmodmap


                This tells X how to handle Key Code 97 (random, non-mouse) when pressed normally, or with modifiers (Shift, Alt, etc). You'd have the mappings in ~/.Xmodmap and load it via $ modmap ~/.Xmodmap, typically alongside X, so in ~/.xinitrc. evtest is 'better' than xev in that it will help you to find the device you want to test, vs make you fumble around the system finding it in the /dev lists.





                udev (system-wide)



                Another solution is to use udev/evdev, and to have the system perform this translation, regardless of if/when you start X, and with each connection of the device. This is a bit more complicated, but once you get used to some settings, you can work to migrate them here.



                Custom rules are places in /etc/udev/hwdb.d/ This is the hardware database [configuration] directory. These are loaded in order, so files are normally prefixed with two digits, but this only matters when later rules overwrite earlier rules. This is a list of devices, by USB bus, device and vendor IDs. This method is ideal because you can remap keys for a specific keyboard, and not all keyboards.



                /etc/udev/hwdb.d/99-myMouse.hwdb



                evdev:input:bIDvIDpID1*
                KEYBOARD_KEY_210=menu

                evdev:input:bIDvIDpID2*
                KEYBOARD_KEY_210=menu


                This example finds two input devices, on the same USB bus, and from the same Vendor, but with different IDs. Both map Key Code 210 to the Menu button. You can learn to remap the keys on your mouse this way as well.



                The system will have hwdb files in another directory, /usr/lib/udev/hwdb.d. These files should not be edited, but you can use them as examples to help along the way.



                After making changes, the database needs to be updated:



                sudo systemd-hwdb update





                share|improve this answer















                xbindkeys



                I think that you need a third line for each of your shortcuts. Maybe it's not a must, but I'm looking at the examples I have set up:



                "pactl set-sink-volume @DEFAULT_SINK@ +5%"
                m:0x4 + c:112
                Control + Prior

                "pactl set-sink-volume @DEFAULT_SINK@ -10%"
                m:0x4 + c:117
                Control + Next

                # xautomation package
                # Print Date
                '"xte "keyup Super_L" "keyup Insert" "str `date +%Y.%m.%d`" "usleep 10" "keydown Super_L""'
                m:0x40 + c:118
                Mod4 + Insert


                So, each of my entries has a third line, which defines the shortcut. Also, we have to release the pressed keys ourselves, and typically before the command we run. This is further complicated with Shift, as I've found releasing Shift causes problems.





                xmodmap (user specific)



                Typically, xbindkeys is used for complicated bindings, or to run scripts/commands. You could give modmap a try, which might be closer to the core of what you're trying to accomplish. Using xev, or evtest, you can determine the Key Code that is used by the mouse, and then tell X to interpret it as another Key Code.



                ~/.Xmodmap



                keycode 97 = Control_R NoSymbol Control_R


                ~/.xinitrc



                [[ -f ~/.Xmodmap ]] && xmodmap ~/.Xmodmap


                This tells X how to handle Key Code 97 (random, non-mouse) when pressed normally, or with modifiers (Shift, Alt, etc). You'd have the mappings in ~/.Xmodmap and load it via $ modmap ~/.Xmodmap, typically alongside X, so in ~/.xinitrc. evtest is 'better' than xev in that it will help you to find the device you want to test, vs make you fumble around the system finding it in the /dev lists.





                udev (system-wide)



                Another solution is to use udev/evdev, and to have the system perform this translation, regardless of if/when you start X, and with each connection of the device. This is a bit more complicated, but once you get used to some settings, you can work to migrate them here.



                Custom rules are places in /etc/udev/hwdb.d/ This is the hardware database [configuration] directory. These are loaded in order, so files are normally prefixed with two digits, but this only matters when later rules overwrite earlier rules. This is a list of devices, by USB bus, device and vendor IDs. This method is ideal because you can remap keys for a specific keyboard, and not all keyboards.



                /etc/udev/hwdb.d/99-myMouse.hwdb



                evdev:input:bIDvIDpID1*
                KEYBOARD_KEY_210=menu

                evdev:input:bIDvIDpID2*
                KEYBOARD_KEY_210=menu


                This example finds two input devices, on the same USB bus, and from the same Vendor, but with different IDs. Both map Key Code 210 to the Menu button. You can learn to remap the keys on your mouse this way as well.



                The system will have hwdb files in another directory, /usr/lib/udev/hwdb.d. These files should not be edited, but you can use them as examples to help along the way.



                After making changes, the database needs to be updated:



                sudo systemd-hwdb update






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 25 at 18:36

























                answered Mar 25 at 17:23









                earthmeLonearthmeLon

                6,6981951




                6,6981951






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1128590%2fbinding-mouse-button-to-another-mouse-button-with-xbindkeys-xev-bugs-out%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    數位音樂下載

                    When can things happen in Etherscan, such as the picture below?

                    格利澤436b