1. 17 2月, 2014 4 次提交
  2. 29 1月, 2014 1 次提交
  3. 27 11月, 2013 1 次提交
  4. 26 9月, 2013 1 次提交
    • D
      HID: uhid: allocate static minor · 19872d20
      David Herrmann 提交于
      udev has this nice feature of creating "dead" /dev/<node> device-nodes if
      it finds a devnode:<node> modalias. Once the node is accessed, the kernel
      automatically loads the module that provides the node. However, this
      requires udev to know the major:minor code to use for the node. This
      feature was introduced by:
      
        commit 578454ff
        Author: Kay Sievers <kay.sievers@vrfy.org>
        Date:   Thu May 20 18:07:20 2010 +0200
      
            driver core: add devname module aliases to allow module on-demand auto-loading
      
      However, uhid uses dynamic minor numbers so this doesn't actually work. We
      need to load uhid to know which minor it's going to use.
      
      Hence, allocate a static minor (just like uinput does) and we're good
      to go.
      Reported-by: NTom Gundersen <teg@jklm.no>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      19872d20
  5. 02 9月, 2013 1 次提交
  6. 31 7月, 2013 1 次提交
  7. 18 2月, 2013 1 次提交
  8. 20 7月, 2012 1 次提交
  9. 18 6月, 2012 14 次提交
    • J
      HID: uhid: silence gcc warning · 1a8b294c
      Jiri Kosina 提交于
      gcc is giving me:
      
      drivers/hid/uhid.c: In function ‘uhid_hid_get_raw’:
      drivers/hid/uhid.c:157: warning: ‘len’ may be used uninitialized in this function
      
      which is clearly bogus, as
      
      - when used as memcpy() argument, it's initialized properly
      - the code is structured in a way that either 'ret' or 'len'
        is always initialized, so the return statement always has
        an initialized value.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1a8b294c
    • D
      HID: uhid: implement feature requests · fcfcf0de
      David Herrmann 提交于
      HID standard allows sending a feature request to the device which is
      answered by an HID report. uhid implements this by sending a UHID_FEATURE
      event to user-space which then must answer with UHID_FEATURE_ANSWER. If it
      doesn't do this in a timely manner, the request is discarded silently.
      
      We serialize the feature requests, that is, there is always only a single
      active feature-request sent to user-space, other requests have to wait.
      HIDP and USB-HID do it the same way.
      
      Because we discard feature-requests silently, we must make sure to match
      a response to the corresponding request. We use sequence-IDs for this so
      user-space must copy the ID from the request into the answer.
      Feature-answers are ignored if they do not contain the same ID as the
      currently pending feature request.
      
      Internally, we must make sure that feature-requests are synchronized with
      UHID_DESTROY and close() events. We must not dead-lock when closing the
      HID device, either, so we have to use separate locks.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      fcfcf0de
    • D
      HID: uhid: forward raw output reports to user-space · 3b3baa82
      David Herrmann 提交于
      Some drivers that use non-standard HID features require raw output reports
      sent to the device. We now forward these requests directly to user-space
      so the transport-level driver can correctly send it to the device or
      handle it correspondingly.
      
      There is no way to signal back whether the transmission was successful,
      moreover, there might be lots of messages coming out from the driver
      flushing the output-queue. However, there is currently no driver that
      causes this so we are safe. If some drivers need to transmit lots of data
      this way, we need a method to synchronize this and can implement another
      UHID_OUTPUT_SYNC event.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      3b3baa82
    • D
      HID: uhid: forward output request to user-space · f80e1360
      David Herrmann 提交于
      If the hid-driver wants to send standardized data to the device it uses a
      linux input_event. We forward this to the user-space transport-level
      driver so they can perform the requested action on the device.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f80e1360
    • D
      HID: uhid: forward open/close events to user-space · e7191474
      David Herrmann 提交于
      HID core notifies us with *_open/*_close callbacks when there is an actual
      user of our device. We forward these to user-space so they can react on
      this. This allows user-space to skip I/O unless they receive an OPEN
      event. When they receive a CLOSE event they can stop I/O again to save
      energy.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e7191474
    • D
      HID: uhid: add UHID_START and UHID_STOP events · ec4b7dea
      David Herrmann 提交于
      We send UHID_START and UHID_STOP events to user-space when the HID core
      starts/stops the device. This notifies user-space about driver readiness
      and data-I/O can start now.
      
      This directly forwards the callbacks from hid-core to user-space.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ec4b7dea
    • D
      HID: uhid: forward hid report-descriptor to hid core · 037c061b
      David Herrmann 提交于
      When the uhid_hid_parse callback is called we simply forward it to
      hid_parse_report() with the data that we got in the UHID_CREATE event.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      037c061b
    • D
      HID: uhid: allow feeding input data into uhid devices · 5e87a36a
      David Herrmann 提交于
      This adds a new event type UHID_INPUT which allows user-space to feed raw
      HID reports into the HID subsystem. We copy the data into kernel memory
      and directly feed it into the HID core.
      
      There is no error handling of the events couldn't be parsed so user-space
      should consider all events successfull unless read() returns an error.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5e87a36a
    • D
      HID: uhid: add UHID_CREATE and UHID_DESTROY events · d365c6cf
      David Herrmann 提交于
      UHID_CREATE and UHID_DESTROY are used to create and destroy a device on an
      open uhid char-device. Internally, we allocate and register an HID device
      with the HID core and immediately start the device. From now on events may
      be received or sent to the device.
      
      The UHID_CREATE event has a payload similar to the data used by
      Bluetooth-HIDP when creating a new connection.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d365c6cf
    • D
      HID: uhid: implement write() on uhid devices · 6664ef72
      David Herrmann 提交于
      Similar to read() you can only write() a single event with one call to an
      uhid device. To write multiple events use writev() which is supported by
      uhid.
      
      We currently always return -EOPNOTSUPP but other events will be added in
      later patches.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      6664ef72
    • D
      HID: uhid: implement read() on uhid devices · d937ae5f
      David Herrmann 提交于
      User-space can use read() to get a single event from uhid devices. read()
      does never return multiple events. This allows us to extend the event
      structure and still keep backwards compatibility.
      
      If user-space wants to get multiple events in one syscall, they should use
      the readv()/writev() syscalls which are supported by uhid.
      
      This introduces a new lock which helps us synchronizing simultaneous reads
      from user-space. We also correctly return -EINVAL/-EFAULT only on errors
      and retry the read() when some other thread captured the event faster than
      we did.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d937ae5f
    • D
      HID: uhid: allow poll()'ing on uhid devices · 1f9dec1e
      David Herrmann 提交于
      As long as the internal buffer is not empty, we return POLLIN to
      user-space.
      
      uhid->head and uhid->tail are no atomics so the comparison may return
      inexact results. However, this doesn't matter here as user-space would
      need to poll() in two threads simultaneously to trigger this. And in this
      case it doesn't matter if a cached result is returned or the exact new
      result as user-space does not know which thread returns first from poll()
      and the following read(). So it is safe to compare the values without
      locking.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1f9dec1e
    • D
      HID: uhid: add internal message buffer · ace3d861
      David Herrmann 提交于
      When receiving messages from the HID subsystem, we need to process them
      and store them in an internal buffer so user-space can read() on the char
      device to retrieve the messages.
      
      This adds a static buffer for 32 messages to each uhid device. Each
      message is dynamically allocated so the uhid_device structure does not get
      too big.
      
      uhid_queue() adds a message to the buffer. If the buffer is full, the
      message is discarded. uhid_queue_event() is an helper for messages without
      payload.
      
      This also adds a public header: uhid.h. It contains the declarations for
      the user-space API. It is built around "struct uhid_event" which contains
      a type field which specifies the event type and each event can then add a
      variable-length payload. For now, there is only a dummy event but later
      patches will add new event types and payloads.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ace3d861
    • D
      HID: uhid: introduce user-space I/O driver support for HID · 1ccd7a2a
      David Herrmann 提交于
      This adds a dummy driver that will support user-space I/O drivers for the
      HID subsystem. This allows to write transport-level drivers like USB-HID
      and Bluetooth-HID in user-space.
      
      Low-Energy Bluetooth needs this to feed HID data that is parsed in
      user-space back into the kernel.
      Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      1ccd7a2a