Add a driver for DisplayLink DL-1x0/1x5 based USB LCDs and USB-VGA adaptors.
Ported by FUKAUMI Naoki from OpenBSD with many modification.
No particular comments (except from me) on tech-kern@.

There are still many TODO even in MI wscons(4) API to handle this device:

* No detach function for wsdisplay(9).
  Unpluging a device causes a panic. (should be trivial?)

* ioctl() for X server support is currently commented out. ("notyet")
  OpenBSD allows device depedent ioctl()s and they introduced
  UDLIO_DAMAGE ioctl for the damage extension ops of X servers for udl(4).
  Before blindly pulling such ioctl(), probably we should discuss
  how such specific operations should be handled in MI wscons(4) API.

* Screen text of wsemul tty could be mangled during large scroll ops.
  All tty output operations are invoked via ttstart() with the giant
  tty_lock mutex held, so we can't call cv_wait(9) to wait resources
  for data xfers via usbdi(9).h, then text output is silently discarded
  on resource shortage. To handle this without tty_lock reorganization,
  we have to change wsdisplay(9) APIs (especially wsdisplaystart()) to
  return a number of actually handled characters as OpenBSD does, but
  it may require whole API changes around child rasops(9) etc.

* No MI API definition to convert mmap(9) cookie to physical address.
  The conversion is required to create a cookie which will be passed to
  pmap_phys_address(9) in uvm/uvm_device.c:udv_fault(). Most other
  drivers use bus_dmamem_mmap(9) or bus_space_mmap(9), but udl(4) uses
  kmem_alloc(9)'ed memory for bitmap data.
  Furthermore, pmap(9) man page says about pmap_phys_address(9):

    "This function is provided to accommodate systems which have
      physical address spaces larger than can be directly addressed
      by the platform's paddr_t type. The existence of this function is
      highly dubious, and it is expected that this function will be
      removed from the pmap API in a future release of NetBSD."

  As the man page says we have already had split paddr_t and vaddr_t,
  so it's time to remove such old ugly cookie and change all mmap(4)
  functions (mostly in MD bus_dma(9) and bus_space(9) APIs) to return
  simple physical address in paddr_t?

* We need proper device names for wsdisplay1 (and more devices).
  Currently wsdisplay0 uses ttyE0 through ttyE253 (minor 0 to 253)
  for screens, ttyEstat (254) for status, and ttyEcfg (255) for config.
  The next wsdisplay1 will use 256 through 509 for screens, 510 for stat,
  and 511 for config but what names should we use for them? ttyFxxx?

* How to handle multiple sets of wskbd/wsdisplay on a single machine.
  rc.d/wscons doesn't provide method to specify wscons control devices.
  There is no proper interface to specify which keyboard should be connected
  to which wsdisplay, etc.

* And maybe more...

(tsutsui)