Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
Graphics
Screen Graphics Subsystem Developer's Guide
QNX Screen Graphics Subsystem is a graphics framework that provides all the functionality necessary to develop interactive user experiences.
Screen library reference
Two important aspects to note when using Screen are function safety and function execution types.
Events (screen.h)
A Screen event notifies applications of actions such as window creations, properties changing values, and keyboard events. The Screen API manages one event queue per context. However, you can also create an event that's independent of any association with a context.
screen_get_event_property_iv()
Retrieve the current value of the specified event property of type integer

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
  - Gestures Library Reference
    The Gestures library provides gesture recognizers to detect gestures through touch events that occur when you place one or more fingers on a touch screen.
  - Image Library Reference
  - Input Events Library Reference
    The Input Events library provides the framework necessary for Screen Graphics Subsystem to communicate with your touch driver.
  - OpenWF Configuration Developer's Guide
    If you are integrating a new display, you must configure and provide the parameters of your display based on its specifications via the OpenWF Display Configuration API (Wfdcfg Library).
  - OpenWF Display Server User's Guide
    The OpenWF Display Server (wfd-server) is a resource manager that provides applications the ability to show image buffers directly to the display controller via the OpenWF Display API.
  - Screen Graphics Subsystem Developer's Guide
    QNX Screen Graphics Subsystem is a graphics framework that provides all the functionality necessary to develop interactive user experiences.
    - Application Development
      The Screen Graphics Subsystem is based on a client/server model where an application is a client that's requesting graphics services from the server (Screen). It includes a composited windowing system as one of these services, which means all application rendering is performed on off-screen buffers, which then can be later used to update the display.
    - Buffers
      A buffer is an area of memory that stores pixel data. Multiple buffers can be associated with a window or stream, but only one buffer can be associated with a pixmap.
    - Rendering
      Rendering refers to the generation of an image.
    - Windowing
      Windows are used to display content and to combine content produced by different renderers. Each of the different renderers can be in the same process, or in another process or processes.
    - Resource Sharing
      Resource sharing allows the access of buffers and their content within the same application and process, or between different applications and processes.
    - Displaying the contents of windows
      Displays are used to show the contents of your windows on physical hardware such as a computer monitor or a touchscreen display.
    - Cursor Movement
      There is more than one way to set up cursor movement between multiple displays.
    - Input
      One key aspect of Screen that enables the development of fully interactive user experiences is the functionality to support input events and to deliver input and notifications back to applications.
    - Event Handling
      Screen events, which include both input and general events, are associated with a given context and are generally handled in your main application's loop.
    - Asynchronous Notifications
      Applications can request to be asynchronously notified of specific Screen events by way of a sigevent.
    - Permissions and Privileges
    - Security policies
      This section on Screen security policies is intended for system integrators who are responsible for implementing and enforcing security policies that create and maintain a trusted execution environment.
    - Debugging
      Debugging graphics isn't easy. Figuring out where the problem is can be challenging because of the many aspects and components when it comes to graphics. The goal of this chapter is to show the tools and techniques that you can use to help with your investigation.
    - Wayland on Screen
      Running Wayland on the Screen Graphics Subsystem provides a C library implementation of the core Wayland communication library.
    - Utilities and binaries
      Screen includes some utilities and binaries to help with calibration, debugging, and demonstrating features.
    - Screen library reference
      Two important aspects to note when using Screen are function safety and function execution types.
      - Function safety
        Function safety refers to whether or not it's safe to use the Screen API functions in certain situations.
      - Function types
        The tables in this section list the type of each function, where the type indicates the expected timeliness of each function call.
      - General (screen.h)
        Constants and Datatypes that are applicable to multiple Screen API objects.
      - Platform-specific APIs (screen_ext.h)
        This section covers extended Screen API functions.
      - Blits (screen.h)
        Blit APIs are native rendering APIs that use the hardware blitter to move data from one area of memory to another without involving the CPU.
      - Buffers (screen.h)
        A buffer is an area of memory that stores pixel data. Although a buffer can be created in the scope of a context, it can't be used by Screen unless it's attached to a window, stream, or pixmap. Multiple buffers can be associated with a window or stream, but only one buffer can be associated with a pixmap.
      - Contexts (screen.h)
        A context provides the setting for graphics operations within Screen. All Screen API objects, with the exception of events, are created within the scope of a context and access to these objects is always with respect to the context associated with the object. Through a handle to a context, you can identify and access specific Screen API objects (e.g., windows, groups, displays, pixmaps) to set or change their properties.
      - Debugging (screen.h)
        Screen provides statistics that can be enabled to facilitate debugging your applications.
      - Devices (screen.h)
        A device refers to an input device (e.g., keyboard, mouse, joystick, multi-touch display).
      - Displays (screen.h)
        A display refers to a physical device, such as a touchscreen, that presents images to viewers. Use this handle to gain access to display properties (e.g., brightness, DPI, video mode).
      - Events (screen.h)
        A Screen event notifies applications of actions such as window creations, properties changing values, and keyboard events. The Screen API manages one event queue per context. However, you can also create an event that's independent of any association with a context.
        Screen event flags
        Types of event flags
        Screen event types
        Types of events
        Screen input control events
        Types of input control events
        screen_create_event()
        Create an event that can later be filled with event data
        screen_destroy_event()
        Destroy an event and free associated memory
        screen_event_t
        A handle to a Screen event
        screen_get_event()
        Wait for a screen event
        screen_get_event_property_cv()
        Retrieve the current value of the specified event property of type char
        screen_get_event_property_iv()
        Retrieve the current value of the specified event property of type integer
        screen_get_event_property_llv()
        Retrieve the current value of the specified event property of type long long integer
        screen_get_event_property_pv()
        Retrieve the current value of the specified event property of type void*
        screen_inject_event()
        Send an input event to the window that has input focus on a given display
        screen_send_event()
        Send an input event to a process
        screen_set_event_property_cv()
        Set the value of the specified event property of type char
        screen_set_event_property_iv()
        Set the value of the specified event property of type integer
        screen_set_event_property_llv()
        Set the current value of the specified event property of type long long integer
        screen_set_event_property_pv()
        Set the value of the specified event property of type void*
      - Groups (screen.h)
        A group is used to organize and manage multiple windows in your applications. Groups establish relationships between properties of the windows belonging to the same group; therefore applying changes to some properties of the group has an effect on all windows belonging to that group.
      - Pixmaps (screen.h)
        A pixmap is an off-screen rendering target. Its contents can be made visible by association with a window.
      - Sessions (screen.h)
        An input session (session) receives one specific type of input event. Unlike windows, sessions don't produce any graphical content and can't be placed into groups. The only grouping that could be considered for a session is the one that's been established for the window that the session is associated with.
      - Streams (screen.h)
        A stream allows graphical content to be produced and processed by components. With streams, it's not necessary to associate their content to a display. The content can be consumed by components other than Screen. However, these components can still use Screen to display the content.
      - Windows (screen.h)
        A window represents a drawing surface whose content is targeted to a display. There are multiple types of windows (e.g, application, child, embedded) to accommodate the organization of the content for display.
    - Configuring Screen
      You configure libraries, drivers, and Screen parameters using the configuration file, graphics.conf.
    - Glossary
  - Video Capture Developer's Guide
    The video capture framework provides applications the ability to capture frames from a video input source. These frames can be passed to a graphics component such as Screen for display.
- Programming
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

screen_get_event_property_iv()

Graphics and Screen4.0 (8.x)Screen Graphics Subsystem Developer's GuideAPIProgrammingUtilities

Retrieve the current value of the specified event property of type integer

Synopsis:

#include <screen/screen.h>

int screen_get_event_property_iv(screen_event_t ev,
                                 int pname,
                                 int *param)

Arguments:

ev: The handle of the event whose property is being queried. The event must have an event type of Screen event types.
pname: The name of the property whose value is being queried. The properties available for query are of type Screen property types.
param: A pointer to a buffer where this function stores the retrieved value(s). This buffer must be of type int. The buffer may be a single integer or an array of integers, depending on the property being retrieved.

Library:

libscreen

Description:

Function Type: Immediate Execution

This function stores the current value of an event property in a user-provided buffer. The list of properties that can be queried per event type are listed as follows:

Event Type: Any

Event Type: SCREEN_EVENT_DISPLAY

Event Type: SCREEN_EVENT_GAMEPAD

Event Type: SCREEN_EVENT_GESTURE

Event Type: SCREEN_EVENT_IDLE

SCREEN_PROPERTY_IDLE_STATE

Event Type: SCREEN_EVENT_INPUT

Event Type: SCREEN_EVENT_INPUT_CONTROL

SCREEN_PROPERTY_BUTTONS (only for events with name SCREEN_INPUT_CONTROL_POINTER_START or SCREEN_INPUT_CONTROL_POINTER_STOP)
SCREEN_PROPERTY_DEVICE
SCREEN_PROPERTY_NAME
SCREEN_PROPERTY_TOUCH_ID (only for events with name SCREEN_INPUT_CONTROL_MTOUCH_START or SCREEN_INPUT_CONTROL_MTOUCH_STOP)

Event Type: SCREEN_EVENT_JOG

Event Type: SCREEN_EVENT_JOYSTICK

Event Type: SCREEN_EVENT_KEYBOARD

Event Type: SCREEN_EVENT_MANAGER

Event Types: SCREEN_EVENT_MTOUCH_PRETOUCH, SCREEN_EVENT_MTOUCH_TOUCH, SCREEN_EVENT_MTOUCH_MOVE, SCREEN_EVENT_MTOUCH_RELEASE

Event Type: SCREEN_EVENT_POINTER

Event Type: SCREEN_EVENT_PROPERTY

SCREEN_PROPERTY_NAME

Event Type: SCREEN_EVENT_USER

SCREEN_PROPERTY_USER_DATA

Returns:

0 if successful, or -1 if an error occurred (errno is set; refer to errno.h for more details).

Page updated: March 05, 2025