Mouse clicks do not work correctly in QT applications

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
5
down vote

favorite












I run Gnome as my desktop environment, and the mouse works fine. However, when I try to use a QT application, mouse clicks don't work correctly. For example, if I click and release inside a text editor, it begins highlighting the text as if I'm still holding down the mouse button. It's as if it doesn't register the mouse up event.



Any ideas why this might be happening, or how to troubleshoot it?







share|improve this question




















  • I'm seeing this problem as well and haven't found any useful information or work arounds.
    – dvj
    Jun 1 at 18:10














up vote
5
down vote

favorite












I run Gnome as my desktop environment, and the mouse works fine. However, when I try to use a QT application, mouse clicks don't work correctly. For example, if I click and release inside a text editor, it begins highlighting the text as if I'm still holding down the mouse button. It's as if it doesn't register the mouse up event.



Any ideas why this might be happening, or how to troubleshoot it?







share|improve this question




















  • I'm seeing this problem as well and haven't found any useful information or work arounds.
    – dvj
    Jun 1 at 18:10












up vote
5
down vote

favorite









up vote
5
down vote

favorite











I run Gnome as my desktop environment, and the mouse works fine. However, when I try to use a QT application, mouse clicks don't work correctly. For example, if I click and release inside a text editor, it begins highlighting the text as if I'm still holding down the mouse button. It's as if it doesn't register the mouse up event.



Any ideas why this might be happening, or how to troubleshoot it?







share|improve this question












I run Gnome as my desktop environment, and the mouse works fine. However, when I try to use a QT application, mouse clicks don't work correctly. For example, if I click and release inside a text editor, it begins highlighting the text as if I'm still holding down the mouse button. It's as if it doesn't register the mouse up event.



Any ideas why this might be happening, or how to troubleshoot it?









share|improve this question











share|improve this question




share|improve this question










asked Jan 15 at 4:19









Ben Davis

959712




959712











  • I'm seeing this problem as well and haven't found any useful information or work arounds.
    – dvj
    Jun 1 at 18:10
















  • I'm seeing this problem as well and haven't found any useful information or work arounds.
    – dvj
    Jun 1 at 18:10















I'm seeing this problem as well and haven't found any useful information or work arounds.
– dvj
Jun 1 at 18:10




I'm seeing this problem as well and haven't found any useful information or work arounds.
– dvj
Jun 1 at 18:10










1 Answer
1






active

oldest

votes

















up vote
0
down vote













Finally, a general solution!



The problem is caused by Qt's support for touch screens. What I've done is use xinput to disable the touch screen:



$ xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DLL06E5:01 06CB:7A13 Touchpad id=14 [slave pointer (2)]
⎜ ↳ ELAN Touchscreen id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
[... bunch of keyboard stuff]


The "ELAN Touchscreen" input is the one we care about. It's id is 13. So:



$ xinput --disable 13


With the touch screen input turned off, the problem no longer happens. I don't have to restart the Qt applications that are already running. Touch can be reenabled with:



$ xinput --enable 13


This AskUbuntu question shows other ways to turn off touch. Unfortunately, I do not know of a way to turn off touch only for a specific application, or only for Qt applications.



The reason the problem did not happen with Xephyr (as described below) is because Xephyr starts without support for touch events.




(I'm keeping this information around as it may help people diagnose similar issues in the future, or people looking for a finer-grained solution.)



I ran into this problem while trying to run Qt 5 applications under a Gnome desktop. I found that if I run the Qt application in a Xephyr session, the issue goes away:



$ Xephyr :1 -screen 1240x800 &
$ DISPLAY=:1 path/to/executable


Xephyr is an Xserver that can act as a client of another Xserver. (I've also tried Xnest, and it works too.) By running the software in a different Xserver, it is essentially isolated from the destkop environment running on the default Xserver.



For some use-case scenarios, this may be a usable workaround. Unfortunately, the isolation means that cut-and-paste between the app running in Xephyr and the other apps would require adding some substantial glue.




I've tried lxqt-config to see if I could change some Qt settings to fix the problem but did not find a setting that fixed the issue.



I also tried starting the app with -style=gtk but that only changes the visual style without changing the behavior.






share|improve this answer






















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    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',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417160%2fmouse-clicks-do-not-work-correctly-in-qt-applications%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    Finally, a general solution!



    The problem is caused by Qt's support for touch screens. What I've done is use xinput to disable the touch screen:



    $ xinput --list
    ⎡ Virtual core pointer id=2 [master pointer (3)]
    ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
    ⎜ ↳ DLL06E5:01 06CB:7A13 Touchpad id=14 [slave pointer (2)]
    ⎜ ↳ ELAN Touchscreen id=13 [slave pointer (2)]
    ⎣ Virtual core keyboard id=3 [master keyboard (2)]
    [... bunch of keyboard stuff]


    The "ELAN Touchscreen" input is the one we care about. It's id is 13. So:



    $ xinput --disable 13


    With the touch screen input turned off, the problem no longer happens. I don't have to restart the Qt applications that are already running. Touch can be reenabled with:



    $ xinput --enable 13


    This AskUbuntu question shows other ways to turn off touch. Unfortunately, I do not know of a way to turn off touch only for a specific application, or only for Qt applications.



    The reason the problem did not happen with Xephyr (as described below) is because Xephyr starts without support for touch events.




    (I'm keeping this information around as it may help people diagnose similar issues in the future, or people looking for a finer-grained solution.)



    I ran into this problem while trying to run Qt 5 applications under a Gnome desktop. I found that if I run the Qt application in a Xephyr session, the issue goes away:



    $ Xephyr :1 -screen 1240x800 &
    $ DISPLAY=:1 path/to/executable


    Xephyr is an Xserver that can act as a client of another Xserver. (I've also tried Xnest, and it works too.) By running the software in a different Xserver, it is essentially isolated from the destkop environment running on the default Xserver.



    For some use-case scenarios, this may be a usable workaround. Unfortunately, the isolation means that cut-and-paste between the app running in Xephyr and the other apps would require adding some substantial glue.




    I've tried lxqt-config to see if I could change some Qt settings to fix the problem but did not find a setting that fixed the issue.



    I also tried starting the app with -style=gtk but that only changes the visual style without changing the behavior.






    share|improve this answer


























      up vote
      0
      down vote













      Finally, a general solution!



      The problem is caused by Qt's support for touch screens. What I've done is use xinput to disable the touch screen:



      $ xinput --list
      ⎡ Virtual core pointer id=2 [master pointer (3)]
      ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
      ⎜ ↳ DLL06E5:01 06CB:7A13 Touchpad id=14 [slave pointer (2)]
      ⎜ ↳ ELAN Touchscreen id=13 [slave pointer (2)]
      ⎣ Virtual core keyboard id=3 [master keyboard (2)]
      [... bunch of keyboard stuff]


      The "ELAN Touchscreen" input is the one we care about. It's id is 13. So:



      $ xinput --disable 13


      With the touch screen input turned off, the problem no longer happens. I don't have to restart the Qt applications that are already running. Touch can be reenabled with:



      $ xinput --enable 13


      This AskUbuntu question shows other ways to turn off touch. Unfortunately, I do not know of a way to turn off touch only for a specific application, or only for Qt applications.



      The reason the problem did not happen with Xephyr (as described below) is because Xephyr starts without support for touch events.




      (I'm keeping this information around as it may help people diagnose similar issues in the future, or people looking for a finer-grained solution.)



      I ran into this problem while trying to run Qt 5 applications under a Gnome desktop. I found that if I run the Qt application in a Xephyr session, the issue goes away:



      $ Xephyr :1 -screen 1240x800 &
      $ DISPLAY=:1 path/to/executable


      Xephyr is an Xserver that can act as a client of another Xserver. (I've also tried Xnest, and it works too.) By running the software in a different Xserver, it is essentially isolated from the destkop environment running on the default Xserver.



      For some use-case scenarios, this may be a usable workaround. Unfortunately, the isolation means that cut-and-paste between the app running in Xephyr and the other apps would require adding some substantial glue.




      I've tried lxqt-config to see if I could change some Qt settings to fix the problem but did not find a setting that fixed the issue.



      I also tried starting the app with -style=gtk but that only changes the visual style without changing the behavior.






      share|improve this answer
























        up vote
        0
        down vote










        up vote
        0
        down vote









        Finally, a general solution!



        The problem is caused by Qt's support for touch screens. What I've done is use xinput to disable the touch screen:



        $ xinput --list
        ⎡ Virtual core pointer id=2 [master pointer (3)]
        ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
        ⎜ ↳ DLL06E5:01 06CB:7A13 Touchpad id=14 [slave pointer (2)]
        ⎜ ↳ ELAN Touchscreen id=13 [slave pointer (2)]
        ⎣ Virtual core keyboard id=3 [master keyboard (2)]
        [... bunch of keyboard stuff]


        The "ELAN Touchscreen" input is the one we care about. It's id is 13. So:



        $ xinput --disable 13


        With the touch screen input turned off, the problem no longer happens. I don't have to restart the Qt applications that are already running. Touch can be reenabled with:



        $ xinput --enable 13


        This AskUbuntu question shows other ways to turn off touch. Unfortunately, I do not know of a way to turn off touch only for a specific application, or only for Qt applications.



        The reason the problem did not happen with Xephyr (as described below) is because Xephyr starts without support for touch events.




        (I'm keeping this information around as it may help people diagnose similar issues in the future, or people looking for a finer-grained solution.)



        I ran into this problem while trying to run Qt 5 applications under a Gnome desktop. I found that if I run the Qt application in a Xephyr session, the issue goes away:



        $ Xephyr :1 -screen 1240x800 &
        $ DISPLAY=:1 path/to/executable


        Xephyr is an Xserver that can act as a client of another Xserver. (I've also tried Xnest, and it works too.) By running the software in a different Xserver, it is essentially isolated from the destkop environment running on the default Xserver.



        For some use-case scenarios, this may be a usable workaround. Unfortunately, the isolation means that cut-and-paste between the app running in Xephyr and the other apps would require adding some substantial glue.




        I've tried lxqt-config to see if I could change some Qt settings to fix the problem but did not find a setting that fixed the issue.



        I also tried starting the app with -style=gtk but that only changes the visual style without changing the behavior.






        share|improve this answer














        Finally, a general solution!



        The problem is caused by Qt's support for touch screens. What I've done is use xinput to disable the touch screen:



        $ xinput --list
        ⎡ Virtual core pointer id=2 [master pointer (3)]
        ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
        ⎜ ↳ DLL06E5:01 06CB:7A13 Touchpad id=14 [slave pointer (2)]
        ⎜ ↳ ELAN Touchscreen id=13 [slave pointer (2)]
        ⎣ Virtual core keyboard id=3 [master keyboard (2)]
        [... bunch of keyboard stuff]


        The "ELAN Touchscreen" input is the one we care about. It's id is 13. So:



        $ xinput --disable 13


        With the touch screen input turned off, the problem no longer happens. I don't have to restart the Qt applications that are already running. Touch can be reenabled with:



        $ xinput --enable 13


        This AskUbuntu question shows other ways to turn off touch. Unfortunately, I do not know of a way to turn off touch only for a specific application, or only for Qt applications.



        The reason the problem did not happen with Xephyr (as described below) is because Xephyr starts without support for touch events.




        (I'm keeping this information around as it may help people diagnose similar issues in the future, or people looking for a finer-grained solution.)



        I ran into this problem while trying to run Qt 5 applications under a Gnome desktop. I found that if I run the Qt application in a Xephyr session, the issue goes away:



        $ Xephyr :1 -screen 1240x800 &
        $ DISPLAY=:1 path/to/executable


        Xephyr is an Xserver that can act as a client of another Xserver. (I've also tried Xnest, and it works too.) By running the software in a different Xserver, it is essentially isolated from the destkop environment running on the default Xserver.



        For some use-case scenarios, this may be a usable workaround. Unfortunately, the isolation means that cut-and-paste between the app running in Xephyr and the other apps would require adding some substantial glue.




        I've tried lxqt-config to see if I could change some Qt settings to fix the problem but did not find a setting that fixed the issue.



        I also tried starting the app with -style=gtk but that only changes the visual style without changing the behavior.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Aug 9 at 11:27

























        answered Aug 7 at 22:12









        Louis

        1296




        1296






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f417160%2fmouse-clicks-do-not-work-correctly-in-qt-applications%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay