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 DDK Guide
The Screen DDK (driver development kit) empowers you to support your own hardware (GPUs, display controller, etc), allowing you to write drivers that map their unique hardware capabilities to the standard Screen APIs.
The libmemobj library
Virtual memory management (virtmem.h)
The functions defined in virtmem.h allow the client to map or unmap the memory object into a process's virtual memory.
memobj_map()
Map a graphics memory object into a process's virtual memory

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 DDK Guide
    The Screen DDK (driver development kit) empowers you to support your own hardware (GPUs, display controller, etc), allowing you to write drivers that map their unique hardware capabilities to the standard Screen APIs.
    - Allocation module
    - Blit module
    - GPU module
    - The libmemobj library
      - memobj
        Share graphics buffer memory between processes
      - Special control flags
      - Creating a memory object handle and allocating its memory (alloc.h)
        The functions defined in alloc.h enable you to create a new memory object handle and allocate required memory on the system.
      - Wrapping existing memory (wrap.h)
        The functions defined in wrap.h enable you to create a new memory object handle that wraps existing memory.
      - Using Memory object handles (handles.h)
        The functions defined in handles.h are helper functions that enable you to get object information (e.g., size, file descriptor, etc.) and close the memory object handle.
      - Physical memory management (physmem.h)
        The functions defined in physmem.h enable the client to lock or unlock the physical memory associated with the memory object and obtain the underlying physical memory layout.
      - Virtual memory management (virtmem.h)
        The functions defined in virtmem.h allow the client to map or unmap the memory object into a process's virtual memory.
        memobj_map()
        Map a graphics memory object into a process's virtual memory
        memobj_unmap()
        Unmaps a graphics memory object from a process's virtual memory
      - Creating additional handles (share.h)
        The functions defined in share.h enable you to create additional memory object handles.
    - The libscrmem library
  - 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.
  - 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 software in Amazon Web Services (AWS) and Microsoft Azure (Azure).
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 and QNX Hypervisor for Safety
The QNX Hypervisor and QNX Hypervisor for Safety products allow you to run multiple OSs on a target system so you can separate critical and non-critical functions, support a wide variety of applications, and reduce hardware costs.
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.

memobj_map()

Map a graphics memory object into a process's virtual memory

Synopsis:

#include <memobj/virtmem.h>

errno_t memobj_map(void **vaddr_out, struct memobj *obj, int pid, int prot, off64_t offset, size_t nbytes)

Arguments:

vaddr_out: A pointer to a void* where this function, if successful, writes the virtual address at which the memory was mapped.
obj: A handle to the memory object you want to map. The mapping is associated with this handle, and is deleted when it's closed.
pid: 0 to map into the calling process; or a process ID specifying the process in which this object shall be mapped.
prot: The access capabilities that you want to use for the memory region being mapped, as for mmap(). Normally PROT_READ | PROT_WRITE.
offset: An offset into the memory object, at which the mapping will start.
nbytes: The number of bytes to map (starting from offset). If 0, map as many bytes as possible.

Library:

libmemobj

Description:

The memobj_map() function maps a graphics memory object into a process's virtual memory. The object doesn't have to be locked.

Returns:

EOK: Success; the memory was mapped, and the address (in the process corresponding to pid), was stored in *addr_out.

EACCES: The wrapped file descriptor isn't usable.

EAGAIN: The mapping couldn't be locked in memory, if required by mlockall(), because of a lack of resources.

EBADF: The gd is invalid, or the wrapped file descriptor is invalid.

EBUSY: The resource you're trying to map is busy.

EINVAL: A parameter is invalid.

EMFILE: The number of mapped regions is at its maximum limit; Refer to the RLIMIT_AS and RLIMIT_DATA resources for setrlimit().

ENODEV: The wrapped file descriptor doesn't support mmap().

ENOMEM: There isn't enough free memory or address space; MAP_FAILED was specified and the mapping would have extended outside the allowed address range, or the mapping couldn't be locked in memory as required by mlockall().

ENXIO: The mapping would have extended outside the valid range for this object.

EOVERFLOW: offset + nbytes would exceed the maximum offset.

EPERM: PROT_EXEC isn't allowed for this object.

ESRCH: The PID isn't valid.

Page updated: June 11, 2026