Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
in [Kernel]
|
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Mauro Carvalho Chehab on 26 Nov 2009 14:10 Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> The issue I see is to support at the same time NEC and RC5 protocols. While >> this may work with some devices, for others, the hardware won't allow. > > Sure. We can handle it for the "simple" devices at least. > >>> I think the mapping should be: key = proto + group + raw code, while >>> key2 could be different_proto + different group (if any) + another code. >> This may work for protocols up to RC5, that uses either 8 or 16 bits. >> However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits >> for a scancode. So, we don't have spare bits to represent a protocol, >> if we consider RC6 mode 6 codes as well. > > I don't see this limitation. The number of bits should depend on the > protocol. see include/linux/input.h: struct input_event { struct timeval time; __u16 type; __u16 code; __s32 value; }; extending the value to more than 32 bits require some changes at the input layer, probably breaking kernel API. > >> See above. Also, several protocols have a way to check if a keystroke were >> properly received. When handling just one protocol, we can use this to double >> check the key. However, on a multiprotocol mode, we'll need to disable this >> feature. > > I don't think so. We can pass the space/mark data to all (configured, > i.e. with active mapping) protocol handlers at once. Should a check > fail, we ignore the data. Perhaps another protocol will make some sense > out of it. What happens if it succeeds on two protocol handlers? 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: Andy Walls on 26 Nov 2009 14:50 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: > > Andy Walls <awalls(a)radix.net> writes: > > > >> I would also note that RC-6 Mode 6A, used by most MCE remotes, was > >> developed by Philips, but Microsoft has some sort of licensing interest > >> in it and it is almost surely encumbered somwhow: > > > > I don't know about legal problems in some countries but from the > > technical POV handling the protocol in the kernel is more efficient > > or (/and) simpler. > > A software licensing from Microsoft won't apply to Linux kernel, so I'm > assuming that you're referring to some patent that they could be filled > about RC6 mode 6A. > > I don't know if is there any US patent pending about it (AFAIK, only US > accepts software patents), but there are some prior-art for IR key > decoding. So, I don't see what "innovation" RC6 would be adding. > If it is some new way to transmit waves, the patent issues > aren't related to software, and the device manufacturer had already handled > it when they made their devices. > > If it is just a new keytable, this issue > could be easily solved by loading the keytable via userspace. > > Also, assuming that you can use the driver only with a hardware that comes > with a licensed software, the user has already the license for using it. > > Do you have any details on what patents they are claiming? The US Philips RC-6 patent is US Patent 5,877,702 http://www.google.com/patents?vid=USPAT5877702 Click on download PDF to get a copy of the whole patent. I am not a lawyer. Philips claims' all appear to tie to a transmitter or receiver as part of a system, but most of the claims are about information and bit positions and lengths. I don't know for sure what Microsoft claims to be licensing. I think it is the protocol itself: http://www.microsoft.com/presspass/Press/2002/Apr02/04-16FreestylePhilipsPR.mspx "Under the terms of the agreement, Microsoft and Philips will license to OEMs an IR protocol based on Philips proprietary RC6 IR technology. The patented and globally adopted solution minimizes interference from other remote-control devices in the household. Use of this established protocol will help ensure uniform development of Windows infrared remote-control products, which include infrared remote-control units and remote-control receivers..." http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt See Slide 5, which has the bullet: "How to License RC6" Since the content of the information field in RC-6 Mode 6A is left up to OEMs, I would not be surprised by bogus "innovations" in OEM patents about RC-6 Mode 6A contents. I would not be at all surprised by something like "a bit to indicate a toggled remote key press in the information field" since RC-6's T bits for mode 6 indicate Mode 6A or Mode 6B and not toggles. IMO, given a. the dearth of public information about RC-6, indicating someone thinks it's their trade secret or intellectual property b. Microsoft claiming to license something related to the MCE remote protocols (which are obviously RC-6 Mode 6A), c. my inability to draw a "clear, bright line" that RC-6 Mode 6A encoding and decoding, as needed by MCE remotes, implemented in software doesn't violate anyone's government granted rights to exclusivity. I think it's much better to implement software RC-6 Mode 6A encoding and decoding in user space, doing only the minimum needed to get the hardware setup and going in the kernel. Encoding/decoding of RC-6 by microcontrollers with firmware doesn't worry me. Maybe I'm being too conservative here, but I have a personal interest in keeping Linux free and unencumbered even in the US which, I cannot deny, has a patent system that is screwed up. Regards, Andy > 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: Mauro Carvalho Chehab on 26 Nov 2009 16:00 Christoph Bartelmus wrote: > Hi Mauro, > > on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote: > [...] >> lircd supports input layer interface. Yet, patch 3/3 exports both devices >> that support only pulse/space raw mode and devices that generate scan >> codes via the raw mode interface. It does it by generating artificial >> pulse codes. > > Nonsense! There's no generation of artificial pulse codes in the drivers. > The LIRC interface includes ways to pass decoded IR codes of arbitrary > length to userspace. I might have got wrong then a comment in the middle of the imon_incoming_packet() of the SoundGraph iMON IR patch: + /* + * Translate received data to pulse and space lengths. + * Received data is active low, i.e. pulses are 0 and + * spaces are 1. + * + * My original algorithm was essentially similar to + * Changwoo Ryu's with the exception that he switched + * the incoming bits to active high and also fed an + * initial space to LIRC at the start of a new sequence + * if the previous bit was a pulse. + * + * I've decided to adopt his algorithm. + */ 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: Mauro Carvalho Chehab on 26 Nov 2009 16:10 Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> see include/linux/input.h: >> >> struct input_event { >> struct timeval time; >> __u16 type; >> __u16 code; >> __s32 value; >> }; >> >> extending the value to more than 32 bits require some changes at the >> input layer, probably breaking kernel API. > > Yeah, but that's a "key" space, not "raw code" space. > Keys via input and raw codes via lirc and there is no problem. No. All the other API functions there work with 32 bits for scancodes. For example, the two ioctls to replace a scancode x key code are defined as: #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get keycode */ #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set keycode */ We need to better analyze the API to see how this can be extended to allow bigger widths. (what's worse is that it is defined as "int" instead of "u32" - so the number of bits is different on 32 and on 64 systems) > The mapping tables for input layer need to have variable code widths, > depending on the protocol, sure. > >>> I don't think so. We can pass the space/mark data to all (configured, >>> i.e. with active mapping) protocol handlers at once. Should a check >>> fail, we ignore the data. Perhaps another protocol will make some sense >>> out of it. >> What happens if it succeeds on two protocol handlers? > > We signal both and hope it isn't self-destruct button. > We can't fix it no matter how hard we try. We can fix. Just let the userspace select what protocol(s) is(are) enabled. 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: Mauro Carvalho Chehab on 26 Nov 2009 16:30
Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> The removal of the existing keymaps from kernel depends on having an >> application >> to be called from udev to load the proper keymaps when a device is probed. >> >> After having it for a while, we should deprecate the in-kernel keymaps >> and move them to userspace. > > Sounds like a plan. > >> I also think that it is important to remove the 7 bits limitation from >> all drivers >> and re-generate the keymaps, since they'll change after it. > > I think the existing space/mark media drivers need to be reworked > completely. Nah. the changes aren't big. The first part of the change were already done for 2.6.32: instead of having a vector of 128 elements, where the element order used to be the masked scancode, we now have a table of scancode x keycode, defined as: struct ir_scancode { u16 scancode; u32 keycode; }; Changing scancode to u32 is as easy as edit a file - it is currently 16 just because all currently supported IR's and protocols have 16 bits only - there's no in-kernel implementation for RC6 mode 6 yet. However, increasing it above to 64 bits will break on 32 bits kernels (and above 64 bits, on all architectures), due to the current API limits. this change is currently limited to the ir keytables, but I have a patch already done extending this change for the drivers to work directly with the new table. The next step is to replace the ir->mask_keycode at the drivers to a value that gets the entire scancode. We may still need a mask there, since not all drivers output a 32 bits scancode. Also, there's no single "space/mark" media driver. All drivers that support pulse/space also support in-hardware IR decoding, in order to support the different types of devices. They generally support several ways to get keys: - serial pulse/space decoding on one GPIO pin (most pci hardware have); - serial pulse/space decoding via a IRQ enabled GPIO pin (several saa7134 IR's use this way); - i2c IR's (common on several popular devices); - parallel scancode output via gpio pins several cx88 IR's use this way); - direct IR hardware decoding done by the video chipset (DibCom and newer em28xx hardware, for example). So, the driver input complexity is needed to support all those different ways. So, rewriting it would likely cause regressions. I agree that there are some cleanups that should be done for the serial pulse/space raw decoding. By adding a lirc interface, we'll need to have a common code for handling those events anyway. 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/ |