On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: > On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman <david@xxxxxxxxxxx> wrote: > > On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: > >> Not that my commit rate has been > 0 LOC lately, but I'd like to see > >> lirc_dev, just to get transmit worked out for the CX23888 chip and > >> cx23885 driver. > >> > >> I think this device will bring to light some assumptions LIRC currently > >> makes about transmit that don't apply to the CX23888 (i.e. LIRC having > >> to perform the pulse timing). The cx23888-ir implementation has a kfifo > >> for holding outgoing pulse data and the hardware itself has an 8 pulse > >> measurement deep fifo. > > > > I think we're eventually going to want to let rc-core create a chardev > > per rc device to allow for things like reading out scancodes (when > > creating keymaps for new and unknown remotes), raw timings (for > > debugging in-kernel decoders and writing new ones), possibly also > > ioctl's (for e.g. setting all RX parameters in one go or to > > create/destroy additional keymaps, though I'm sure some will want all of > > that to go through sysfs). > > That problem is handled differently in the graphics code. You only > have one /dev device for graphics. IOCTLs on it are divided into > ranges - core and driver. The IOCTL call initially lands in the core > code, but if it is in the driver range it simply gets forwarded to the > specific driver and handled there. > > Doing it that was avoids needing two /dev devices nodes for the same > device. Two device nodes has problems. How do you keep them from > being open by two different users and different privilege levels, or > one is open and one closed, etc... I'm not sure which two devices you're talking about. ir-core currently creates no device at all (unless you count the input device). And further down the road I think each rc (ir) device should support multiple keytables, each keytable having an associated input device. Input device(s) would be used by the majority of applications that only want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns would apply to that division... > Splitting the IOCTL range is easy to add to input core and it won't > effect any existing user space code. The input maintainers have already NAK'ed adding any ir-specific ioctls to the input layer, and I tend to agree with them. > Don't forget about binary sysfs attributes. I have scars from > implementing sysfs attributes as text that other people thought should > have been binary. > > There has long been talk of implementing sysfs transactions. I think > the closest thing that got implemented was to not make the attributes > take effect until an action occurs. For example, you would set all of > the RX parameters using sysfs. They would be written into shadow > variables. Then you write to a 'commit' attribute. The write triggers > the copy from the shadow variables to the real ones. I still fail to understand why sysfs is preferrable over ioctls. > Why are the TX variables being set via sysfs? There's not a single line of TX code yet. > I think the attributes > were read only in the code I wrote. Instead I set them via commands in > the input stream. Setting via the stream make it easy to change them > on each transmit. The input layer already supports transactions > wrapping in output. The same transactions could be used to wrap input > parameter setting. Start an input transaction, set the TX variables, > send the pulse data, end the input transaction. I don't remember if I > got around to implementing that. Again, the input maintainers have NAK'ed the kind of changes that would be necessary to support TX through the input layer. We're going to have to go with something ir-core specific. -- David Härdeman -- 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
