Another approach to IR
in [Kernel]
|
From: Mauro Carvalho Chehab on 1 Dec 2009 14:10 Dmitry Torokhov wrote: > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver >> to change the protocol in runtime. >> > > Mauro, > > I think this kind of confuguration belongs to lirc device space, > not input/evdev. This is the same as protocol selection for psmouse > module: while it is normally auto-detected we have sysfs attribute to > force one or another and it is tied to serio device, not input > device. Dmitry, This has nothing to do with the raw interface nor with lirc. This problem happens with the evdev interface and already affects the in-kernel drivers. In this case, psmouse is not a good example. With a mouse, when a movement occurs, you'll receive some data from its port. So, a software can autodetect the protocol. The same principle can be used also with a raw pulse/space interface, where software can autodetect the protocol. However, with hardware decoded IR's, when the hardware detects a code from the wrong protocol, it simply discards the unknown protocol code without any advice. So, there's no way to autodetect. You need to set the right protocol before enabling the hardware decoder, or no scan code will be produced at all. Also, the same hardware can work with more than one protocol, on several cases, but the list is generally limited to a few different protocols. So, a way to enumerate what protocols are supported by the hardware is needed. Let me give you a practical example: I have here a a Pixelview SBTVD USB stick, for ISDB-T digital TV standard. Pixelview provides a very inexpensive and limited NEC protocol-based IR, with a dozen of keys. However, the hardware of the stick has the same components that are also present on similar devices made by other manufacturers, with are shipped with different IR's, running different protocols. The same hardware design is also used with other models that work with DVB or ATSC video standards. For example, the same dib0700 driver supports this ISDB-T device and, for example, a Hauppauge Nova-T DVB stick, that used a Hauppauge Grey IR, based on RC5 protocol. Due to the lack of an evdev API call to select the IR protocol, an ugly modprobe parameter is provided to select the protocol at module boot time. So, if people want to use the original NEC protocol-based IR, they need to do: modprobe dvb_usb_dib0700 dvb_usb_dib0700_ir_proto=0 But, if they want to use a decent IR, even having the keycodes for the RC5 remotes there, the driver needs to be reloaded with a different parameter, to change the hardware to use a different decoder. This is not an isolated case of this driver. The same problem happens will all other in-kernel drivers at drivers/media. Due to the lack of an API for it, each driver has their own way to handle the protocols, but basically, on almost all drivers, even supporting different protocols, the driver limits the usage of just the protocol provided by the shipped remote. To solve this, we really need to extend evdev API to do 3 things: enumberate the supported protocols, get the current protocol(s), and select the protocol(s) that will be used by a newer table. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jon Smirl on 1 Dec 2009 14:30 On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab <mchehab(a)redhat.com> wrote: > Due to the lack of an API for it, each driver has their own way to handle the > protocols, but basically, on almost all drivers, even supporting different protocols, > the driver limits the usage of just the protocol provided by the shipped remote. > > To solve this, we really need to extend evdev API to do 3 things: enumberate the > supported protocols, get the current protocol(s), and select the protocol(s) that > will be used by a newer table. evdev capabilities bits can support enumerating the supported protocols. I'm not sure if you can write those bits back into evdev to turn a feature off/on. If not its something that could be added to evdev. I agree that there is no consistency in the existing driver implementations. -- Jon Smirl jonsmirl(a)gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 1 Dec 2009 15:20 On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: > >> For sure we need to add an EVIOSETPROTO ioctl to allow the driver > >> to change the protocol in runtime. > >> > > > > Mauro, > > > > I think this kind of confuguration belongs to lirc device space, > > not input/evdev. This is the same as protocol selection for psmouse > > module: while it is normally auto-detected we have sysfs attribute to > > force one or another and it is tied to serio device, not input > > device. > > Dmitry, > > This has nothing to do with the raw interface nor with lirc. This problem > happens with the evdev interface and already affects the in-kernel drivers. > > In this case, psmouse is not a good example. With a mouse, when a movement > occurs, you'll receive some data from its port. So, a software can autodetect > the protocol. The same principle can be used also with a raw pulse/space > interface, where software can autodetect the protocol. Or, in certain cases, it can not. > [... skipped rationale for adding a way to control protocol (with which I agree) ...] > > To solve this, we really need to extend evdev API to do 3 things: enumberate the > supported protocols, get the current protocol(s), and select the protocol(s) that > will be used by a newer table. > And here we start disagreeing. My preference would be for adding this API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), since it only applicable to IR, not to input devices in general. Once you selected proper protocol(s) and maybe instantiated several input devices then udev (by examining input device capabilities and optionally looking up at the parent device properties) would use input evdev API to load proper keymap. Because translation of driver-specific codes into standard key definitions is in the input realm. Reading these driver-specific codes from hardware is outside of input layer domain. Just as psmouse ability to specify protocol is not shoved into evdev; just as atkbd quirks (force release key list and other driver-specific options) are not in evdev either; we should not overload evdev interface with IR-specific items. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 1 Dec 2009 16:10 Dmitry Torokhov wrote: > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: >> Dmitry Torokhov wrote: >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: >>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver >>>> to change the protocol in runtime. >>>> >>> Mauro, >>> >>> I think this kind of confuguration belongs to lirc device space, >>> not input/evdev. This is the same as protocol selection for psmouse >>> module: while it is normally auto-detected we have sysfs attribute to >>> force one or another and it is tied to serio device, not input >>> device. >> Dmitry, >> >> This has nothing to do with the raw interface nor with lirc. This problem >> happens with the evdev interface and already affects the in-kernel drivers. >> >> In this case, psmouse is not a good example. With a mouse, when a movement >> occurs, you'll receive some data from its port. So, a software can autodetect >> the protocol. The same principle can be used also with a raw pulse/space >> interface, where software can autodetect the protocol. > > Or, in certain cases, it can not. > > [... skipped rationale for adding a way to control protocol (with which > I agree) ...] > >> To solve this, we really need to extend evdev API to do 3 things: enumberate the >> supported protocols, get the current protocol(s), and select the protocol(s) that >> will be used by a newer table. >> > > And here we start disagreeing. My preference would be for adding this > API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), > since it only applicable to IR, not to input devices in general. > > Once you selected proper protocol(s) and maybe instantiated several > input devices then udev (by examining input device capabilities and > optionally looking up at the parent device properties) would use > input evdev API to load proper keymap. Because translation of > driver-specific codes into standard key definitions is in the input > realm. Reading these driver-specific codes from hardware is outside of > input layer domain. > > Just as psmouse ability to specify protocol is not shoved into evdev; > just as atkbd quirks (force release key list and other driver-specific > options) are not in evdev either; we should not overload evdev interface > with IR-specific items. I'm not against mapping those features as sysfs atributes, but they don't belong to lirc, as far as I understand. From all we've discussed, we'll create a lirc interface to allow the direct usage of raw IO. However, IR protocol is a property that is not related to raw IO mode but, instead, to evdev mode. We might add a /sys/class/IR and add IR specific stuff there, but it seems overkill to me and will hide the fact that those parameters are part of the evdev interface. So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). I agree that the code to implement the IR specific sysfs parameter should be kept oustide input core, as they're specific to IR implementations. Would this work for you? Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 2 Dec 2009 04:40
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: > >> Dmitry Torokhov wrote: > >>> On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: > >>>> For sure we need to add an EVIOSETPROTO ioctl to allow the driver > >>>> to change the protocol in runtime. > >>>> > >>> Mauro, > >>> > >>> I think this kind of confuguration belongs to lirc device space, > >>> not input/evdev. This is the same as protocol selection for psmouse > >>> module: while it is normally auto-detected we have sysfs attribute to > >>> force one or another and it is tied to serio device, not input > >>> device. > >> Dmitry, > >> > >> This has nothing to do with the raw interface nor with lirc. This problem > >> happens with the evdev interface and already affects the in-kernel drivers. > >> > >> In this case, psmouse is not a good example. With a mouse, when a movement > >> occurs, you'll receive some data from its port. So, a software can autodetect > >> the protocol. The same principle can be used also with a raw pulse/space > >> interface, where software can autodetect the protocol. > > > > Or, in certain cases, it can not. > > > > [... skipped rationale for adding a way to control protocol (with which > > I agree) ...] > > > >> To solve this, we really need to extend evdev API to do 3 things: enumberate the > >> supported protocols, get the current protocol(s), and select the protocol(s) that > >> will be used by a newer table. > >> > > > > And here we start disagreeing. My preference would be for adding this > > API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace), > > since it only applicable to IR, not to input devices in general. > > > > Once you selected proper protocol(s) and maybe instantiated several > > input devices then udev (by examining input device capabilities and > > optionally looking up at the parent device properties) would use > > input evdev API to load proper keymap. Because translation of > > driver-specific codes into standard key definitions is in the input > > realm. Reading these driver-specific codes from hardware is outside of > > input layer domain. > > > > Just as psmouse ability to specify protocol is not shoved into evdev; > > just as atkbd quirks (force release key list and other driver-specific > > options) are not in evdev either; we should not overload evdev interface > > with IR-specific items. > > I'm not against mapping those features as sysfs atributes, but they don't belong > to lirc, as far as I understand. From all we've discussed, we'll create a lirc > interface to allow the direct usage of raw IO. However, IR protocol is a property > that is not related to raw IO mode but, instead, to evdev mode. > Why would protocol relate to evdev node? Evdev does not really care what how the fact that a certain button was pressed was communicated to it. It may be deliveretd through PS/2 port, or maybe it was Bluetooth HID, or USB HID or USB boot protocol or some custom protocol, or RC-5, NEC or some custom IR protocol. It makes no difference _whatsoever_ to evdev nor any users of evdev care about protocol used by underlying hardware device to transmit the data. > We might add a /sys/class/IR and add IR specific stuff there, but it seems > overkill to me and will hide the fact that those parameters are part of the evdev > interface. > > So, I would just add the IR sysfs parameters at the /sys/class/input, if > the device is an IR (or create it is /sys/class/input/IR). > > I agree that the code to implement the IR specific sysfs parameter should be kept > oustide input core, as they're specific to IR implementations. > > Would this work for you? I am seeing a little bit differently structured subsystem for IR at the moment. I think we should do something like this: - receivers create /sys/class/lirc devices. These devices provide API with a ring buffer (fifo) for the raw data stream coming from (and to) them. - we allow registering several data interfaces/decoders that can be bound (manually or maybe automatically) to lirc devices. lirc devices may provide hints as to which interface(s) better suited for handling the data coming form particular receiver. Several interfaces may be bound to one device at a time. - one of the interfaces is interface implementing current lirc_dev - other interfaces may be in-kernel RC-5 decoder or other decoders. decoders will create instances of input devices (for each remote/substream that they can recognize). This way there is clear layering, protocol selection is kept at lirc level. Would this work? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |