X Windows graphics is slowly being replaced by Wayland but there is still a lot to admire about this old system. This extract is from my  book on using C in an IoT context.

Now available as a paperback or ebook from Amazon.

Applying C For The IoT With Linux

1. C,IoT, POSIX & LINUX
2. Kernel Mode, User Mode & Syscall
   
3. Execution, Permissions & Systemd
   Extract Running Programs With Systemd
4. Signals & Exceptions
   Extract  Signals
5. Integer Arithmetic
   Extract: Basic Arithmetic As Bit Operations
   Extract: BCD Arithmetic 
   
6. Fixed Point
   Extract: Simple Fixed Point Arithmetic
7. Floating Point 
8. File Descriptors
   Extract: Simple File Descriptors 
   Extract: Pipes 
9. The Pseudo-File System
   Extract: The Pseudo File System
   Extract: Memory Mapped Files 
10. Graphics
    Extract: framebuffer
    Extract: Programming X Windows ***NEW
11. Sockets
    Extract: Sockets The Client
    Extract: Socket Server
12. Threading
    Extract:  Pthreads
    Extract:  Locking
    Extract:  Condition Variables
    Extract:  Deadline Scheduling
13. Cores Atomics & Memory Management
    Extract: Applying C - Cores 
14. Interupts & Polling
    Extract: Interrupts & Polling 
15. Assembler
    Extract: Assembler

Also see the companion book: Fundamental C

<ASIN:1871962609>

<ASIN:1871962617>

C is not a language known in the context of developing user interfaces, but even small systems occasionally need to communicate with their users. Often all that is needed is the display of a few digits to provide feedback on the current state. A common and low-cost way of doing this is to interface directly to a 7-segment LCD display driven directly by the GPIO lines. Any input is also often provided by physical switches and buttons and handled directly by programming GPIO lines.

In this sense the user interface is just an extension of the low-level GPIO programming in the rest of the system. However, with many small devices being equipped with a full HDMI or VGA graphics output, using a full screen display is a real alternative to the GPIO-driven user interface. This means we have to move to using full Linux graphics from C to create either simple displays at one end of the spectrum or full GUI interfaces, complete with touchscreen, trackball, mouse or keyboard input.

In Chapter but not in this extract

• Choosing a GUI System
• The Framebuffer
• Drawing a Line
• Framebuffer Text PSF 1
• Framebuffer Text PSF 2

Windowing Systems - X11

The framebuffer is a very primitive access to the graphics hardware. At the next level up in the hierarchy we have the window managers and X11 is the longest serving. It was created back in 1984 at MIT and has been stuck at version 11 since 1987, hence X11. It is now being replaced by Wayland but there is still a lot of life left in it.

The X Window System was a revolutionary way of implementing graphics and it is what is responsible for the ease of remote desktop implementation on Linux/Unix machines. X11 provides all of the facilities you need to create and manage windows including input. You can draw within a window, but X11 doesn't provide any widgets such as buttons and hence it doesn't determine a complete GUI.

X11 uses a client-server architecture and this was revolutionary at a time when network communications were generally slow. The idea is that the client sends graphics commands to an X11 server, which might be installed on the same machine or on another machine accessed via a network connection.

Notice that this is not the usual sense of "server" because the X11 server is generally installed on the machine in front of the user and the client is the one that is perhaps located elsewhere. The client sends X11 drawing commands to the server and the server occasionally sends back notifications of user actions, such as mouse clicks and keystrokes.

When the server and client are resident on the same machine, communication is via a named pipe. When they are running on different machines, communication is via sockets, see the next chapter.

The standard way of writing programs that make use of X11 is to make use of the Xlib library, but there is an alternative in the form of the XCB library. In this chapter the focus will be on Xlib because so many other programs are based on it. While the X11 system is usually installed by default, the development system involving Xlib generally isn't. You can install it on Debian based systems using something like:

sudo apt install libx11-dev

As long as it is installed, you will have access to Xlib.h and other header files and to the X11 library, which has to be added to the linker.

The big problem with getting to grips with X11 is that its client-server architecture means you have to do things in a slightly different way from writing or reading directly into a framebuffer. For example, to minimize any transmission protocol overheads, any commands or requests that you issue are usually stored in a buffer, the request buffer. To send the requests to the server you have to use Xflush, which is non-blocking, or Xsync, which is blocking and waits for the server to complete all of the requests. In many cases you don't need to explicitly flush the buffer because it happens whenever the client handles an event from the server.

You also need to know that X11 maintains a hierarchy of windows and every window is a child of some other window. All children of the root window are "top-level" windows and these are managed by the window manager, which can have some unexpected effects. For example, although you specify a position when creating a window, it is usually ignored because the window manager knows best where to place your new window. In the same way, you might not get a window of the size you requested.