Another approach to IR
in [Kernel]
|
From: Gerd Hoffmann on 2 Dec 2009 06:30 On 12/01/09 22:05, Mauro Carvalho Chehab wrote: > 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). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel $ ll /sys/class/input/ | grep usb2 lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 -> .../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 -> .../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 -> .../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ So "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0" is the device node of the physical device, and the input devices belonging to it are in the "input" subdirectory. If the mouse would be a usb IR receiver the IR attributes should go to /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' subdirectory there. HTH, Gerd -- 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 2 Dec 2009 07:50 Dmitry Torokhov wrote: > 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. The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). > - 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 I don't see why having more than one interface, especially for devices with hardware decoders. On IR remote receivers, internally, there's just one interface per hardware. Considering the hardware decoding case, why to artificially create other interfaces that can't be used simultaneously? No current hardware decoders can do that (or, at least, no current implementation allows). We're foreseen some cases where we'll have that (like Patrick's dib0700 driver), but for now, it is not possible to offer more than one interface to userspace. Creating an arbitrary number of artificial interfaces just to pass a parameter to the driver (the protocol), really seems overkill to me. In the case of the cheap devices with just raw interfaces, running in-kernel decoders, while it will work if you create one interface per protocol per IR receiver, this also seems overkill. Why to do that? It sounds that it will just create additional complexity at the kernelspace and at the userspace, since now userspace programs will need to open more than one device to receive the keycodes. > (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? > > This way there is clear layering, protocol selection is kept at lirc > level. > > Would this work? > -- 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 2 Dec 2009 07:50 Gerd Hoffmann wrote: > On 12/01/09 22:05, Mauro Carvalho Chehab wrote: >> 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). > > No, you add it to the physical device node. > > The usb mouse on the system I'm working on is here: > > zweiblum kraxel $ ll /sys/class/input/ | grep usb2 > lrwxrwxrwx. 1 root root 0 Dec 2 12:07 event7 -> > ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/event7/ > lrwxrwxrwx. 1 root root 0 Dec 2 12:07 input7 -> > ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/ > lrwxrwxrwx. 1 root root 0 Dec 2 12:07 mouse2 -> > ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input7/mouse2/ > > So "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0" is the device > node of the physical device, and the input devices belonging to it are > in the "input" subdirectory. > > If the mouse would be a usb IR receiver the IR attributes should go to > /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 or maybe a 'ir' > subdirectory there. This makes sense to me. 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 2 Dec 2009 10:40 On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > 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. The FIFO will have to appear as a /dev/device or be in debugfs. GregKH sent earlier mail telling me to get the FIFO out of sysfs. > - 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 includes defining IR events for evdev with vendor/device/command triplets? You need those standard events to make apps IR aware. LIRC will also need to inject those events after decoding pulse data. > > This way there is clear layering, protocol selection is kept at lirc > level. Did you checkout capabilities bits in evdev? > > Would this work? > > -- > Dmitry > -- 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 2 Dec 2009 12:10
On Wed, Dec 02, 2009 at 10:37:02AM -0500, Jon Smirl wrote: > On Wed, Dec 2, 2009 at 4:38 AM, Dmitry Torokhov > <dmitry.torokhov(a)gmail.com> wrote: > > 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. > > The FIFO will have to appear as a /dev/device or be in debugfs. GregKH > sent earlier mail telling me to get the FIFO out of sysfs. > No, I expect it not to be directly exposed to userspace at all, just a part of in-kernel subsystem API. This is the way interfaces/decoders will communicate with drivers. lirc_dev interface will take data from fifo and send to userspace. > > - 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 includes defining IR events for evdev with vendor/device/command triplets? No, I believe that adding EV_IR type of events to evdev would be a mistake. > You need those standard events to make apps IR aware. > But I do not want to make application IR-aware. If applications want to be IR-aware they can work with lircd. I want applications react to buttons/actions no matter which device issues those as long as the codes are the same. IOW if you happen to have multimedia-type USB keyboard that has button for play and you have a IR that has that button as well I'd expect application to perform the same response (start playing). > LIRC will also need to inject those events after decoding pulse data. > LIRC will need to inject EV_KEY events. > > > > This way there is clear layering, protocol selection is kept at lirc > > level. > > Did you checkout capabilities bits in evdev? Not sure if I understand the question.. Yes, I am aware that evdev presents capabilities of the device userspace; no, I do not think that they are applicable here (since there won't be EV_IR events). -- 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/ |