I was looking for an example of a hid driver that needs to customize
resume or provides a post resume function, but couldn't find one.
I would like to implement some post resume code. In particular, the g13 on
resume loses the backlight color, LCD image and LED state. On resume, it
needs feature reports sent to re-establish these settings.
However, I couldn't find a way to either provide a post resume function or
replace resume with a call to hid_resume() followed by the feature
reports.
Any suggestions?
---
Rick
On Tue, 26 Jan 2010, Rick L. Vinyard, Jr. wrote:
> I was looking for an example of a hid driver that needs to customize
> resume or provides a post resume function, but couldn't find one.
>
> I would like to implement some post resume code. In particular, the g13 on
> resume loses the backlight color, LCD image and LED state. On resume, it
> needs feature reports sent to re-establish these settings.
>
> However, I couldn't find a way to either provide a post resume function or
> replace resume with a call to hid_resume() followed by the feature
> reports.
>
> Any suggestions?
Current HID / USBHID code doesn't allow for that. But implementing that
should be pretty straightforward, you can define callbacks in the
hid_device struct and then redirect to them instead of the default ones,
when they are initialized.
If you submit this patch together (but separately) with your Logitech G13
driver, there shouldn't be any obstacle merging it.
--
Jiri Kosina
SUSE Labs, Novell Inc.
Jiri Kosina wrote:
> On Tue, 26 Jan 2010, Rick L. Vinyard, Jr. wrote:
>
>> I was looking for an example of a hid driver that needs to customize
>> resume or provides a post resume function, but couldn't find one.
>>
>> I would like to implement some post resume code. In particular, the g13
>> on
>> resume loses the backlight color, LCD image and LED state. On resume, it
>> needs feature reports sent to re-establish these settings.
>>
>> However, I couldn't find a way to either provide a post resume function
>> or
>> replace resume with a call to hid_resume() followed by the feature
>> reports.
>>
>> Any suggestions?
>
> Current HID / USBHID code doesn't allow for that. But implementing that
> should be pretty straightforward, you can define callbacks in the
> hid_device struct and then redirect to them instead of the default ones,
> when they are initialized.
Sounds good. I was actually thinking of doing a post_reset() and
post_resume().
I think the most common case would be for something like the G13 to
re-establish settings, which from the few devices I'm familiar with would
need to restart the hid subsystem first and then re-establish through
feature reports, et. al. after the hid_resume().
Also, that means that usbhid's hid_resume() doesn't need to be exposed in
the API, or even need to be usb specific.
>
> If you submit this patch together (but separately) with your Logitech G13
> driver, there shouldn't be any obstacle merging it.
>
Sounds good.
Thanks,
Rick
Am Mittwoch, 27. Januar 2010 15:57:48 schrieb Rick L. Vinyard, Jr.:
> I think the most common case would be for something like the G13 to
> re-establish settings, which from the few devices I'm familiar with would
> need to restart the hid subsystem first and then re-establish through
> feature reports, et. al. after the hid_resume().
>
> Also, that means that usbhid's hid_resume() doesn't need to be exposed in
> the API, or even need to be usb specific.
If you do do this please document that you may use only GFP_NOIO
and GFP_ATOMIC in that context.
Regards
Oliver
Oliver Neukum wrote:
> Am Mittwoch, 27. Januar 2010 15:57:48 schrieb Rick L. Vinyard, Jr.:
>> I think the most common case would be for something like the G13 to
>> re-establish settings, which from the few devices I'm familiar with
>> would
>> need to restart the hid subsystem first and then re-establish through
>> feature reports, et. al. after the hid_resume().
>>
>> Also, that means that usbhid's hid_resume() doesn't need to be exposed
>> in
>> the API, or even need to be usb specific.
>
> If you do do this please document that you may use only GFP_NOIO
> and GFP_ATOMIC in that context.
>
> Regards
> Oliver
>
Will do.