Jarod Wilson wrote: > On Monday 03 August 2009 09:05:28 Anssi Hannula wrote: >> Jarod Wilson wrote: >>> 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. > >> 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. >>> 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 :) >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
