Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

Jarod Wilson wrote:

On Monday 03 August 2009 09:05:28 Anssi Hannula wrote:

quoted

Jarod Wilson wrote:

quoted

Also, out of curiosity, what does a "proper HID driver for it" look
like and/or do that the latest lirc_imon doesn't?

Well, I didn't want to use 3rdparty drivers with my device.

Anyways.. my driver implements a hid_driver (see /drivers/hid/hid-*.c),
and sets a raw_event callback for the non-standard-hid-input events of
the 2nd interface and emits input layer events for those. The device
uses standard HID input protocol in first interface, so my driver
doesn't touch that at all and lets the general hid code handle that
(some remote control buttons are passed by that).

Yeah, a lot of this sounds like what Rene Harder and I have discussed
doing over on the lirc list. We're both a bit tied up with other things
right now though, so its not really progressed in a few weeks, since
we merged a bunch of touchscreen and mouse input device support a bit
ago.

quoted

LCD write packets are
queued via usbhid_submit_report(). The driver also has code for
registering the LCD as standard framebuffer device and allowing led
subsystem access to the icons, though I'm not sure yet if those should
be there (1-bit framebuffers may not be supported by much userspace
code, haven't checked yet; having the icons registered for led subsystem
allows triggers and handling via /sys, but I'm not sure if that is
useful for these kind of icons).

So is the LCD usable with, say, lcdproc? I hadn't ever really thought
about using mine any other way (I have an 0045 device myself, its an
Antec Veris Premiere, which is a rebranded iMON UltraBay).

Well, these can be additional to /dev/lcd*, not necessarily replacing it.

I also see that currently the LCD handling code is somewhat duplicated
at least with lcdproc and VDR imon
(http://projects.vdr-developer.org/wiki/plg-imonlcd), haven't searched
if there are other projects doin the same. Maybe an userspace library
would be better suited for this, though.

quoted

quoted

We're already doing
input layer stuff with the mouse mode and mouse buttons, and looking to
further extend that, potentially making the driver pure input layer,
but still usable with the lirc devinput userspace driver.

Oh, this sounds to me like active work getting lirc into upstreamable
condition :)  Is it that?

It is. I'm hoping to send another submission for upstream review Real
Soon Now. lirc_imon, lirc_mceusb, lirc_serial and lirc_i2c are all in
pretty good shape now, will probably limit the submission to those
four this time around...

Great :)

quoted

More incentive for me to not submit my driver, then.

More than anything, I'd love to see any worthwhile additions in your
work merged into the lirc_imon driver.

I'll see. I have so much other work to do currently, that it may not
happen soon, though.

-- 
Anssi Hannula