Skip to content

Add initial QNX support to backends and example - #9492

Open
mgorchak-blackberry wants to merge 4 commits into
ocornut:masterfrom
mgorchak-blackberry:master
Open

Add initial QNX support to backends and example#9492
mgorchak-blackberry wants to merge 4 commits into
ocornut:masterfrom
mgorchak-blackberry:master

Conversation

@mgorchak-blackberry

Copy link
Copy Markdown

Summary

This PR adds native QNX Screen support to Dear ImGui.

It introduces a reusable QNX Screen platform backend and two complete example
applications:

  • example_screen_opengl3
  • example_screen_vulkan

The OpenGL example uses the existing imgui_impl_opengl3 renderer backend with
IMGUI_IMPL_OPENGL_ES3. No separate OpenGL ES renderer backend is required.

The Vulkan example uses the existing imgui_impl_vulkan renderer backend and
creates the native Vulkan surface with vkCreateScreenSurfaceQNX().

Added files

Platform backend

  • backends/imgui_impl_screen.h
  • backends/imgui_impl_screen.cpp
  • backends/imgui_impl_screen_keysym2ucs.inl

Examples

  • examples/example_screen_opengl3/
  • examples/example_screen_vulkan/

The examples include QNX recursive Makefile hierarchies for:

  • aarch64
  • x86_64

Platform backend features

The QNX Screen backend currently supports:

  • Mouse position
  • Left, right, and middle mouse buttons
  • Horizontal and vertical mouse wheel
  • Touch input using the primary contact
  • Keyboard key events
  • Left/right Shift, Ctrl, Alt, and Super modifier events
  • Text input from QNX Screen key symbols
  • Window focus events
  • Window close events
  • Runtime window-size updates
  • Monotonic frame timing

QNX/X11-style key symbols are converted to Unicode before being submitted through ImGuiIO::AddInputCharacter().
The keysym conversion is based on the public-domain keysym2ucs implementation.

@ocornut

ocornut commented Jul 30, 2026

Copy link
Copy Markdown
Owner

Hello Mike,

Thanks for your PR.
This looks good and polished overall, which I appreciate very much - although I was not able to build/test anything.

I'm generally trying to avoid hosting third-party backends for technologies that are going to be difficult for me to maintain.

Can you consider a path for https://github.com/blackberry to instead host this, so the maintenance would more officially fall on Blackberry? A "clean" repo would essentially consist in the files you added to this PR. If you feel there's a strong reason not to, or that there would be an incentive for me to host this you can message me privately. Either way I would happily add all suitable links to it (in fact, I've already added this PR to https://github.com/ocornut/imgui/wiki/Bindings#qnx-screen as there's no reasons not too, until decided where it is hosted).

If hypothetically I were to merge this in main repository:

    1. Could this be renamed to imgui_impl_qnx or imgui_impl_qnxscreen for visibility? I feel like "screen" being a generic term outside intended audience, it might blend in too much and fail to be noticed.
    1. I would have a pass at comparing the two examples main.cpp with existing counterpart e.g. example_glfw_xxx/main.cpp to reduce diff to required minimum. e.g. Reintroduce removed comments. Ensure example code are matching. Revert braces style. Re-add Style/Fonts blocks. In particular your Vulkan inits has difference and I believe not all of them are strictly necessary. Honestly it is already 90% there. Having close matching examples makes maintenance easier as there are already 33 of them (35 with yours). I am happy to consider any changes to e.g. existing example_xxxx_vulkan/main.cpp file, but I need them to be all closer matches.

Nitpicking:

    1. As the keysym2ucs.inl file is auto-generated and unlikely to require much maintenance, I would (A) strips the long comments (66 KB -> 20 KB) and (B) embed it directly inside the main the source file (preferably at the end of it, if possible). Ample comments can point to the sources and/or generator and/or command-line if needed. I know that's how I would do it in order to keep the backends/ folder clean and neat, and it seems reasonable considering it is auto-generated, not that big, and the data is stable.
    1. I would strive to flatten some of the recursive Makefile hierarchy so the files as in the same folder.

This is just what I would do for imgui/backends/ as a minimalist maximizer, but hosted in any other repo it would be just as nice kept separately and closer to your standard.

@ocornut

ocornut commented Jul 30, 2026

Copy link
Copy Markdown
Owner

The amount of minor/noisy changes in examples also make it harder to find what the important changes are.
I started reducing that diff but honestly it's strange to do if I cannot build it.

imgui-a2426bb-WIP amend example_screen_vulkan example.patch

Again, I'm not against upstreaming small changes but they need to be in sync between the 4-5 examples.

@mgorchak-blackberry

Copy link
Copy Markdown
Author

The amount of minor/noisy changes in examples also make it harder to find what the important changes are. I started reducing that diff but honestly it's strange to do if I cannot build it.

imgui-a2426bb-WIP amend example_screen_vulkan example.patch

Again, I'm not against upstreaming small changes but they need to be in sync between the 4-5 examples.

Hi,

I aligned the OpenGL3 and Vulkan examples with the SDL2 code and coding style as closely as possible. The diff is now minimal.

@mgorchak-blackberry

Copy link
Copy Markdown
Author

Hi,

Can you consider a path for https://github.com/blackberry to instead host this, so the maintenance would more officially fall on Blackberry? A "clean" repo would essentially consist in the files you added to this PR. If you feel there's a strong reason not to, or that there would be an incentive for me to host this you can message me privately. Either way I would happily add all suitable links to it (in fact, I've already added this PR to https://github.com/ocornut/imgui/wiki/Bindings#qnx-screen as there's no reasons not too, until decided where it is hosted).

It is a little difficult to explain, but this work belongs to another department—the open-source team. I work in R&D Graphics, and our goals are somewhat different.

Their team works on QNX Everywhere, porting additional open-source software to QNX Everywhere (free for non-commercial use). My goal, however, is to provide customers with ready-to-use solutions that are easy to integrate.

We mainly use Dear ImGui for technology demonstrations and for prototyping or debugging versions of customer software in areas such as medical technology, robotics, and AI.

I addressed all your comments except the one about the recursive QNX Makefile hierarchy. It is supposed to be structured this way, and it is not something I added. :)

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants