Operating Systems 2015F Lecture 17

Video

The video from the lecture given on November 11, 2015 is now available.

Notes

Lecture 17
----------

Administration

* Solutions for Assignment 4 are up
* Assigment 5 goes up tonight, is due on November 18th.  Solutions
  will go up on the 19th. 
* Test 2 is on November 20th

Project

Graphics
--------

Devices
 - keyboards
 - printers
 - disks
 - tapes
 - text displays
 - text displays + keyboards = terminals
 
Abstractions for devices:
 - character devices
   - non-cached data
 - block devices
   - cached data

But what about graphics?

How do printer graphics work?
 - send raster data (bits/pixels), but at 600dpi+, that's a lot of bits
 - fixed function commands (old inkjects)
    - text
    - simple geometric figures (circles, squares, lines)
    - raster images
 - create a program to generate the pages
   e.g., postscript


Diversion: Kolmogorov complexity
 - smallest program that encodes a bitstring
 - random data means trivial program plus data

lpr = line printer

So what about the graphics display?

Key difference - interactivity
 - how do I update the display, and do so quickly?

Display types
 - text
 - raster graphics (bitmapped screen)
   - generally RAM mapped to screen
   - e.g., Apple II's
 - hardware accelerated graphics
   - manipulating RAM (frame buffer)
   - creating circles, lines, text, etc
   - fixed function
 - GPUs
   - send a program to the "display" and have it run the program
   - multiple programming languages
     - old: display Postscript, used by NeXTStep
     - later, display PDF (Quartz), used by Apple MacOS/iOS
     - OpenGL (Silicon Graphics, SGI), for 3D graphics
     - DirectX, Microsoft's alternative

What about shared displays? (between programs)

Need code to multiplex display between running programs
 - sounds like an OS job right?
 - could be in the kernel, but it is really complicated
 - normal practice is to abstract display management into a userspace process
   - kernel still does some low-level work

 - the classic display manager on UNIX is the X Window System
   - late 1980's
   - predated by proprietary UNIX graphics managers, classic MacOS, EARLY
     Windows, and Xerox PARC work

Xerox PARC
 - company for making paper copies
 - created the Palo Alto Research Center (PARC) to develop new technologies
 - drew on work by Doug Engelbart (go watch the Mother of All Demos)
 - AMAZINGLY successful at developing tech, not so good at commercializing it
   - Graphical User Interfaces
   - Ethernet
   - Laser Printer

X Windows was developed with Distributed Computing in mind
 - the X display manager was an "X Server" that served many "clients"
 - clients could run anywhere on the network
 - actually defined a network protocol for sharing displays, the
 X Windows protocol, implemented by a low-level library, Xlib

X Windows is on the way out
 - network protocol was designed for fixed-function graphics
 - now we want to do compositing rather than manage windows
   - overlay graphical elements, not manage programs running in windows

New generation of compositing managers, not network enabled
 - Wayland

Fancy way of saying...
 - the kernel don't do much with graphics
 - there are graphics drivers, but they only have one customer,
   the display manager

If you want to display something on the screen coming from the kernel...
  - use a userspace helper process!!!

Processes like dbus relay data between processes
  - dbus can be slow because it copies data in memory
  - Android is faster because it uses a new kernel mechanism, Binder