I'm in development of a QT5 application for RPi2 running build root. Initially I'm trying out QTQuick 2 with QML, and running into the issue where the app launches with a resolution of 1280x720 instead of the intended 1920x1080 on an 8" HDMI display.
I don't know if the change I need to make is somewhere within the running OS, or some value within the QT app in order to fix the resolution.
Logging Screen.width and Screen.height in QML outputs the following:
qml: x: 1280 y: 720
I have tried setting env variables as mentioned in this similar post by creating a file in /etc/profiles.d/ with the following.
export QT_QPA_EGLFS_WIDTH=1920
export QT_QPA_EGLFS_HEIGHT=1080
export QT_QPA_EGLFS_PHYSICAL_WIDTH=177
export QT_QPA_EGLFS_PHYSICAL_HEIGHT=100
export QT_QPA_EGLFS_DEPTH=24
export QT_QPA_EGLFS_ALWAYS_SET_MODE=1
# Logging
#export QT_DEBUG_PLUGINS=1
export QT_QPA_EGLFS_DEBUG=1
#export QSG_INFO=1
export QT_LOGGING_RULES=qt.qpa.*=true
However that results in the app not detecting the variables set
Unable to query physical screen size, defaulting to 100 dpi.
To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters).
If I manually source a file containing the values the error above is not output, indicating I believe that they have been seen by QT but still no change is reflected.
I am SSH'ing into the Pi to make changes and run the QT app, and I have also tried using fbset to change there resolution, which does seem to set the terminal into 1080p, but not the app when ran.
fbset -xres 1920 -yres 1080
Here is the logging output when the app is ran.
qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_brcm")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_brcm")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_brcm"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_brcm"
qt.qpa.input: evdevkeyboard: Using device discovery
qt.qpa.input: udev device discovery for type QFlags(0x8)
qt.qpa.input: Found matching devices ()
qt.qpa.input: evdevmouse: Using device discovery
qt.qpa.input: udev device discovery for type QFlags(0x1|0x2)
qt.qpa.input: Found matching devices ()
qt.qpa.input: evdevtouch: Using device discovery
qt.qpa.input: udev device discovery for type QFlags(0x2|0x4)
qt.qpa.input: Found matching devices ()
qml: x: 1280 y: 720
Created context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 1, profile 0) with config:
EGL_BUFFER_SIZE: 16
EGL_ALPHA_SIZE: 0
EGL_BLUE_SIZE: 5
EGL_GREEN_SIZE: 6
EGL_RED_SIZE: 5
EGL_DEPTH_SIZE: 24
EGL_STENCIL_SIZE: 8
EGL_CONFIG_CAVEAT: 12344
EGL_CONFIG_ID: 17
EGL_LEVEL: 0
EGL_MAX_PBUFFER_HEIGHT: 2048
EGL_MAX_PBUFFER_PIXELS: 4194304
EGL_MAX_PBUFFER_WIDTH: 2048
EGL_NATIVE_RENDERABLE: 1
EGL_NATIVE_VISUAL_ID: 107544
EGL_NATIVE_VISUAL_TYPE: 12344
EGL_SAMPLES: 0
EGL_SAMPLE_BUFFERS: 0
EGL_SURFACE_TYPE: 1639
EGL_TRANSPARENT_TYPE: 12344
EGL_TRANSPARENT_BLUE_VALUE: 0
EGL_TRANSPARENT_GREEN_VALUE: 0
EGL_TRANSPARENT_RED_VALUE: 0
EGL_BIND_TO_TEXTURE_RGB: 1
EGL_BIND_TO_TEXTURE_RGBA: 1
EGL_MIN_SWAP_INTERVAL: 0
EGL_MAX_SWAP_INTERVAL: 2147483647
Realised buildroot hadn't copied over a config.txt to the boot partition of the SD card. Copied across a minimal config and set configured a few arguments as stated in this thread.
hdmi_ignore_edid=0xa5000080
hdmi_group=1
hdmi_mode=16
That forced the RPi into 1080p mode and now my QT app is displaying correctly at 1920x1080.
Related
I have been created a build with Buildroot. Also did it everthing on this comment -> https://www.raspberrypi.org/forums/viewtopic.php?t=263418#p1614833
Did my research, and dozens of trials, and I get nothing.
My config is:
Rpi4-64, QT5-Qml, Mesa v3d-vc4, opengl es 2.0
When I try to run my qt qml application on this build, I'm getting this error:
QStandardPaths: wrong permission on runtime directory /usr/bin/, 7755 instead of 7700
drmModeGetResources failed (Operation not supported)
no screens available, assuming 24 -bit color
Cannot create window: no screens available.
Summary : I need to run my qt5 qml application on Rpi 4 with hw accelerated.
I found the solution.
I think the Rpi4 with eglfs using default card for card0, and this is not work. Need to force using card1 for eglfs.
Create a file "eglfs.json" with the following content:
{ "device": "/dev/dri/card1" }
export QT_QPA_EGLFS_KMS_CONFIG=/wherever/is/the/file/eglfs.json
and run your qt app!
Also my qt5 qml program is not showing fonts or text on rpi4 buildroot system. Coping /usr/share/fonts/your_program_fonts worked for me.
OS: Ubuntu 18
Qt: 5.15.1 GCC x64
I tried
qDebug()<<"screens"<<QGuiApplication::screens();
xcb which shows:
screens (QScreen(0x55ab206fba50, name="HDMI-0"), QScreen(0x55ab206fba90, name="DVI-D-0"))
but on eglfs which shows:
screens (QScreen(0x55c07f8308f0, name=""))
backend used eglfs_x11 cannot detect the second screen, so I tired eglfs_kms_egldevice, then the app even cannot enter the main function and give
Could not open DRM (NV) device
As far as i know, eglfs does not support multiple displays
here i find something that might help:
https://forum.qt.io/topic/88111/imx6-multi-screen-use-eglfs
you might wanna try wayland
I am trying to run gym-gazebo on Google Colaboratory.
There is a problem to run gazebo server (gazebo without gui) on Colab.
There was warning on display: Unable to create X window. Rendering will be disabled but I think I fix it.
There also warning about sound card. not sure it related Unable to open audio device,
And there warning about conversion Conversion of sensor type[depth] not supported
Here is an example
Can you help?
In order to run gazebo in a headless mode you need to run gserver executable, instead of gazebo. Not sure which one is used by the gym-gazebo toolkit.
In order to still do rendering in gazebo server (e.g. camera view) you would need to use Xvfb (X Virtual Frame Buffer). It is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
For your specific colab notebook I have changed last cell by adding
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &')
in order to create virtual display and added DISPLAY=:1.0 to the beginning of the last line, so it looked as follows
DISPLAY=:1.0 python gym-gazebo/examples/turtlebot/circuit2c_turtlebot_camera_dqn.py
DISPLAY=:1.0 tells X Window client used by gazebo to use virtual display we have created instead of default one :0.
A complete installation of Gazebo on colab and running it in headless server mode with rendering capability can be achieved the following way:
!curl -sSL http://get.gazebosim.org | sh # Install gazebo
!apt-get install -y xvfb # Install X Virtual Frame Buffer
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &') # create virtual display with size 1600x1200 and 16 bit color. Color can be changed to 24 or 8
!source /usr/share/gazebo-9/setup.sh && DISPLAY=:1.0 gzserver --verbose # Run gazebo and tell X client to use our virtual DISPLAY :1.0
There is also a way to run full gazebo in simulator with gzweb as a head and link to it using ngrok.io explained here as a fully working notebook. https://colab.research.google.com/drive/1A-miW8cTRKzs7B0m1m4enfiFySzBhsgN
You would need to authenticate to ngrok using your auth token which can be created at ngrok.com in order to connect, because it is lunch as background and doesn't print to cell
!./ngrok authtoken <token>
I am using the excellent http://platformio.org/ together with Visual Studio Code to develop for Teensy 3.6 (an Arduino compatible board).
This works great. But I wanted to do better debugging via SWD (serial wire debug).
So I disconnected the Arduino-compatible USB-chip and connected via SWD and JLINK instead. Similar to this: https://mcuoneclipse.com/2017/04/29/modifying-the-teensy-3-5-and-3-6-for-arm-swd-debugging/
I can flash firmware that I built via platformio using the "J-Link Lite" software just fine. Also I can run the J-Link GDB Server without a problem.
But I can't get the IDE integration to work.
My platformio.ini looks like this:
[env:teensy36]
platform = teensy
board = teensy36
framework = arduino
upload_protocol = jlink
debug_tool = jlink
Still the upload_protocol is ignored and when I invoke upload (platformio.exe run --target upload) via the IDE all I get is
Linking .pioenvs\teensy36\firmware.elf
Checking program size
text data bss dec hex filename
17348 172 2696 20216 4ef8 .pioenvs\teensy36\firmware.elf
Building .pioenvs\teensy36\firmware.hex
Uploading .pioenvs\teensy36\firmware.hex
Teensy Loader, Command Line, Version 2.1
Read ".pioenvs\teensy36\firmware.hex": 17520 bytes, 1.7% usage
Soft reboot is not implemented for Win32
Waiting for Teensy device...
(hint: press the reset button)
So it's still trying to upload via Arduino compatible USB connection instead of via SWD connection. How can I get platformio to change the upload method or upload_protocol?
From Project Configuration File platformio.ini, it provides an example of how to configure Jlink GDB server:
[env:bluepill_f103c8]
...
; Debug options
debug_tool = custom
debug_server =
JLinkGDBServer
-singlerun
-if
SWD
-select
USB
-port
2331
-device
STM32F103C8
If JLinkGDBServer.exe is not included in PATH, then you need to specify the full file name of JLinkGDBServer.exe.
I have tried this, it works.
There is another example of using JlinkGDBServerCL.exe - J-Link and ST Nucleo.
I have a Particle Photon which I'm trying to setup. I've tried flashing code both from the web IDE, and locally and it always times out. The device is connecting as it can be seen in these pictures:
The web IDE does not give me much information. It only says "Request Timed Out". This is what I get when I try to flash an .ino code
MacBook-Pro:Desktop User$ particle flash ABCDEFGH123456789 sketch_jun09a/
Including:
sketch_jun09a/sketch_jun09a.ino
attempting to flash firmware to your device ABCDEFGH123456789
Flash device failed.
Request Timed Out
And when I try to flash a firmware.bin file this is what I get:
MacBook-Pro:Downloads Usesr$ particle flash --usb firmware.bin
Found DFU device 2b04:d006
spawning dfu-util -d 2b04:d006 -a 0 -i 0 -s 0x080A0000:leave -D firmware.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x080a0000, size = 5224
Download [=========================] 100% 5224 bytes
Download done.
File downloaded successfully
dfu-util: Error during download get_status
Error writing firmware...dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Error during download get_status
I've seen online that the firmware.bin file seems to be compiled for the Particle Core, and not the Photon, so the device does not allow the code to be flashed. How should I compile the code for it to work? Is there any other solution to this problem? Thank you in advance.
You won't be able to flash a Core firmware to a Photon (they have different architecture and firmware layout). To compile the code for photon you can also use the CLI:
$ particle compile photon sketch_jun09a/
the resulting binary can be flashed using the CLI the same way you did.
To figure out the failed over the air flash I would recommend contacting the support.