Screen geometry transposed under Weston with fbdev transform=90 in Qt 5.9 - c++

I have an embedded device where I use Qt 5.9 and Weston. Weston has to use fbdev backend (reasons out of scope) and needs
transform=90
in its output section, otherwise the screen is rotated. It runs fine, but I am unable to get a propper screen size in Qt. To run my application in fullscreen in Qt 5.8 I used:
auto geometry = QGuiApplication::screens().first()->geometry();
view.setGeometry(geometry);
and it was ok. With Qt 5.9 the screen reports its size transposed, so I would have to use
auto geometry = QGuiApplication::screens().first()->geometry();
geometry = geometry.transposed();
view.setGeometry(geometry);
This runs fine again, but the application is no longer portable. I use it on other platforms as well, all work without correctly without transposing.
Looking into the weston log I see
fbdev output 480×854 px
which corresponds to what I get in Qt now. But how to properly detect the rotation caused by transform=90?

Related

Qt Application becomes larger than screen if QDockWidget becomes visible

I have old Qt C++ Application which works perfectly in Desktop or Laptop. I am now trying to make it work in a High DPI touchscreen embedded device having 10 inch screen having 1920 X 1200 Resolution. The device is running Windows 10. I am using MXE to cross-compile for Windows in my Ubuntu machine.
Following the suggestion given over here, I added following lines to automatically scale my application.
static const char ENV_VAR_QT_DEVICE_PIXEL_RATIO[] = "QT_DEVICE_PIXEL_RATIO";
if (!qEnvironmentVariableIsSet(ENV_VAR_QT_DEVICE_PIXEL_RATIO)
&& !qEnvironmentVariableIsSet("QT_AUTO_SCREEN_SCALE_FACTOR")
&& !qEnvironmentVariableIsSet("QT_SCALE_FACTOR")
&& !qEnvironmentVariableIsSet("QT_SCREEN_SCALE_FACTORS")) {
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
}
The application starts with right size:
However, when I make settingWidget visible which is added to QDockWidget, then the application becomes larger than the screen size. I am unable to understand the source of problem.
The codebase is very large if someone wants to review the code then they have to help me with the code fragment which may have the bug and I will shall post it here.

All QT applications on my windows machine have garbled GUI

Starting recently, all QT applications have problems with window sizing and offset, f.i. the window origin (0,0) seems to be moved left and up, so that the menu disappears.
This is how it should look:
And this is how it looks with the problem:
Any idea what setting might have gone haywire ?
I suspect this has happened after an update of Intel HD Graphics Drivers. Anyway, since I have NVIDIA graphics aswell I tried to force the use of it instead of the default Intel HD Graphics, and voila!, it works perfectly. I had the same problem within Qt Creator, and this solved that as well.
It should be noted that I changed the default choice to NVIDIA, and now all applications using Qt work fine.

C++ glfw3: one (of the two) windows in fullscreen mode is not really fullscreen (Mac Os)

In my app (C++14, MacOsX 10.11) I use glfw3 to create two windows that should run in fullscreen mode in two monitors with different native resolutions. I'm creating the windows like this:
glfwCreateWindow(capture_monitor_width, capture_monitor_height, "Capture Window",capture_monitor,NULL);
//..
glfwCreateWindow(projection_monitor_width, projection_monitor_height, "Projection Window",projection_monitor,NULL).
(where projection_motinor_width, projection_monitor_height,capture_motinor_width,capture_monitor_height have been retrieved by the appropriate GLFWvidmode* and they have been tested to be correct in all cases)
The problem is that while I'm getting the fullscreen window correctly in my primary monitor, in my secondary one it is displaced upwards so that it only covers the upper 3/4 (more or less) of the screen. Note that by simply replacing projection_monitorwith NULL in the snippet above I get a properly aligned window that does cover the entire screen (yet it has a title bar which I don't need in my app).
Any ideas? Could this be some sort of bug? Any hacks around it?
With the latest 'devel' version the problem is no longer there. So apparently it's a bug that has already been fixed.

Qt 5.3 full screen issue

I have a Qt application which runs on Ubuntu 12.04 Server with KDE plasma desktop. If I compile with Qt 4.8 full screen works as expected. With Qt 5.3, the window is getting bigger than the available resolution. If I set the resolution using the following code, it works.
QSize sz(QApplication::desktop()->size());
main_window->setFixedSize(sz.width() + 1, sz.height() + 1);
main_window->showFullScreen();
Is this the proper way to solve this issue?
Thanks in advance.
Qt is quite flexible in application sizing and provides you with a lots of informations (and options).
For what concerns QApplication you can use QDesktopWidget.
QDesktopWidget * screen = QApplication::desktop();
screen->availableGeometry();
As stated in the docs about availableGeometry:
Returns the available geometry of the screen with index screen. What
is available will be subrect of screenGeometry() based on what the
platform decides is available (for example excludes the dock and menu
bar on Mac OS X, or the task bar on Windows). The default screen is
used if screen is -1.
Read the section "Use of the Primary Screen" in QDesktopWidget docs for details about the "default screen" and the general handling of multiple screens. Using these methods you will have full control over the way your application is laid out, even with multiple screens available.
For what concerns QGuiApplication you can use QScreen:
QScreen * screen = QGuiApplication::primaryScreen();
screen->availableGeometry();
Finally, in QML it is possible (and advisable) to use Screen object which provides Screen.desktopAvailableWidth and Screen.desktopAvailableHeight which ensure proper resizing with different versions of Android/iOS.

QOpenGL: Color Index mode

I am working in Unix using QT and I am trying to create a bitmap (either QGLWidget or QGLPixelBuffer classes) to render with OpenGL. I need to use color index mode so when I am creating the bitmap I declare this qglformat:
qglformat.setDirectRendering(true);
qglformat.setRgba(false); // COLOR INDEX MODE
qglformat.setDepth(true);
qglformat.setOverlay(false);
qglformat.setDepthBufferSize(16);
And then I create the bitmap:
QGLWidget:
m_qglwiget = new QGLWidget(qglformat);
m_qglwiget->setGeometry(0,0,m_iW,m_iH);
QGLPixelBuffer:
m_pB = new QGLPixelBuffer(m_iW,m_iH,qglformat);
In the first case the Widget is created but if I see if it is valid, the function isValid() returns 'false'. And the execution aborts with that error: QGLContext::makeCurrent(): Cannot make invalid context current. Because the context is also invalid.
Otherwise in the second case, the PixelBuffer is created correctly but it has changed automaticaly the index color mode to the RGB mode.
The same program runs in the same computer using Windows so it is not problem of the graphic card.
Would you told me how could I define correctly the bitmap in order to be able to render in color index mode?
I need to use color index mode
Why? Honestly why?
Color index mode is horrible to work with and NO(!) GPU built after 1998 actually supports it! Also color index mode has been removed from modern versions of OpenGL.
Just. Don't. Use. It!
For OpenGL-1.4 and earlier just pretend it's not there.
If you want to create a color indexed pixmap, render it in RGB, and after that turn it into indexed mode.
he same program runs in the same computer using Windows so it is not problem of the graphic card.
The reason is not the GPU, but that the software emulation shipping with Windows since 1996 also implements color index mode. If the GPU doesn't support a requested pixelformat, but the software emulation does, it will silently drop into software emulation mode.
PixelBuffer is created correctly but it has changed automaticaly the index color mode to the RGB mode.
PBuffers are supported by most (today all) GPUs, but not by the software emulation of Windows. So by requesting a PBuffer the only pixel formats that can satisfy this request will be RGB.