Build System:
Qt Creator 2.7.2 Based on Qt 5.1.0 (32 bit) Built on Jul 2 2013
Qt 5.1.0 MSVC2010 32bit (ANGLE)
Microsoft Windows SDK for Windows 7 (7.1.7600.0.30514)
Environment:
Windows 7 (VMWare)
Problem:
A new Qt Quick 2 Application (Built-in Elements) project will not run as I receive:
class QWindowsEGLStaticContext *__cdecl QWindowsEGLStaticContext::create(void): Could not initialize egl display: error 12289
QOpenGLFunctions created with non-current context
List of attribute names is either too long or not null-terminated.
Maximum number of attributes on this hardware is 0.
Vertex shader:
attribute highp vec4 vertexCoord;
attribute highp vec4 vertexColor;
uniform highp mat4 matrix;
uniform highp float opacity;
varying lowp vec4 color;
void main() {
gl_Position = matrix * vertexCoord;
color = vertexColor * opacity;
}
Fragment shader:
varying lowp vec4 color;
void main() {
gl_FragColor = color;
}
I believe this is due to it running on a virtual machine.
I have tried both ANGLE and OpenGL versions of Qt but both fail. The OpenGL I expected to fail as I don't believe our VMWare infrastructure has a compatible video driver.
Has anyone else experienced this and managed to work around it?
Thanks,
Marcus
I had the same problem and I resolved it by activating "Accelerate 3D graphics" in vmplayer conf.
After that, I don't have the error message, but the apps still doesn't work: it display a blank screen.
This issue is due to the missing of d3dcompiler, provided by DirectX End-User Runtime, as remarked by Friedemann Kleint's comment on QTBUG-31611. I had the same problem (a blank window) and installing DirectX and reboot the system, has been the resolution.
Installation of a NVIDIA graphic acceleration + the related NVIDIA Software driver of the graphic card will fix the problem after a restart of the PC
Related
I have an OpenGL application with a QWidget-based (no QtQuick/QML) Qt UI that I ported from Qt5 to Qt6. Most of it works fine, except that with Qt 6.4 and the Qt 6.5 beta (Qt up to 6.3 works fine!), the QSurfaceFormat color space setting no longer has an effect. I could not find any changes in the change log that should affect this. The only OpenGL-related change mentioned is to the RHI which shouldn't matter since I don't use QtQuick/QML.
In my main, before creating the QApplication instance I set up my default surface format and the Qt::AA_UseDesktopOpenGL attribute as follows:
auto surfaceFormat = QSurfaceFormat::defaultFormat();
surfaceFormat.setVersion(3, 3);
surfaceFormat.setProfile(QSurfaceFormat::CoreProfile);
surfaceFormat.setOption(QSurfaceFormat::DebugContext);
surfaceFormat.setColorSpace(QColorSpace::NamedColorSpace::SRgb);
surfaceFormat.setSamples(4);
QSurfaceFormat::setDefaultFormat(surfaceFormat);
QApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
QApplication app(argc, argv);
In the constructor of my QOpenGLWidget-derived widget, I set a compatible texture format and the update mode:
setTextureFormat(GL_SRGB8_ALPHA8);
setUpdateBehavior(QOpenGLWidget::NoPartialUpdate);
In initializeGL I set up a QOpenGLDebugLogger and load my OpenGL functions using glad Using QOpenGLFunctions is not an option as that would imply making the rendering code Qt-dependent and/or require significant changes. I also tried outputting the name of the color space reported by the widget's surface format via qDebug() and it is "SRgb" as expected.
At the beginning of paintGL I ensure GL_FRAMEBUFFER_SRGB is enabled before drawing using glEnable(GL_FRAMEBUFFER_SRGB).
In summary, it works in Qt 5.13 to Qt 6.3.2, but stops working with Qt 6.4 (the 6.5 beta adds another bug where menus have a black background but it's a beta). I am not getting any relevant OpenGL debugger messages, just a lone performance warning due to a re-compiled shader. Am I doing something wrong that just happens to work on previous versions or is this a bug that none of the many Qt users have discovered over the course of more than one minor revision? Any ideas regarding resolutions / workarounds?
I`m digging example qt6 6.2.2 camera.pro and found next line code:
m_captureSession.setVideoOutput(ui->viewfinder);
this is the way of outing frames to ui.
I know what QVideoSinc is used for grab every frame and process it.
I have replaced this line with m_captureSession.setVideoSink(&videoSink);
where videoSinc defined as my class :
class MyVideoSinc : public QVideoSink
{
Q_OBJECT
public:
bool videoframeReady=false;
MyVideoSinc()
{
connect(this, &QVideoSink::videoFrameChanged, this, &MyVideoSinc::hvideoFrameChanged);
}
public Q_SLOTS:
void hvideoFrameChanged(const QVideoFrame &frame)
{
videoframeReady=true;
}
};
hvideoFrameChanged raised for every frame in Windows build, but only once in Android application.
What is wrong here. How to grab and process frames from QCamera in QT6 ? I don`t want show frames with ui->viewfinder.
I need processing frames myself.
I made a small repository to show how to process frames with QVideoSink in Qt6. Have a look at it.
I use such approach in my own applications, I tested it on Android 9, all works like a charm.
But be careful, on Linux from launch to launch FPS can differ very much, sometimes FPS are normal, but very often FPS are very-very low - 1 FPS only. This is a bug Qt6, 6.2.3 affected still. Have a look at the bug.
I would like to connect my ESP32 (Lolin32 Lite Dev Board) to a "1.3 inch 7PIN SPI HD Full Color IPS TFT Display Screen ST7789 Drive IC 240*240". I am using the Arduino IDE.
I have not managed to find a ST7789 library for the ESP32. I have tried to port the Arduino_ST7789 library to the ESP32 to no avail (I am relatively new at embedded programming). I am currently writing my own library from scratch, but effort.
What code/libraries would I need to get started with the display?
My hardware connections are as follows
ESP32 -> Display
Pin GND -> GND
Pin 3.3V -> VCC
Pin 18 -> SCL
Pin 23 -> SDA
Pin 15 -> RES
Pin 13 -> DC
Pin 2 -> BLK
I figured out the solution, I wasn't able to use the Arduino_ST7789 library because i did not have the correct boards manager.
To get the correct manager go File->Preferences then scroll down to "Additional Boards Manager URLs" and add the following URL.
https://dl.espressif.com/dl/package_esp32_index.json
Note: If you have existing URLs don't delete them otherwise you will lose access. Add the board to your sketch by going Tools->Board->LoLin D32
Get the relevant libraries by downloading this https://github.com/adafruit/Adafruit-ST7735-Library as a .zip
Next add the library by going Sketch->Include Library->Add .ZIP Library...
Then go to File->Examples->Adafruit ST7785 ST7789 Library->Graphicstest
Use the following code above the setup function
#include <Adafruit_GFX.h> // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <Adafruit_ST7789.h> // Hardware-specific library for ST7789
#include <SPI.h>
#define TFT_CS 5
#define TFT_RST 15 // Or set to -1 and connect to Arduino RESET pin
#define TFT_DC 13
#define TFT_MOSI 23 // Data out
#define TFT_SCLK 18 // Clock out
Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
float p = 3.1415926;
Sit back and enjoy some crazy displays
You can use the Hardware supported SPI as well. Initialize the display library like:
Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);
and adjust the SPI to your specific IO lines at startup (in setup()):#
SPI.begin(TFT_SCLK, TFT_MISO, TFT_MOSI);
tft.init(240, 320); // Init ST7789 320x240
I'm using Xcode 5. I have a OS X Framework / iOS static library project with mixed ObjC/C++ code and language dialects set to C11/C++11.
I added a Cocoa Unit Testing Bundle target which uses XCTest, I created one for both the iOS static library and the OS X framework.
This is the code I have and the error I get in both:
-(void) testExample
{
NSObject* world = [NSObject new];
world = nil; <--- Ambiguous expansion of macro 'NULL'
}
Running the iOS test the compiler tells me it is using the definition of NULL from stddef.h (line 74, ((void*)0)) and the other definition being in usr/include/stdlib.h (line 115, __DARWIN_NULL).
The OS X test fails points to usr/include/MacTypes.h (line 90, __DARWIN_NULL) with this time the alternative being in stddef.h (line 74, ((void*)0)).
Google has nothing on this issue. I'm just like "Well, I guess it's just one of these days...".
Any clues as to what may be going on here, and how to fix it?
UPDATE:
The iOS tests not running were due to creating the iOS unit test bundle with the OS X "Cocoa Unit Testing Bundle". /me slap
The OS X testing issue persists though. But I have a hunch that being on OS X 10.9 (Mavericks) this may be related to a missing 10.9 SDK (Base SDK is set to 10.8).
In your Build Settings for your test target, try setting "Enable Modules" to NO.
I've been having various kinds of trouble with test targets, all around preprocessor expansion. Doing this fixed things for me.
Try this: Add -Wno-ambiguous-macro to Xcode -> Build Settings -> Other C Flags
I'm currently making an OpenGL ES 2.0 drawing app for the iPad and I keep getting the following warnings regarding the shaders:
Check dependencies
[WARN]warning: no rule to process file '$(PROJECT_DIR)/IdeaStorm/Drawing Engine/Shaders/Shader.fsh' of type sourcecode.glsl for architecture i386
[WARN]warning: no rule to process file '$(PROJECT_DIR)/IdeaStorm/Drawing Engine/Shaders/Shader.vsh' of type sourcecode.glsl for architecture i386
My drawing app currently runs fine on my 2nd gen iPad with iOS 5, with exception of this error and runs in the simulator fine as well.
However, the other day I tried running it on my friends 1st gen iPad with iOS 4.3 and the shaders failed to compile.
Can anyone point my in the right direction regarding both this warning and the failure for the shaders to compile for the 1st gen iPad?
By default, when you add a vertex and fragment shader to your project, Xcode mistakenly thinks of them as source files to be compiled instead of resources to be bundled. This causes the above errors you're seeing.
Remove your Shader.fsh and Shader.vsh files from your project target's Compile Sources build phase and make sure they're present within your Copy Bundle Resources phase.
It's a little odd that your shaders compile (at runtime, I assume) successfully on an iPad 2, but not on an original iPad. While the iPad 2 has significantly more shader horsepower than an iPad 1, there shouldn't be much that would cause a shader to fail on one when it works on the other. You could try logging out any shader compilation failures using code like the following (during your shader compilation process):
glGetShaderiv(*shader, GL_COMPILE_STATUS, &status);
if (status != GL_TRUE)
{
GLint logLength;
glGetShaderiv(*shader, GL_INFO_LOG_LENGTH, &logLength);
if (logLength > 0)
{
GLchar *log = (GLchar *)malloc(logLength);
glGetShaderInfoLog(*shader, logLength, &logLength, log);
NSLog(#"Shader compile log:\n%s", log);
free(log);
}
}