---
- branch: MAIN
  date: Mon Nov 30 16:18:35 UTC 2009
  files:
  - new: '1.92'
    old: '1.91'
    path: src/sys/dev/usb/files.usb
    pathrev: src/sys/dev/usb/files.usb@1.92
    type: modified
  - new: '1.1'
    old: '0'
    path: src/sys/dev/usb/udl.c
    pathrev: src/sys/dev/usb/udl.c@1.1
    type: added
  - new: '1.1'
    old: '0'
    path: src/sys/dev/usb/udl.h
    pathrev: src/sys/dev/usb/udl.h@1.1
    type: added
  id: 20091130T161835Z.5eb79d647e7b2aab16685937273616b6095b4de4
  log: |
    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...
  module: src
  subject: 'CVS commit: src/sys/dev/usb'
  unixtime: '1259597915'
  user: tsutsui