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... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. 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. Why are the TX variables being set via sysfs? 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. > > That same chardev could also be used to implement TX, once a suitable > interface has been fleshed out. The end result might not look exactly > like lirc... > > -- > David Härdeman > -- Jon Smirl jonsmirl@xxxxxxxxx -- 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
