yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/src/utils/xcbutils.cpp

651 lines
26 KiB
C++
Raw Normal View History

Prettify license headers
2020-08-02 22:22:19 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2006 Lubos Lunak <l.lunak@kde.org>
SPDX-FileCopyrightText: 2012 Martin Gräßlin <mgraesslin@kde.org>
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-License-Identifier: GPL-2.0-or-later
*/
Move xcbutils to utils directory
2022-01-13 13:54:03 +00:00
#include "utils/xcbutils.h"
Move utils.h file to utils directory
2022-01-18 08:35:52 +00:00
#include "utils/common.h"
And we got rid of KDebug Usages of kBacktrace got dropped.
2013-09-02 11:14:39 +00:00
// Qt
#include <QDebug>
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
// xcb
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
#include <cmath>
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
#include <xcb/composite.h>
#include <xcb/damage.h>
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
#include <xcb/glx.h>
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
#include <xcb/randr.h>
#include <xcb/render.h>
#include <xcb/shape.h>
#include <xcb/sync.h>
#include <xcb/xfixes.h>
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
// system
#include <sys/shm.h>
#include <sys/types.h>
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
namespace KWin
{
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
namespace Xcb
{
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
static const int COMPOSITE_MAX_MAJOR = 0;
static const int COMPOSITE_MAX_MINOR = 4;
static const int DAMAGE_MAX_MAJOR = 1;
static const int DAMAGE_MIN_MAJOR = 1;
static const int SYNC_MAX_MAJOR = 3;
static const int SYNC_MAX_MINOR = 0;
static const int RANDR_MAX_MAJOR = 1;
static const int RANDR_MAX_MINOR = 4;
static const int RENDER_MAX_MAJOR = 0;
static const int RENDER_MAX_MINOR = 11;
static const int XFIXES_MAX_MAJOR = 5;
static const int XFIXES_MAX_MINOR = 0;
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
QVector<QByteArray> shapeOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/xextproto/shape.html
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/shape.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("Rectangles"),
QByteArrayLiteral("Mask"),
QByteArrayLiteral("Combine"),
QByteArrayLiteral("Offset"),
QByteArrayLiteral("Extents"),
QByteArrayLiteral("Input"),
QByteArrayLiteral("InputSelected"),
QByteArrayLiteral("GetRectangles")});
}
QVector<QByteArray> randrOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/randrproto/randrproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/randr.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArray(""), // doesn't exist
QByteArrayLiteral("SetScreenConfig"),
QByteArray(""), // doesn't exits
QByteArrayLiteral("SelectInput"),
QByteArrayLiteral("GetScreenInfo"),
QByteArrayLiteral("GetScreenSizeRange"),
QByteArrayLiteral("SetScreenSize"),
QByteArrayLiteral("GetScreenResources"),
QByteArrayLiteral("GetOutputInfo"),
QByteArrayLiteral("ListOutputProperties"),
QByteArrayLiteral("QueryOutputProperty"),
QByteArrayLiteral("ConfigureOutputProperty"),
QByteArrayLiteral("ChangeOutputProperty"),
QByteArrayLiteral("DeleteOutputProperty"),
QByteArrayLiteral("GetOutputproperty"),
QByteArrayLiteral("CreateMode"),
QByteArrayLiteral("DestroyMode"),
QByteArrayLiteral("AddOutputMode"),
QByteArrayLiteral("DeleteOutputMode"),
QByteArrayLiteral("GetCrtcInfo"),
QByteArrayLiteral("SetCrtcConfig"),
QByteArrayLiteral("GetCrtcGammaSize"),
QByteArrayLiteral("GetCrtcGamma"),
QByteArrayLiteral("SetCrtcGamma"),
QByteArrayLiteral("GetScreenResourcesCurrent"),
QByteArrayLiteral("SetCrtcTransform"),
QByteArrayLiteral("GetCrtcTransform"),
QByteArrayLiteral("GetPanning"),
QByteArrayLiteral("SetPanning"),
QByteArrayLiteral("SetOutputPrimary"),
QByteArrayLiteral("GetOutputPrimary"),
QByteArrayLiteral("GetProviders"),
QByteArrayLiteral("GetProviderInfo"),
QByteArrayLiteral("SetProviderOffloadSink"),
QByteArrayLiteral("SetProviderOutputSource"),
QByteArrayLiteral("ListProviderProperties"),
QByteArrayLiteral("QueryProviderProperty"),
QByteArrayLiteral("ConfigureProviderroperty"),
QByteArrayLiteral("ChangeProviderProperty"),
QByteArrayLiteral("DeleteProviderProperty"),
QByteArrayLiteral("GetProviderProperty")});
}
QVector<QByteArray> randrErrorCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/randrproto/randrproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/randr.h>
return QVector<QByteArray>({QByteArrayLiteral("BadOutput"),
QByteArrayLiteral("BadCrtc"),
QByteArrayLiteral("BadMode"),
QByteArrayLiteral("BadProvider")});
}
QVector<QByteArray> damageOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/damageproto/damageproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/damage.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("Create"),
QByteArrayLiteral("Destroy"),
QByteArrayLiteral("Subtract"),
QByteArrayLiteral("Add")});
}
QVector<QByteArray> damageErrorCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/damageproto/damageproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/damage.h>
return QVector<QByteArray>({QByteArrayLiteral("BadDamage")});
}
QVector<QByteArray> compositeOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/compositeproto/compositeproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/composite.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("RedirectWindow"),
QByteArrayLiteral("RedirectSubwindows"),
QByteArrayLiteral("UnredirectWindow"),
QByteArrayLiteral("UnredirectSubwindows"),
QByteArrayLiteral("CreateRegionFromBorderClip"),
QByteArrayLiteral("NameWindowPixmap"),
QByteArrayLiteral("GetOverlayWindow"),
QByteArrayLiteral("ReleaseOverlayWindow")});
}
QVector<QByteArray> fixesOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/fixesproto/fixesproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/xfixes.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("ChangeSaveSet"),
QByteArrayLiteral("SelectSelectionInput"),
QByteArrayLiteral("SelectCursorInput"),
QByteArrayLiteral("GetCursorImage"),
QByteArrayLiteral("CreateRegion"),
QByteArrayLiteral("CreateRegionFromBitmap"),
QByteArrayLiteral("CreateRegionFromWindow"),
QByteArrayLiteral("CreateRegionFromGc"),
QByteArrayLiteral("CreateRegionFromPicture"),
QByteArrayLiteral("DestroyRegion"),
QByteArrayLiteral("SetRegion"),
QByteArrayLiteral("CopyRegion"),
QByteArrayLiteral("UnionRegion"),
QByteArrayLiteral("IntersectRegion"),
QByteArrayLiteral("SubtractRegion"),
QByteArrayLiteral("InvertRegion"),
QByteArrayLiteral("TranslateRegion"),
QByteArrayLiteral("RegionExtents"),
QByteArrayLiteral("FetchRegion"),
QByteArrayLiteral("SetGcClipRegion"),
QByteArrayLiteral("SetWindowShapeRegion"),
QByteArrayLiteral("SetPictureClipRegion"),
QByteArrayLiteral("SetCursorName"),
QByteArrayLiteral("GetCursorName"),
QByteArrayLiteral("GetCursorImageAndName"),
QByteArrayLiteral("ChangeCursor"),
QByteArrayLiteral("ChangeCursorByName"),
QByteArrayLiteral("ExpandRegion"),
QByteArrayLiteral("HideCursor"),
QByteArrayLiteral("ShowCursor"),
QByteArrayLiteral("CreatePointerBarrier"),
QByteArrayLiteral("DeletePointerBarrier")});
}
QVector<QByteArray> fixesErrorCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/fixesproto/fixesproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/xfixes.h>
return QVector<QByteArray>({QByteArrayLiteral("BadRegion")});
}
QVector<QByteArray> renderOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/renderproto/renderproto.txt
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/render.h>
return QVector<QByteArray>({QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("QueryPictFormats"),
QByteArrayLiteral("QueryPictIndexValues"),
QByteArrayLiteral("CreatePicture"),
QByteArrayLiteral("ChangePicture"),
QByteArrayLiteral("SetPictureClipRectangles"),
QByteArrayLiteral("FreePicture"),
QByteArrayLiteral("Composite"),
QByteArrayLiteral("Trapezoids"),
QByteArrayLiteral("Triangles"),
QByteArrayLiteral("TriStrip"),
QByteArrayLiteral("TriFan"),
QByteArrayLiteral("CreateGlyphSet"),
QByteArrayLiteral("ReferenceGlyphSet"),
QByteArrayLiteral("FreeGlyphSet"),
QByteArrayLiteral("AddGlyphs"),
QByteArrayLiteral("FreeGlyphs"),
QByteArrayLiteral("CompositeGlyphs8"),
QByteArrayLiteral("CompositeGlyphs16"),
QByteArrayLiteral("CompositeGlyphs32"),
QByteArrayLiteral("FillRectangles"),
QByteArrayLiteral("CreateCursor"),
QByteArrayLiteral("SetPictureTransform"),
QByteArrayLiteral("QueryFilters"),
QByteArrayLiteral("SetPictureFilter"),
QByteArrayLiteral("CreateAnimCursor"),
QByteArrayLiteral("AddTraps"),
QByteArrayLiteral("CreateSolidFill"),
QByteArrayLiteral("CreateLinearGradient"),
QByteArrayLiteral("CreateRadialGradient"),
QByteArrayLiteral("CreateConicalGradient")});
}
QVector<QByteArray> syncOpCodes()
{
Update URLs to use https Summary: Largely done automatically using the tools from D19996. Reviewers: yurchor, zzag Reviewed By: yurchor, zzag Subscribers: zzag, yurchor, kwin, kde-doc-english Tags: #kwin, #documentation Differential Revision: https://phabricator.kde.org/D20017
2019-03-25 18:11:15 +00:00
// see https://www.x.org/releases/X11R7.7/doc/xextproto/sync.html
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
// extracted from <xcb/sync.h>
return QVector<QByteArray>({QByteArrayLiteral("Initialize"),
QByteArrayLiteral("ListSystemCounters"),
QByteArrayLiteral("CreateCounter"),
QByteArrayLiteral("DestroyCounter"),
QByteArrayLiteral("QueryCounter"),
QByteArrayLiteral("Await"),
QByteArrayLiteral("ChangeCounter"),
QByteArrayLiteral("SetCounter"),
QByteArrayLiteral("CreateAlarm"),
QByteArrayLiteral("ChangeAlarm"),
QByteArrayLiteral("DestroyAlarm"),
QByteArrayLiteral("QueryAlarm"),
QByteArrayLiteral("SetPriority"),
QByteArrayLiteral("GetPriority"),
QByteArrayLiteral("CreateFence"),
QByteArrayLiteral("TriggerFence"),
QByteArrayLiteral("ResetFence"),
QByteArrayLiteral("DestroyFence"),
QByteArrayLiteral("QueryFence"),
QByteArrayLiteral("AwaitFence")});
}
Add support for GLX in Xcb::Extensions
2014-09-18 15:09:16 +00:00
static QVector<QByteArray> glxOpCodes()
{
return QVector<QByteArray>{
QByteArrayLiteral(""),
QByteArrayLiteral("Render"),
QByteArrayLiteral("RenderLarge"),
QByteArrayLiteral("CreateContext"),
QByteArrayLiteral("DestroyContext"),
QByteArrayLiteral("MakeCurrent"),
QByteArrayLiteral("IsDirect"),
QByteArrayLiteral("QueryVersion"),
QByteArrayLiteral("WaitGL"),
QByteArrayLiteral("WaitX"),
QByteArrayLiteral("CopyContext"),
QByteArrayLiteral("SwapBuffers"),
QByteArrayLiteral("UseXFont"),
QByteArrayLiteral("CreateGLXPixmap"),
QByteArrayLiteral("GetVisualConfigs"),
QByteArrayLiteral("DestroyGLXPixmap"),
QByteArrayLiteral("VendorPrivate"),
QByteArrayLiteral("VendorPrivateWithReply"),
QByteArrayLiteral("QueryExtensionsString"),
QByteArrayLiteral("QueryServerString"),
QByteArrayLiteral("ClientInfo"),
QByteArrayLiteral("GetFBConfigs"),
QByteArrayLiteral("CreatePixmap"),
QByteArrayLiteral("DestroyPixmap"),
QByteArrayLiteral("CreateNewContext"),
QByteArrayLiteral("QueryContext"),
QByteArrayLiteral("MakeContextCurrent"),
QByteArrayLiteral("CreatePbuffer"),
QByteArrayLiteral("DestroyPbuffer"),
QByteArrayLiteral("GetDrawableAttributes"),
QByteArrayLiteral("ChangeDrawableAttributes"),
QByteArrayLiteral("CreateWindow"),
QByteArrayLiteral("DeleteWindow"),
QByteArrayLiteral("SetClientInfoARB"),
QByteArrayLiteral("CreateContextAttribsARB"),
QByteArrayLiteral("SetClientInfo2ARB")
// Opcodes 36-100 are unused
// The GL single commands begin at opcode 101
};
}
static QVector<QByteArray> glxErrorCodes()
{
return QVector<QByteArray>{
QByteArrayLiteral("BadContext"),
QByteArrayLiteral("BadContextState"),
QByteArrayLiteral("BadDrawable"),
QByteArrayLiteral("BadPixmap"),
QByteArrayLiteral("BadContextTag"),
QByteArrayLiteral("BadCurrentWindow"),
QByteArrayLiteral("BadRenderRequest"),
QByteArrayLiteral("BadLargeRequest"),
QByteArrayLiteral("UnsupportedPrivateRequest"),
QByteArrayLiteral("BadFBConfig"),
QByteArrayLiteral("BadPbuffer"),
QByteArrayLiteral("BadCurrentDrawable"),
QByteArrayLiteral("BadWindow"),
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
QByteArrayLiteral("GLXBadProfileARB")};
Add support for GLX in Xcb::Extensions
2014-09-18 15:09:16 +00:00
}
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
ExtensionData::ExtensionData()
: version(0)
, eventBase(0)
Port KWin::errorMessage to new Xcb::Extensions Code section had been in an #ifndef NDEBUG which is the reason why I did not find the usage of Extensions there and why it always compiled successfully. Some data elements which got dropped needed to be added again like a name for the extension and errorBase, etc. Sorry for the inconvenience of a semi-broken master.
2013-01-22 12:17:07 +00:00
, errorBase(0)
, majorOpcode(0)
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
, present(0)
{
}
template<typename reply, typename T, typename F>
void Extensions::initVersion(T cookie, F f, ExtensionData *dataToFill)
{
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
ScopedCPointer<reply> version(f(connection(), cookie, nullptr));
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
dataToFill->version = version->major_version * 0x10 + version->minor_version;
}
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
Extensions *Extensions::s_self = nullptr;
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Extensions *Extensions::self()
{
if (!s_self) {
s_self = new Extensions();
}
return s_self;
}
void Extensions::destroy()
{
delete s_self;
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
s_self = nullptr;
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
}
Extensions::Extensions()
{
init();
}
Extensions::~Extensions()
{
}
void Extensions::init()
{
xcb_connection_t *c = connection();
Fix xrandr primary when the new screen is the connected one We'd trigger updatePrimary before Xwayland had reacted to the new output so we wouldn't end up calling xcb_randr_set_output_primary() as necessary. BUG: 449099
2022-01-25 14:17:51 +00:00
Q_ASSERT(c);
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
xcb_prefetch_extension_data(c, &xcb_shape_id);
xcb_prefetch_extension_data(c, &xcb_randr_id);
xcb_prefetch_extension_data(c, &xcb_damage_id);
xcb_prefetch_extension_data(c, &xcb_composite_id);
xcb_prefetch_extension_data(c, &xcb_xfixes_id);
xcb_prefetch_extension_data(c, &xcb_render_id);
xcb_prefetch_extension_data(c, &xcb_sync_id);
Add support for GLX in Xcb::Extensions
2014-09-18 15:09:16 +00:00
xcb_prefetch_extension_data(c, &xcb_glx_id);
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_shape.name = QByteArray("SHAPE");
m_randr.name = QByteArray("RANDR");
m_damage.name = QByteArray("DAMAGE");
Port KWin::errorMessage to new Xcb::Extensions Code section had been in an #ifndef NDEBUG which is the reason why I did not find the usage of Extensions there and why it always compiled successfully. Some data elements which got dropped needed to be added again like a name for the extension and errorBase, etc. Sorry for the inconvenience of a semi-broken master.
2013-01-22 12:17:07 +00:00
m_composite.name = QByteArray("Composite");
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_fixes.name = QByteArray("XFIXES");
m_render.name = QByteArray("RENDER");
m_sync.name = QByteArray("SYNC");
m_glx.name = QByteArray("GLX");
m_shape.opCodes = shapeOpCodes();
m_randr.opCodes = randrOpCodes();
m_damage.opCodes = damageOpCodes();
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
m_composite.opCodes = compositeOpCodes();
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_fixes.opCodes = fixesOpCodes();
m_render.opCodes = renderOpCodes();
m_sync.opCodes = syncOpCodes();
m_glx.opCodes = glxOpCodes();
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_randr.errorCodes = randrErrorCodes();
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
m_damage.errorCodes = damageErrorCodes();
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_fixes.errorCodes = fixesErrorCodes();
m_glx.errorCodes = glxErrorCodes();
Print better error messages for XCB errors from extensions Qt doesn't print proper error messages for any errors caused by extensions. As KWin is a heavy user of extensions not of interest to Qt (e.g. damage or composite) we do our own error code mapping. The Xcb::ExtensionData is extended by a vector of OpCodes and ErrorNames. In ::workspaceEvent it's checked whether the event is an error and if that is the case KWin tries to map the error to one of the extensions. If that is successful it prints a warning looking like Qt's one: XCB error: 151 (BadDamage), sequence: 12534, resource id: 127926362, \ major code: 143 (DAMAGE), minor code: 2 (Destroy) and the event gets filtered out, so that the Qt error messages is not printed in addition. If the error is not from one of the extensions the error is not filtered out and so the default Qt behavior gets applied. REVIEW: 117421
2014-04-07 13:05:41 +00:00
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
extensionQueryReply(xcb_get_extension_data(c, &xcb_shape_id), &m_shape);
extensionQueryReply(xcb_get_extension_data(c, &xcb_randr_id), &m_randr);
extensionQueryReply(xcb_get_extension_data(c, &xcb_damage_id), &m_damage);
extensionQueryReply(xcb_get_extension_data(c, &xcb_composite_id), &m_composite);
extensionQueryReply(xcb_get_extension_data(c, &xcb_xfixes_id), &m_fixes);
extensionQueryReply(xcb_get_extension_data(c, &xcb_render_id), &m_render);
extensionQueryReply(xcb_get_extension_data(c, &xcb_sync_id), &m_sync);
Add support for GLX in Xcb::Extensions
2014-09-18 15:09:16 +00:00
extensionQueryReply(xcb_get_extension_data(c, &xcb_glx_id), &m_glx);
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
// extension specific queries
xcb_shape_query_version_cookie_t shapeVersion;
xcb_randr_query_version_cookie_t randrVersion;
xcb_damage_query_version_cookie_t damageVersion;
xcb_composite_query_version_cookie_t compositeVersion;
xcb_xfixes_query_version_cookie_t xfixesVersion;
xcb_render_query_version_cookie_t renderVersion;
xcb_sync_initialize_cookie_t syncVersion;
if (m_shape.present) {
shapeVersion = xcb_shape_query_version_unchecked(c);
}
if (m_randr.present) {
randrVersion = xcb_randr_query_version_unchecked(c, RANDR_MAX_MAJOR, RANDR_MAX_MINOR);
XCB variant for displayWidth/Height and update after RandR event DisplayWidth and height provide proper values though internally things are wrong as QDesktopWidget seems to not emit the signal.
2013-08-30 12:30:14 +00:00
xcb_randr_select_input(connection(), rootWindow(), XCB_RANDR_NOTIFY_MASK_SCREEN_CHANGE);
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
}
if (m_damage.present) {
damageVersion = xcb_damage_query_version_unchecked(c, DAMAGE_MAX_MAJOR, DAMAGE_MIN_MAJOR);
}
if (m_composite.present) {
compositeVersion = xcb_composite_query_version_unchecked(c, COMPOSITE_MAX_MAJOR, COMPOSITE_MAX_MINOR);
}
if (m_fixes.present) {
xfixesVersion = xcb_xfixes_query_version_unchecked(c, XFIXES_MAX_MAJOR, XFIXES_MAX_MINOR);
}
if (m_render.present) {
renderVersion = xcb_render_query_version_unchecked(c, RENDER_MAX_MAJOR, RENDER_MAX_MINOR);
}
if (m_sync.present) {
syncVersion = xcb_sync_initialize(c, SYNC_MAX_MAJOR, SYNC_MAX_MINOR);
}
// handle replies
if (m_shape.present) {
initVersion<xcb_shape_query_version_reply_t>(shapeVersion, &xcb_shape_query_version_reply, &m_shape);
}
if (m_randr.present) {
initVersion<xcb_randr_query_version_reply_t>(randrVersion, &xcb_randr_query_version_reply, &m_randr);
}
if (m_damage.present) {
initVersion<xcb_damage_query_version_reply_t>(damageVersion, &xcb_damage_query_version_reply, &m_damage);
}
if (m_composite.present) {
initVersion<xcb_composite_query_version_reply_t>(compositeVersion, &xcb_composite_query_version_reply, &m_composite);
}
if (m_fixes.present) {
initVersion<xcb_xfixes_query_version_reply_t>(xfixesVersion, &xcb_xfixes_query_version_reply, &m_fixes);
}
if (m_render.present) {
initVersion<xcb_render_query_version_reply_t>(renderVersion, &xcb_render_query_version_reply, &m_render);
}
if (m_sync.present) {
initVersion<xcb_sync_initialize_reply_t>(syncVersion, &xcb_sync_initialize_reply, &m_sync);
}
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "Extensions: shape: 0x" << QString::number(m_shape.version, 16)
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
<< " composite: 0x" << QString::number(m_composite.version, 16)
<< " render: 0x" << QString::number(m_render.version, 16)
<< " fixes: 0x" << QString::number(m_fixes.version, 16)
<< " randr: 0x" << QString::number(m_randr.version, 16)
<< " sync: 0x" << QString::number(m_sync.version, 16)
<< " damage: 0x " << QString::number(m_damage.version, 16);
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
}
void Extensions::extensionQueryReply(const xcb_query_extension_reply_t *extension, ExtensionData *dataToFill)
{
if (!extension) {
return;
}
dataToFill->present = extension->present;
dataToFill->eventBase = extension->first_event;
Port KWin::errorMessage to new Xcb::Extensions Code section had been in an #ifndef NDEBUG which is the reason why I did not find the usage of Extensions there and why it always compiled successfully. Some data elements which got dropped needed to be added again like a name for the extension and errorBase, etc. Sorry for the inconvenience of a semi-broken master.
2013-01-22 12:17:07 +00:00
dataToFill->errorBase = extension->first_error;
dataToFill->majorOpcode = extension->major_opcode;
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
}
int Extensions::damageNotifyEvent() const
{
return m_damage.eventBase + XCB_DAMAGE_NOTIFY;
}
bool Extensions::hasShape(xcb_window_t w) const
{
if (!isShapeAvailable()) {
return false;
}
Extend ScopedCPointer from QScopedPointer with QScopedPointerPodDeleter REVIEW: 108242
2013-01-07 13:53:21 +00:00
ScopedCPointer<xcb_shape_query_extents_reply_t> extents(xcb_shape_query_extents_reply(
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
connection(), xcb_shape_query_extents_unchecked(connection(), w), nullptr));
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
if (extents.isNull()) {
return false;
}
return extents->bounding_shaped > 0;
}
bool Extensions::isCompositeOverlayAvailable() const
{
return m_composite.version >= 0x03; // 0.3
}
bool Extensions::isFixesRegionAvailable() const
{
return m_fixes.version >= 0x30; // 3
}
Support for cursor change tracking in KWin::Cursor KWin::Cursor can track changes to the cursor image. It supports a start/stop tracking to not handle these events if nobody is interested in them. When enabled and the cursor image changes a signal is emitted with the serial number of the new cursor image. To track cursor image changes xcb_xfixes_select_cursor_input is used (see XFixes Version 5.0 protocol, section 7). This could be useful for the zoom effect when it replaces the cursor. REVIEW: 110519
2013-05-19 07:32:27 +00:00
int Extensions::fixesCursorNotifyEvent() const
{
return m_fixes.eventBase + XCB_XFIXES_CURSOR_NOTIFY;
}
Port Xwayland data bridge to xcbutils This spares a redundant xcb_prefetch_extension_data() during startup.
2020-07-28 09:33:35 +00:00
int Extensions::fixesSelectionNotifyEvent() const
{
return m_fixes.eventBase + XCB_XFIXES_SELECTION_NOTIFY;
}
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
bool Extensions::isShapeInputAvailable() const
{
return m_shape.version >= 0x11; // 1.1
}
int Extensions::randrNotifyEvent() const
{
return m_randr.eventBase + XCB_RANDR_SCREEN_CHANGE_NOTIFY;
}
int Extensions::shapeNotifyEvent() const
{
return m_shape.eventBase + XCB_SHAPE_NOTIFY;
}
int Extensions::syncAlarmNotifyEvent() const
{
return m_sync.eventBase + XCB_SYNC_ALARM_NOTIFY;
}
Port KWin::errorMessage to new Xcb::Extensions Code section had been in an #ifndef NDEBUG which is the reason why I did not find the usage of Extensions there and why it always compiled successfully. Some data elements which got dropped needed to be added again like a name for the extension and errorBase, etc. Sorry for the inconvenience of a semi-broken master.
2013-01-22 12:17:07 +00:00
QVector<ExtensionData> Extensions::extensions() const
{
Don't call << in a temporary vector Summary: Create the vector using an initializer list. Reviewers: davidedmundson Reviewed By: davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21263
2019-07-08 19:05:21 +00:00
return {
m_shape,
m_randr,
m_damage,
m_composite,
m_render,
m_fixes,
m_sync,
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
m_glx};
Port KWin::errorMessage to new Xcb::Extensions Code section had been in an #ifndef NDEBUG which is the reason why I did not find the usage of Extensions there and why it always compiled successfully. Some data elements which got dropped needed to be added again like a name for the extension and errorBase, etc. Sorry for the inconvenience of a semi-broken master.
2013-01-22 12:17:07 +00:00
}
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
//****************************************
// Shm
//****************************************
Shm::Shm()
: m_shmId(-1)
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
, m_buffer(nullptr)
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
, m_segment(XCB_NONE)
, m_valid(false)
Provide pixmap format in XShm helper
2013-06-17 11:41:35 +00:00
, m_pixmapFormat(XCB_IMAGE_FORMAT_XY_BITMAP)
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
{
m_valid = init();
}
Shm::~Shm()
{
if (m_valid) {
xcb_shm_detach(connection(), m_segment);
shmdt(m_buffer);
}
}
bool Shm::init()
{
const xcb_query_extension_reply_t *ext = xcb_get_extension_data(connection(), &xcb_shm_id);
if (!ext || !ext->present) {
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "SHM extension not available";
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
return false;
}
ScopedCPointer<xcb_shm_query_version_reply_t> version(xcb_shm_query_version_reply(connection(),
Run clang-format The .clang-format file is based on the one in ECM except the following style options: - AlwaysBreakBeforeMultilineStrings - BinPackArguments - BinPackParameters - ColumnLimit - BreakBeforeBraces - KeepEmptyLinesAtTheStartOfBlocks
2022-03-23 10:13:38 +00:00
xcb_shm_query_version_unchecked(connection()), nullptr));
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
if (version.isNull()) {
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "Failed to get SHM extension version information";
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
return false;
}
Provide pixmap format in XShm helper
2013-06-17 11:41:35 +00:00
m_pixmapFormat = version->pixmap_format;
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
const int MAXSIZE = 4096 * 2048 * 4; // TODO check there are not larger windows
m_shmId = shmget(IPC_PRIVATE, MAXSIZE, IPC_CREAT | 0600);
if (m_shmId < 0) {
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "Failed to allocate SHM segment";
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
return false;
}
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
m_buffer = shmat(m_shmId, nullptr, 0 /*read/write*/);
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
if (-1 == reinterpret_cast<long>(m_buffer)) {
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "Failed to attach SHM segment";
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
shmctl(m_shmId, IPC_RMID, nullptr);
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
return false;
}
Use nullptr everywhere Summary: Because KWin is a very old project, we use three kinds of null pointer literals: 0, NULL, and nullptr. Since C++11, it's recommended to use nullptr keyword. This change converts all usages of 0 and NULL literal to nullptr. Even though it breaks git history, we need to do it in order to have consistent code as well to ease code reviews (it's very tempting for some people to add unrelated changes to their patches, e.g. converting NULL to nullptr). Test Plan: Compiles. Reviewers: #kwin, davidedmundson, romangg Reviewed By: #kwin, davidedmundson, romangg Subscribers: romangg, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D23618
2019-09-19 14:46:54 +00:00
shmctl(m_shmId, IPC_RMID, nullptr);
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
m_segment = xcb_generate_id(connection());
const xcb_void_cookie_t cookie = xcb_shm_attach_checked(connection(), m_segment, m_shmId, false);
ScopedCPointer<xcb_generic_error_t> error(xcb_request_check(connection(), cookie));
if (!error.isNull()) {
Introduce categorized logging for kwin core Done by Daniel Pastushchak for KDE during GCI-2014.
2014-12-05 10:42:15 +00:00
qCDebug(KWIN_CORE) << "xcb_shm_attach error: " << error->error_code;
Move XShm helper class to xcbutils That way it can be used also in other parts of KWin.
2013-06-17 11:38:24 +00:00
shmdt(m_buffer);
return false;
}
return true;
}
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
uint32_t toXNative(qreal value)
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
{
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
//debug helper, check for things getting mangled
if (!qFuzzyIsNull(std::fmod(kwinApp()->xwaylandScale() * value, 1))) {
qCritical(KWIN_CORE) << "precision lost! floating value sent to X" << kwinApp()->xwaylandScale() * value;
}
return std::round(kwinApp()->xwaylandScale() * value);
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
}
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
QRect toXNative(const QRectF &r)
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
{
return QRect(toXNative(r.x()), toXNative(r.y()), toXNative(r.width()), toXNative(r.height()));
}
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
qreal fromXNative(int value)
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
{
return value / kwinApp()->xwaylandScale();
}
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
QRectF fromXNative(const QRect &r)
{
return QRectF(fromXNative(r.x()), fromXNative(r.y()), fromXNative(r.width()), fromXNative(r.height()));
}
QSizeF fromXNative(const QSize &s)
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
{
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
return QSizeF(fromXNative(s.width()), fromXNative(s.height()));
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
}
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
qreal nativeFloor(qreal value)
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
{
Use floating geometry throughout With fractional scaling integer based logical geometry may not match device pixels. Once we have a floating point base we can fix that. This also is important for our X11 scale override, with a scale of 2 we could get logical sizes with halves. We already have all input being floating point, this doubles down on it for all remaining geometry. - Outputs remain integer to ensure that any screen on the right remains aligned. - Placement also remains integer based for now. - Repainting is untouched as we always expand outwards (QRectF::toAdjustedRect(). - Decoration is untouched for now - Rules are integer in the config, but floating in the adjusting/API This should also be fine. At some point we'll add a method to snap to the device pixel grid. Effectively `round(value * dpr) / dpr` though right now things mostly work. This also gets rid of a lot of hacks for QRect right and bottom which are very confusing. Parts to watch out in the port are: QRectF::contains now includes edges QRectF::right and bottom are now sane so previous hacks have to be removed QRectF(QPoint, QPoint) behaves differently for the same reason QRectF::center too In test results some adjusted values which are the result of QRect.center because using QRectF's center should behave the same to the user.
2022-05-16 20:13:39 +00:00
return std::floor(value / kwinApp()->xwaylandScale()) * kwinApp()->xwaylandScale();
Support an alternative harcoded scale for X Anything in xcb_ structs are always in X local, all member variables aside from buffers are in kwin local space. This patch ignores a few paths that are not relevant on wayland.
2022-02-02 03:35:13 +00:00
}
Use XCB to resolve the X11 Extensions The extension handling is removed from kwinglobals and moved into the xcbutils in KWin core in namespace KWin::Xcb. The motivation for this change is that the Extensions are only used in KWin core and are marked as internal. So there is no need to have them in the library. What remains in Extensions are the non-native pixmaps. This will be removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap. The remaining code in kwinglobals also still initialize the XLib versions of extensions emitting events. It seems like there are no XEvents emitted if not done so even if the extension is correctly initialized with xcb. This needs to be removed once the event handling is ported over to xcb. REVIEW: 107832
2012-12-21 14:11:31 +00:00
} // namespace Xcb
} // namespace KWin
Reference in a new issue Copy permalink