summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/xcb/qxcbconnection.h
Commit message (Collapse)AuthorAgeFilesLines
* xcb: qxcbdrag.cpp cleanupsGatis Paeglis2018-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | - moved finding of XdndAware target logic in its own function to reduce size of QXcbDrag::move(). - switched to use categorized logging with more consistent logging messages - added more comments to avoid constatly looking at the specification for the meanings of Xdnd* actions and who sends/receives the action. - removed dead code (findXdndAwareParent), which should have been removed in 269fdbdd2bedda5f5eacb751224d3a3fc3eed5bc when reimplementing this logic in XCB. - removed needless reseting of state variables in various places as this is handled in QXcbDrag::init() on DnD start. - renamed variable in QXcbDrag::dndEnable(): xdnd_widget -> window - and other minor cleanups Change-Id: Ib667f80ceb4c07b7409a90c041044c98665877f3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-06-071-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/corelib/kernel/qeventdispatcher_cf.mm src/gui/kernel/qguiapplication_p.h src/gui/kernel/qwindowsysteminterface.cpp src/gui/kernel/qwindowsysteminterface.h src/plugins/platforms/cocoa/qcocoawindow.mm src/plugins/platforms/cocoa/qnswindowdelegate.mm src/plugins/platforms/ios/qioseventdispatcher.mm src/plugins/platforms/windows/qwindowsdrag.h src/plugins/platforms/windows/qwindowsinternalmimedata.h src/plugins/platforms/windows/qwindowsmime.cpp src/plugins/platforms/winrt/qwinrtscreen.cpp Change-Id: Ic817f265c2386e83839d2bb9ef7419cb29705246
| * Make sure we can build with -no-feature-draganddropJoerg Bornemann2018-05-291-2/+2
| | | | | | | | | | | | | | | | | | We move QInternalMimeData to a separate file, because this class is used, even if draganddrop is disabled. From now on, include qinternalmimedata_p.h instead of qdnd_p.h for QInternalMimeData. Change-Id: I594e08e2e90d574dc445119091686b4b69e4731b Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | qpa: improve API to support DnDs from other processesGatis Paeglis2018-05-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of using a hack of directly accessing QGuiApplication members. The current QPA API was bad for two reasons: 1) It expects platform plugin authors to know about internals of Qt Gui, particularly that QGuiApplication uses QGuiApplication::{mouseButtons,keyboardModifiers} to construct QDragMoveEvent and QDropEvent events. Which results in the second reason why this is bad. 2) Platform plugins should not directly access member variables of QGuiApplication, just to make sure that QDragMoveEvent and QDropEvent events contain correct state. Platform plugins should instead use QWindowSystemInterface to communicate with Qt Gui (which is also the solution here). The solution is to extend QWindowSystemInterface::handle{Drag,Drop} to require mouse/keyboard state. We already do this for some of the other methods, so it is nothing extraordinary. This type of interface is also _required_ to support drag-n-drops from other processes. We can't use QGuiApplication::{mouseButtons,keyboardModifiers} when the drag originates from another process, instead we need to query mouse/keyboard state from the system. This patch fixes drag-n-drops from others processes on XCB platform plugin. Task-number: QTBUG-57168 Change-Id: I3f8b0d2f76e9a32ae157622fef801829d629921d Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-04-151-1/+9
|\| | | | | | | Change-Id: I8c353b4c53e90434453c76691eac39a894d23b49
| * xcb: prevent crash with pixmap cursors on XRender-less X serversGatis Paeglis2018-04-141-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were using xcb_render_* APIs without checking if the server even supports this extension. Attempting to use an extension which is not present will always result in a crash. This patch adds the required guards and refactors how we detect presence of XRender extension. Also instead of falling back to some odd-looking bitmapped version just leave the current cursor unchanged. That is how we did it in Qt4 AFAICT. Task-number: QTBUG-66935 Change-Id: I4f27f1d65a77563ec34f3e0e94492c9236d7f9a6 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | xcb: minor cleanups around QT_CONFIG(xcb_xlib)Gatis Paeglis2018-04-091-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove unused createVisualInfoForDefaultVisualId() function. This amends dff3c0f14f3c3a7288c456028d5bec23bee5406a. - Inline QXcbConnection::xlib_display(). - Don't nest QT_CONFIG(xcb_native_painting) in QT_CONFIG(xcb_xlib). configure.json already checks for the dependencies, we don't need to do that again in *.h/*.cpp. Change-Id: If39912e67ce9baa31faf091bebe120bac5cf6876 Reviewed-by: Alexander Volkov <a.volkov@rusbitech.ru> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | xcb: Use XCB instead of Xlib for XInputAlexander Volkov2018-03-221-27/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Replace xinput2 feature by xcb-xinput, which doesn't depend on xcb-xlib - Remove xi2PrepareXIGenericDeviceEvent() that was used to fix incompatibilty between XCB and libXi structs - Drop XCB_USE_XINPUT21 and XCB_USE_XINPUT22 defines that were needed with libXi Although xcb-xinput was released in version 1.13 of libxcb, it was quite stable in version 1.12, and the parts that we use did not change between versions, so require system xcb-xinput 1.12. [ChangeLog][X11] The xcb plugin was ported to use libxcb-xinput instead of libXi for XInput2 support. The -xinput2 configure option was replaced by -xcb-xinput. Task-number: QTBUG-39624 Change-Id: I37475b09b2bd7057763345c3f33d8c7751a4e831 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devQt Forward Merge Bot2018-02-231-0/+1
|\| | | | | | | Change-Id: I01dfc41e18333ac55954296cef8f01475adab27e
| * xcb: remove fragile and unnecessary missing-latin-keymap workaroundGatis Paeglis2018-02-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... which was trying to fix a rarely occurring situation where system settings from a desktop environment does not set any latin keymap on X. This is a DE bug and it has a simple workaround (details in the patch). Ubuntu has fixed this issue sometime between 12.10 -> 14.04. Gnome 3 always appends 'us' layout, even if you have only e.g. 'gr' listed in keyboard layouts (can be checked via setxkbmap -query). In KDE, the global system shorcuts seem to stop working as soon as latin keymap is not the first in the list, which means that KDE users won't be affected as they will likely always have a latin keymap present in the list. This patch removes parts of 2b666d9576210aa98700e219dba6b1bd4f93d793, the parts that in the commit message I was referring to by this quote: "lookupLatinKeysym() also handles the cases that did not work in Qt4 with XLookupString". Since finding a latin key is not working by XLookupString() in this rare case, then it would not work pretty much across the whole desktop. And users would be more interested at finding a solution that works across the desktop. We should not workaround this issue. Desktops that are doing it wrong should learn about this and not repeat the same mistakes on Wayland systems, where XKB keymap is assembled by compositor and passed to clients. Clients should work with the provided keymap as is. The missing-latin-keymap workaround is considered fragile for several reasons - it might not work with legacy or enterprise X server key codes and it relies on global _XKB_RULES_NAMES (there might be several connected keyboards). And theoretical limitation: client might be running in a restricted environment where we don't have access to keymaps on the file system. Change-Id: Ib445b2ea46174248cfa0e5da0eb642cd2a5cf2f6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-02-161-0/+6
|\| | | | | | | | | | | | | Conflicts: src/corelib/tools/tools.pri Change-Id: I705630f9cecbf0ce51a22fc6116b8c49611259e9
| * xcb: Fix access to shm for X server running from another userAlexander Volkov2018-02-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use ShmCreateSegment call, that was added in MIT-SHM 1.2, to create shared memory segments on the server side. It returns a POSIX shared memory object that is used to mmap memory. It's in effect a file descriptor that is passed through the X server socket and thus avoids permission checks. On the other hand this scheme is more secure, because the file descriptor, and thus the shared memory, are accessible only by the X server and the application. Task-number: QTBUG-46017 Change-Id: I202eead9d01aee2ab5b65f4f74f4c13da7cb2239 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
| * xcb: Enhance SHM management codeAlexander Volkov2018-02-151-0/+4
| | | | | | | | | | | | | | | | | | | | - extract the creation of a shared memory segment into a separate function - do extra checks for errors - check that MIT-SHM extension is present once in QXcbConnection Change-Id: I956bdf76b879ec5c95a7ed219a59ae722dc5afba Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | Merge remote-tracking branch 'origin/5.11' into devLiang Qi2018-02-111-4/+4
|\| | | | | | | Change-Id: Ia443f6eb1c854c99c68127a376b78c1986675a9d
| * QPlatformWindow: add startSystemMove()Alexander Volkov2018-02-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It can be used by custom widgets or for example by the Breeze style from KDE, which allows to drag windows by some widgets. It's important on X11 because _NET_WM_MOVERESIZE requests induced by touch sequences require support from Qt. Task-number: QTBUG-58044 Change-Id: I31c37534555a9050cf361cad85bdef13c2808572 Reviewed-by: Johan Helsing <johan.helsing@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | xcb: Drop _QT_SETTINGS_TIMESTAMP_ atomAlexander Volkov2018-02-081-3/+0
|/ | | | | | | | It was used in Qt 4 to make applications reload Trolltech.conf, which is not supported by Qt 5. Change-Id: Ic75c117f22a23a8f26b3f19ce57322878613f5b0 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* xcb: fix and optimize QXcbConnection::xi2SetMouseGrabEnabledGatis Paeglis2018-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | What was broken: - m_xiGrab on successful ungrab (XIUngrabDevice) was never set to 'false'. Which means that we would unnecessarily call XIAllowTouchEvents, even when we are not grabbing (this did not have any apparent side effects). What was non optimal: - Redundant XIQueryDevice calls. XIQueryDevice with XIAllMasterDevices flag already returns all required devices. Calling XIQueryDevice for every id again does not make sense. - Querying for master pointer info on every grab is unnecessary. Simply cache ids of master devices whenever hierarchy changes. What remains to be investigated some time later (or never): The original and the re-factored code grabs all master pointer devices. Not sure if that is the expected behavior on MPX (Multi-pointer X) systems. Could there be two context menus, each dismissed separately? MPX concept was introduced in XI2.0, but testing shows that this setup is not very well supported even on modern desktop environments. Tested on Ubuntu 16.04, where multiple pointers is enough for crashing a terminal. Also AFAIK there isn't any bug reports about broken MPX support in Qt. Change-Id: I53f99c6efd44abc43a0985e15cff8aae7ebba8f1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* xcb: use a more efficient unique_ptr instantiationMarc Mutz2017-12-061-6/+8
| | | | | | | | | | Wrap std::free() in a function object, to avoid having to carry around state (the function pointer) inside unique_ptr objects. This shrinks unique_ptrs back to sizeof(void*). Change-Id: I32a711192c5485dc04e3b36a1ddabf02d1e9d4f9 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* qpa: enhance mouse event with type and button dataGatis Paeglis2017-10-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and deprecate QWSI APIs that accepts mouse event without mouse button/ type data. In the early days of Qt5 it was decided to centralize mouse button/type handling in QGuiApplication (because of limitation of some now unknown platform). This has proven to be problematic as mouse handling details differ across platforms (e.g on X11 we do not receive mouse release event when closing popup windows or ordinary windows that are closed from the mouse press event). Instead of hacking around platform specific behaviors in Qt Gui, we should move this task back to platform plugins (similar to how this was done in Qt4 with native APIs sending mouse details directly to QApplication). There are even cases where it simply is not possible to deduce (from QGuiApplication) which button caused the event (e.g. when more than one button is involved and some event goes missing). Besisdes, throwing away information which is already available at QPA level (for free) and trying to deduce it again at Qt Gui level seems impractical, fagile (as probably noticed by people fixing all the unexpected issues) and adds unnecessary complexity. Note: Removing the deprecated QWSI APIs from offscreen plugin depends on fixing autotests that rely on QOffscreenCursor::setPos() logic. For the convenience of testing use QT_QPA_DISABLE_ENHANCED_MOUSE to restore to the old code path where QGuiApplication does the mouse state deducing. Other platforms have similar issues. I do not have all supported platform available on my desk, so other platform maintainers will need to take care of porting those platforms to the new APIs. And mainly, I don't want to deal with all the hacks that other platforms have added to workaround this broken mouse logic. In Qt6 we need to remove deprecated code path from QGuiApplication. This patch: - Extends QWindowSystemInterfacePrivate::MouseEvent ctor with QEvent::Type and Qt::MouseButton. We use this extra data when processing mouse events in QGuiApplication. This actually is similar to KeyEvent, where we do pass the type (press or release) to QtGui. - Refactors QGuiApplicationPrivate::processMouseEvent and qtestlib to use the new APIs. Task-number: QTBUG-59277 Task-number: QTBUG-62329 Task-number: QTBUG-63467 Change-Id: If94fd46a7cccfea8264dcb1368804c73334558b8 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Handle endian mismatch between X11 client and serverAllan Sandfeld Jensen2017-10-021-0/+9
| | | | | | | | | | | | If the server and client has different endian we need to swizzle the image pixels, we can do that by swizzling the masks and try to match the new configuration. This is a rather rare setup so we don't try to match every combination. This patch fixes the colors when running Qt in a bigendian QEMU chroot. Change-Id: Ie83f9607563cba137b2e1a63e996a05d43ff603e Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-08-311-0/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/examples.pro qmake/library/qmakebuiltins.cpp src/corelib/global/qglobal.cpp Re-apply b525ec2 to qrandom.cpp(code movement in 030782e) src/corelib/global/qnamespace.qdoc src/corelib/global/qrandom.cpp src/gui/kernel/qwindow.cpp Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08) src/network/ssl/qsslkey_openssl.cpp src/plugins/platforms/android/androidjniinput.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/widgets/widgets/qmenu.cpp tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
| * XCB: Don't core-dump if we can't connect to the X displayNameThiago Macieira2017-08-161-0/+1
| | | | | | | | | | | | | | Exit with error, but don't crash. Change-Id: Ie05c6480d8a44fda817ffffd14d9dfd8c951beef Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* | xcb: add support for peeking into the XCB event queueGatis Paeglis2017-08-111-0/+15
| | | | | | | | | | | | | | | | This will be used by the Qt X11 Extras module. Task-number: QTBUG-50358 Change-Id: Ie095cd211c393ea6d78660b4d53cac28b435a3b2 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | xcb: re-factor QXcbConnection::printXcbEventGatis Paeglis2017-08-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - To use categorized logging. - Print also non-core event types. - Added QLoggingCategory as one of the parameters because I will need it in a subsequent patch. - A call to this function in QXcbConnection::handleXcbEvent I left disabled from builds by default as the "handled" variable is broken. Change-Id: I15cd71c40b5772a4352a69cdc24a0ae026626060 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* | xcb: use XInput2 for mouse starting from 2.0 not 2.2Gatis Paeglis2017-08-091-18/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 53d289ec4c0f512a3475da4bbf1f940cd6838ac fixed the issue of not getting touch events when grabbing via the plain xcb functions. And due to wanting to support a setup where mouse events are delivered via core events it was chosen to use mouse via XI2 only when really necessary. Thus starting only from 2.2, the version from which the mouse+touch grabbing becomes the issue (XI2 introduced touch support from 2.2). The same patch states that using QT_XCB_NO_XI2_MOUSE restores to the old behavior (grabbing via core) with broken touch grabbing. Broken only with 2.2+, not 2.0 and 2.1 since those versions of protocol do not know about touch. All of this implies the following: 1) The user code that already depends on QT_XCB_NO_XI2_MOUSE, won't see any behavioural difference if we will use XInput starting from 2.0 for mouse. Mouse grabbing will continue to be done via core (xcb_grab_pointer) as mentioned above and thus touch grabbing will continue to be broken with 2.2+. 2) The code that has never cared how we get the native events (core vs xinput2), won't see any behavioural difference. In this case grabbing will always be done via XI2 (XIGrabDevice) grab when XI2.0+ is available. Since there is no difference in the outcome, we migth as well use XI2 for mouse from 2.0, not 2.2. Extension events are always better choice than core. Besides the broken touch grabbing issue with QT_XCB_NO_XI2_MOUSE, there are other issues with that code path, for details see internal documentation of xi2SelectDeviceEventsCompatibility(), where the conclusion is: *** If your code relies on QT_XCB_NO_XI2_MOUSE, then your code needs fixing. *** This patch also cleans up how we select XInput2 events, by separating the QT_XCB_NO_XI2_MOUSE code path. This has two benefits - improved code readability and will make the deprecation of QT_XCB_NO_XI2_MOUSE easier. The patch removes some sparse comments as the behavior is now documented in one place, see xi2SelectDeviceEventsCompatibility(). [ChangeLog][Platform Specific Changes][Linux] The QT_XCB_NO_XI2_MOUSE environment variable is deprecated and will be removed in Qt 6. If your application relies on behavior set by QT_XCB_NO_XI2_MOUSE, it should be updated accordingly. [ChangeLog][Platform Specific Changes][Linux] Pointer event delivery on X11 is now done starting from XInput version 2.0 (when available) instead of 2.2. XInput support can be disabled by setting QT_XCB_NO_XI2=1 environment variable. Note that using QT_XCB_NO_XI2 would also disable tablet and touch support. Change-Id: I661b36d6710b9f6ec71fecc8287ba479432bff4c Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: tidy-up has_<extension> variable handlingGatis Paeglis2017-08-081-2/+3
| | | | | | | | | | Change-Id: I666c9d415e366d6b06b05e70e01456c47ac35b4a Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devOswald Buddenhagen2017-08-021-0/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/xcb/qxcbconnection.h src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp src/plugins/styles/mac/qmacstyle_mac.mm src/widgets/widgets/qdockarealayout.cpp src/widgets/widgets/qmainwindow.cpp src/widgets/widgets/qmainwindowlayout.cpp src/widgets/widgets/qmainwindowlayout_p.h tests/auto/corelib/tools/qlocale/tst_qlocale.cpp tests/auto/other/macnativeevents/BLACKLIST tests/auto/widgets/widgets/qmenu/BLACKLIST Change-Id: Ic8e724b80a65e7b1af25511b0e674d209265e567
| * xcb: fix freeze when (un)plugging input devicesGatis Paeglis2017-07-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .. in an application that has many native windows. We don't need to select XI_HierarchyChangedMask and XI_DeviceChangedMask for every window. It is enough to register one window for these events to update state of our X11 client (application). Furthermore, XIAllDevices and XIAllMasterDevices always apply, even if the device has been added after the client has selected for events. So there is no need to call XISelectEvents on XIAllDevices/XIAllMasterDevices again, if we are not updating event masks. With this patch and the test application from QTBUG-57013, removing/attaching a device takes few hundred milliseconds instead of 23-24 seconds. Task-number: QTBUG-57013 Change-Id: Ieb0b5ee25feef2922f901165825cb4a1289fc852 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: use default member initialization in structGatis Paeglis2017-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | ... for better localization. This is not possible in C, but in C++ a struct has the same features as a class. Thus, use default member initialization feature (available since C++11). Change-Id: I91522c3a4fe4270c37bb6e85fddeb5970a847352 Reviewed-by: Alexander Volkov <a.volkov@rusbitech.ru> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* | xcb: fix build failure when XCB_USE_XINPUT22 is not definedGatis Paeglis2017-07-181-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and group XI22 methods together under one ifdef clause. The error message was: qxcbconnection_xi2.cpp:1025:42: error: no ‘bool QXcbConnection::isTouchScreen(int)’ member function declared in class ‘QXcbConnection’ bool QXcbConnection::isTouchScreen(int id) XInput 2.2 was released many years ago, this build failure could in practice happen only on some really old platform. Change-Id: I3c1741cbdffe15c0f5149c6d76592a743d1d8a91 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: allow to change XInput device properties at runtimeGatis Paeglis2017-07-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xinput list-props <device-id> xinput set-prop <device-id> <atom-id> n n n Example: xinput list-props 9 .. Evdev Scrolling Distance (274): 1, 1, 1 .. xinput set-prop 9 274 8 1 1 [ChangeLog][Platform Specific Changes][Linux] XInput device property changes are now detected at runtime (no application restart required). Change-Id: I4d2455eef70857bc2e35c27011a3808a78fa960f Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: fix spelling error in xi2HandleHierarchyEvent()Gatis Paeglis2017-07-171-1/+1
| | | | | | | | | | Change-Id: I17bdd856bb23734f683b066759ab44493a8d60b7 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: don't allow isAtLeastXI2{1,2} in builds without Xinput2Gatis Paeglis2017-07-141-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .. thus making it purely into a _runtime_ check of XInput 2 version. If Qt was build with -no-xinput2, it does not make sense to compile in code that always returns "false". Simply exclude code that is not relevant for -no-xinput2 builds with XCB_USE_XINPUT2 ifdefs. In addition, this improves readability of the code. Now, trying to use ::isAtLeastXI21() in a -no-xinput2 build will result in the following build error: error: ‘class QXcbConnection’ has no member named ‘isAtLeastXI21’ Change-Id: If242510d43d71829b327edc1f76322f3a0db0e08 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: fix logic in QXcbConnection::initializeXInput2()Gatis Paeglis2017-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Things that were broken: - The return values of XIQueryVersion interpreted wrongly. BadRequest means no XI2 support on the server. Nesting more XIQueryVersion calls to check for lower minor version of XI2 in this case does not make sense. On Success, server's supported X Input version is returned. Server's supported version can be lower than the version we have announced to support. In this case Qt client will be limited by X server's supported version (which is ok, as we do check the available version at runtime via QXcbConnection::isAtLeastXI2*). - The code was _always_ announcing to X server that we support XI 2.2, by ignoring what actually is supported in the specific build (see XCB_USE_XINPUT ifdefs). - qCDebug messages and logging categories were wrong too. Change-Id: Ia84457f125474aa851b7a91ed19fc5b904ac359e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: cleanup updating of scrolling device valuatorsGatis Paeglis2017-07-131-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This includes: - Better sharing of common code. - Less argument passing. - Improved code readability: It is somewhat confusing to read when QXcbWindow::handleEnterNotifyEvent calls connection()->handleEnterEvent(). - Better organizing of ifdefs. Change-Id: I4405390cada13b51db78f9fd30e26bb1793395ff Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | xcb: don't keep objects for disconnected touch devicesGatis Paeglis2017-07-131-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... as XI2 reuses device ids and we might end up with some bogus objects in m_touchDevices (the same touch device after reconnecting might have a new device id). With this patch, m_touchDevices is handled similarly to tablets and scolling devices. This patch also removes unnecessary calls to X (XIQueryDevice). We already have device information available for all devices when populating m_touchDevices list, so calling XIQueryDevice again for every device id (which we haven't already concluded to be a tablet device) is a redundant round trip to X. For consistency with other device types, extend touch device data structure to store the necessary device details, instead of holding pointers to XIDeviceInfo. And allocate touch device objects on stack instead of heap, also for the consistency reasons (this way we won't need to special case m_touchDevices when running some management task on _all_ devices, e.g. removing a device with id=n when it was disconnected). Change-Id: I9f6edfaf24da911dd21ec45cd48dfdd6d0dcdf8b Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-07-041-12/+12
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qprocess_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbwindow.cpp src/widgets/util/util.pri tests/auto/corelib/thread/qthread/qthread.pro tests/auto/corelib/thread/qthread/tst_qthread.cpp Change-Id: I5c45ab54d46d3c75a5c6c116777ebf5bc47a871b
| * xcb: Replace XCB_USE_XINPUT define by QT_CONFIG macroAlexander Volkov2017-06-291-6/+6
| | | | | | | | | | | | | | | | .. and remove it from qxcbconnection_xi2.cpp as this file is build _only_ when xinput2 is available. Change-Id: I66d6a299c120fc034f8519cd188e1b845d5bd1bc Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
| * Convert features.tabletevent to QT_CONFIGStephan Binner2017-06-281-4/+4
| | | | | | | | | | Change-Id: Ibd7ed7f269a64afddadee70979b20f1c58398378 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
| * xcb: Use QT_CONFIG macro to check for xcb-xlibAlexander Volkov2017-06-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and remove the XCB_USE_XLIB define. This patch also removes the unnecessary checks for xcb-xlib in: - qxcbglxintegration.cpp as this files is build _only_ when xcb-xlib is present. From gl_integrations.pro: qtConfig(xcb-xlib):qtConfig(opengl):!qtConfig(opengles2) { SUBDIRS += xcb_glx } This also would have been the right place where to define XCB_USE_XLIB, instead of unconditional line in xcb_glx.pro: DEFINES += XCB_USE_GLX XCB_USE_XLIB - qxcbnativeinterface.cpp as this cpp file does not use any Xlib APIs directly, there is no need to include Xlib.h. Change-Id: I531b5f1e79606fcfd1c63810cf51b7d5e9dc58a7 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | xcb: remove DISPLAY_FROM_XCB macroGatis Paeglis2017-06-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... as it does not add much value and is not widely used. and cleanup code: - where we repeatedly (for no good reason) call DISPLAY_FROM_XCB, instead of storing display as a (member) variable. - inconsistency where we (in the same function) alternatingly use DISPLAY_FROM_XCB and variable holding pointer to Display (when both refer to the same display). In other places this patch replaces macros with code they would translate to (or with minor adjustments to keep sensible line length). Change-Id: Ieb2a3e055892dcf31f132891f83ed4a665e3fa6e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | XCB platform plugin: add missing includeMarcel Krems2017-06-021-0/+1
| | | | | | | | | | | | | | | | | | 89870a35bde2f67f9c371ba145e90b86d3e2dd1b introduced an usage of std::free without including cstdlib. Change-Id: I9b7ae1caf90bf22aae99cc0407347350c83181a2 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* | xcb: remove CREATE_VISUALINFO_FROM_DEFAULT_VISUALID macroGatis Paeglis2017-06-021-1/+0
| | | | | | | | | | | | | | | | | | It was added by d605883 and become unused after 5f39a0e. The patch that added this macro used it only in one place, which rarely is a good reason for introducing a macro. Change-Id: If7065956fc79daf9b2d535527beaa42dbe0243a2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | xcb: remove duplicate QXcbConnection::supportsThreadedRendering()Gatis Paeglis2017-06-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | It is unused and it duplicates QXcbConnection::threadedEventHandling(): bool supportsThreadedRendering() const { return m_reader->isRunning(); } bool threadedEventHandling() const { return m_reader->isRunning(); } "threadedEventHandling" is more appropriate name by looking at the body of the function. Change-Id: I99733e9c1ddb3ff75444d61d28eca54dcd6b0418 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | xcb: rename QXcbConnection::{setButton,buttons,m_buttons}Gatis Paeglis2017-05-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | ... to {setButtonState,buttonState,m_buttonState}. This is more consistent with the naming from XCB events: xcb_button_press_event_t->state xcb_button_release_event_t->state xcb_motion_notify_event_t->state Change-Id: I51ebb858defbdfee4a2009922178f0e58658e6b6 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | xcb: Add experimental legacy support for native X11 paintingLouai Al-Khanji2017-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | This commit revives the old native QPixmap and QPaintEngine implementations that were present in Qt4. The backing store supports regular raster windows in this commit. Support for render-to-texture widgets and OpenGL compositing will be added in a follow-up commit. Change-Id: I80a9c4f0c42a6f68f571dfee930d95000d5dd950 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-04-071-1/+1
|\| | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/linux-icc/qmake.conf mkspecs/macx-icc/qmake.conf mkspecs/win32-icc/qmake.conf src/gui/painting/qgrayraster.c Change-Id: Ib08c45ea3215be05f986ecb3e1f4b37d209aa775
| * Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-04-061-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp src/platformsupport/fontdatabases/freetype/qfreetypefontdatabase.cpp src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp src/widgets/widgets/qtabbar.cpp Change-Id: Iaa9daee5f7a6490d56257a3824730a35751ceb05
| | * xcb: prevent dangling pointer when window focus changesGatis Paeglis2017-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the current implementation, the QXcbConnection::m_focusWindow was holding a dangling pointer during the focus transition from a dying modal window to other modal window. 1) QXcbConnection::m_focusWindow holds a pointer to A; 2) A is closed; 3) relayFocusToModalWindow B; => m_focusWindow now points to a dead window. 4) We get a reply back from WM in a respone to relayFocusToModalWindow (_NET_ACTIVE_WINDOW) => m_focusWindow now points to a valid window. The fix is to update m_focusWindow to nullptr, when the current focus window was destroyed and the new focus window has not been set yet by WM. This patch actually solves a more general case - whenever we get a focus-out event, we should set m_focusWindow to nullptr. It is ok for none of the windows to be in-focus while focus transition is happening. The focusInPeeker will make sure to "optimize out" (when possible) this no-window-in-focus state, and GUI won't be bothered by this extra event. This is how things were working before relayFocusToModalWindow was introduced. Having a focus-relay mechanism in-between is ok, but it should not have changed the original behavior. Task-number: QTBUG-48391 Task-number: QTBUG-55197 Change-Id: I6fdda9de73f999dad84000059ce4b89c0d1a964c Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-03-201-0/+13
|\| | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qfilesystemengine_win.cpp src/gui/text/qdistancefield.cpp src/plugins/platforms/xcb/qxcbconnection.h Change-Id: I1be4a6f440ccb7599991159e3cb9de60990e4b1e
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 14:51:25 +0000