On Wed, Feb 12, 2014 at 5:35 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> hid_output_raw_report() is not a ll_driver callback and should not be used.
>> To keep the same code path than before, we are forced to play with the
>> different
On Wed, Feb 12, 2014 at 5:35 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
hid_output_raw_report() is not a ll_driver callback and should not be used.
To keep the same code path than before, we are
Hi
On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
wrote:
> hid_output_raw_report() is not a ll_driver callback and should not be used.
> To keep the same code path than before, we are forced to play with the
> different hid_hw_* calls: if the usb or i2c device does not support
> direct
Hi
On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
hid_output_raw_report() is not a ll_driver callback and should not be used.
To keep the same code path than before, we are forced to play with the
different hid_hw_* calls: if the usb or i2c device does
hid_output_raw_report() is not a ll_driver callback and should not be used.
To keep the same code path than before, we are forced to play with the
different hid_hw_* calls: if the usb or i2c device does not support
direct output reports, then we will rely on the SET_REPORT HID call.
hid_output_raw_report() is not a ll_driver callback and should not be used.
To keep the same code path than before, we are forced to play with the
different hid_hw_* calls: if the usb or i2c device does not support
direct output reports, then we will rely on the SET_REPORT HID call.
6 matches
Mail list logo