summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/eglfs/api/qeglfswindow_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Introduce VK_KHR_display support for i.MX8 devicesLaszlo Agocs2020-01-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The eglfs_viv backend has Vulkan support now. While the support code is common (lives in api/vulkan), we will not expose this for any other integration yet, without the appropriate testing. While putting this to eglfs seems unintuitive at first, it turns out that for Vivante in particular this is very useful, since we can rely on the existing framebuffer device infrastructure to solve certain problems (like the lack of vsync) The VK_KHR_display implementation of Vivante currently exhibits all the known issues of the old, fbdev-style EGL plumbing (presumably since it lives on top of that): - No vsync. This can be fixed by setting QT_QPA_EGLFS_FORCEVSYNC. - May need a manual call to fbset to set the correct resolution before launching the Qt app. - And of course it lacks all the multi-screen features provided by drm. - Plus, it seems the swapchain only supports a min/max buffer count of 1. This needs special handling in QRhi since until now we assumed that there was always at least 2 buffers available. [ChangeLog][Platform Specific Changes][Linux] Vulkan is now supported by eglfs (eglfs_viv backend) on i.MX8 devices with the Vivante graphics stack. This is done via VK_KHR_display so no windowing system is required. Task-number: QTBUG-78754 Change-Id: I7530aa026d4b904b9de83f9bdbdc4897ae770e71 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* eglfs: Fix raster windowsLaszlo Agocs2019-08-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Also sanitize the initial WebAssembly hack. Both eglfs and wasm lack the concept of true raster windows. A QWindow with RasterSurface is rendered with OpenGL no matter what. The two platforms took two different approaches to work around the rest of the machinery: - wasm disabled the QOpenGLContext warning for non-OpenGL QWindows, - eglfs forced the QWindow surfaceType to OpenGLSurface whenever it was originally set to RasterSurface. Now, the latter breaks since c4e9eabc309a275efc222f4127f31ba4677259b7, leaving all raster window applications failing on eglfs, because flush in the backingstore is now checking the surface type and disallows OpenGLSurface windows. (just like how QOpenGLContext disallows RasterSurface windows) To solve all this correctly, introduce a new platform capability, OpenGLOnRasterSurface, and remove the special handling in the platform plugins. Change-Id: I7785dfb1c955577bbdccdc14ebaaac5babdec57c Fixes: QTBUG-77100 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Segfault when the exiting the application under platform eglfsElena Zaretskaya2019-02-271-0/+1
| | | | | | | | | | | | | | | | | If you run an application under eglfs, it falls with segfault on the exit. For example, examples/gui/analogclock, examples/widgets/widgets/analogclock, examples/opengl/cube, examples/opengl/qopenglwidget, etc. (I have added the function keyPressEvent to exit by qApp->quit(), if needed). It isn't appear in applications using QQuickView or QGLWindow. This is because QCoreApplication destructor, where the variable self = 0 (therefore, qGuiApp = 0), is called before than QOpenGLVertexArrayObject::destroy(), where qGuiApp is accessed (qGuiApp->thread()). Task-number: QTBUG-73824 Change-Id: I1dc55d5e811bfe8a8ea2178752e8771f8644d356 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix compilation with clang 4 on LinuxLars Knoll2017-09-151-1/+1
| | | | | Change-Id: I7fdafeced7cdef7a97b4e004e9302cb2f1e6f258 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* eglfs: Replace Q_DECL_OVERRIDE by overrideAlexander Volkov2016-12-071-19/+19
| | | | | | | | We can use 'override' directly since Qt 5.7. Also remove redundant 'virtual'. Change-Id: I4c1d5d8a69bf51a7f31077f7cdc74ba06da0bc11 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Enable building EGLFS and MinimalEGL with QT_NO_OPENGLAndy Nichols2016-11-171-3/+13
| | | | | | | | | | | | | It is possible to have support for EGL without having support for OpenGL for example with OpenVG. Unfortanately many features of EGLFS require OpenGL (Cursor, MultiWindow, QEGLPlatformContext, QBackingStore), so the plugins become pretty useless on their own. This is necessary if you still want to use Qt as a method to provide an EGL surface to render to via QWindow. This is the method by which Qt Quick uses OpenVG to render its content when available. Change-Id: I34973b21bf1932865950ce6a78b71b3a29360d65 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* port to modularized platformsupport librariesOswald Buddenhagen2016-10-151-1/+1
| | | | | Change-Id: I20eb0e33abfd70b6a5240e7b6b0aa0425f2d2ee7 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* eglfs: make qeglfsglobal.h privateLaszlo Agocs2016-09-221-1/+1
| | | | | | | | | | | | To avoid build system warnings about including _p headers. There is no real reason to have this as a .h header anymore, now that it is in the device integration private module. Change-Id: I16526419356284e66861f95d1d0553abf0711218 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Giulio Camuffo <giulio.camuffo@kdab.com> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* eglfs: Move remaining sources to under apiLaszlo Agocs2016-09-221-1/+1
| | | | | | | | | | | | | | Move platform integration, context and offscreensurface to under 'api'. This allows accessing these from out-of-tree eglfs backends as well. For instance, the upcoming eglfs_emu backend for the Qt Simulator may need access to QEglFSIntegration. Clean up the project files and remove out-of-date comments (the private module QtEglFSDeviceIntegration is not really header-less since 5.7). Change-Id: If96dd5780a6bd33a1cf29164364df9bf921c4d01 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Install some eglfsdeviceintegration headers, as a private moduleGiulio Camuffo2016-06-031-0/+129
This allows external integrations to be developed against it. Also uniforms all class names as QEglFSFoo. Change-Id: I72ff37c0fcdf1ccd37110b4c36874d6c99b2e743 Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>