Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-40207

Qt polls for hardware on every start of a qt application

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: P3: Somewhat important P3: Somewhat important
    • 5.5.0
    • 5.2.1, 5.3.1
    • QPA: X11/XCB
    • None
    • Archlinux/Gnome, Archlinux/KDE, Archliux/XFCE, hence in general. Current Ubuntu14.04 live.
    • a73cead0e0ffe674d0c873a726d2535ba60d9614

      Starting an app built with qt polls for harware changes exactly as xrandr does. This results in several freezes starting kde as well as starting a qt app. I guess the latter is implying the first one.

      I found this out due to another intel bug which is not a qt problem. (Polling hardware with DisplayPort connected freezes X for about a second) Anyway this is not a proper solution, since hardware polling is slow in general and should be avoided.

      This affects 5.3.1 on my ArchLiux system as well as qt 5 on an Ubuntu 14.04 Live System (I dont know the version exactly). Gtk and pure Xlib/xcb and command line applications do not show this behavior. Just to exclude genereal I/O problems out.

      In more detail the debugger freezes X exactly at "QApplication a(argc, argv);"

      Are you using XRRGetScreenResources() instead of XRRGetScreenResourcesCurrent()? This call is polling for changes. See http://www.x.org/releases/X11R7.6/doc/randrproto/randrproto.txt paragraph "RRGetScreenResources" and "RRGetScreenResourcesCurrent".

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            srutledg Shawn Rutledge
            manuelschneid3r Manuel Schneider
            Votes:
            3 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved:

                There are no open Gerrit changes