Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Mauro, Resend of my proposed patch attached that reverts tuning regressions with my DViCO card, whilst still fixing the original 6Mhz tuning issue. Please merge or let me know how else I should proceed to get this merged. Thanks -Rob perhaps the attached notes will help Rob's case here. I did a few more tests, with just one tuner. First I changed a cable that I was suspicious of (it was way too long anyway) but I got no significant improvement. Then I applied the 'revert2.diff' patch that Rob sent and cold-booted. I reran the test and got significantly lower BER and UNC values. There is still something odd going on, in that the UNC seem to get worse with repeated tunings to the same channel, a few minutes apart (less than 10min). This might be a measurement artefact, I don't know. I might try changing the channel order - that should test whether the trend of the UNC values is with frequency or order in the tuning sequence. Cheers VInce 2009-12-07 Try signaltest.pl again. First, with old cable and no code changes hg identify = c57f47cfb0e8+ tip tuner 0 is usbid 0fe9:db78 do three consecutive runs to see if things worsen with repeated tuning. Frequency Signal Ber Unc = 17750 75.9 % 318.9 376.2 191625000 74.5 % 280.1 904.9 21950 77.0 % 245.2 1862.2 22650 77.0 % 186.4 3525.4 57150 77.1 % 502.9 6161.3 57850 77.2 % 541.1 9128.8 Frequency Signal Ber Unc = 17750 75.5 % 314.6 11219.2 191625000 74.0 % 384.3 12057.3 21950 76.8 % 118.7 13236.9 22650 76.8 % 173.5 15256.6 57150 77.0 % 472.3 17930.7 57850 77.1 % 550.0 20888.8 Frequency Signal Ber Unc = 17750 75.4 % 346.0 23052.8 191625000 73.3 % 347.5 24087.7 21950 76.7 % 236.0 25289.0 22650 76.8 % 190.1 27241.0 57150 76.9 % 541.1 29910.0 57850 77.1 % 511.7 32902.1 Now repeat with the 1.5m cable connecting wall socket to splitter. cold boot the machine hg identify = c57f47cfb0e8+ tip dvb0.frontend0: usbid 0fe9:db78 Frequency Signal Ber Unc = 17750 74.0 % 288.2 784.8 191625000 73.3 % 487.2 1890.9 21950 76.7 % 147.2 3189.8 22650 76.8 % 202.2 5094.7 57150 76.9 % 443.1 7640.6 57850 76.9 % 499.9 10675.3 Frequency Signal Ber Unc = 17750 73.0 % 330.7 12795.4 191625000 72.6 % 291.8 13844.3 21950 76.7 % 132.5 15005.5 22650 76.8 % 136.2 16928.0 57150 76.9 % 525.2 19480.7 57850 77.0 % 522.7 22361.7 Frequency Signal Ber Unc = 17750 75.5 % 361.6 24584.2 191625000 73.8 % 480.9 25816.4 21950 76.7 % 143.4 26962.2 22650 76.8 % 187.5 28846.1 57150 77.0 % 468.4 31448.9 57850 77.0 % 547.3 34511.8 Now make the code change. Cold boot. dvb0.frontend0: usbid 0fe9:db78 Frequency Signal Ber Unc = 17750 76.5 % 0.0 0.0 191625000 76.9 % 136.8 102.3 21950 76.9 % 297.6 549.0 22650 76.8 % 304.7 1461.4 57150 76.9 % 505.0 3801.0 57850 77.0 % 573.7 6818.6 Frequency Signal Ber Unc = 17750 76.4 % 0.0 8345.0 191625000 76.8 % 169.7 8476.0 21950 76.7 % 243.8 8967.2 22650 76.9 % 271.6 9904.7 57150 76.9 % 525.9 12097.4 57850 77.1 %
New USB-Statistics API
Hello together, after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options Actually Manu did propose a new API for fetching enhanced statistics. It uses new IOCTL to directly fetch the statistical data in one go from the frontend. This propose was so far rejected by Mauro who wants to use the S2API get/set calls instead. Now to give everyone a quick overview about the advantages and disadvantages of both approaches I will try to summarize it up: 1st approach: Introduce new IOCTL Pros: - Allows a quick fetch of the entire dataset, which ensures that: 1. all values are fetched in one go (as long as possible) from the frontend, so that they can be treated as one united and be valued in conjunction 2. the requested values arrive the caller in an almost constant timeframe, as the ioctl is directly executed by the driver - It does not interfere with the existing statistics API, which has to be kept alive as it is in use for a long time already. (unifying it's data is not the approach of this new API) Cons: - Forces the application developers to interact with two APIs. The S2API for tuning on the one hand and the Statistics API for reading signal values on the other hand. 2nd approach: Set up S2API calls for reading statistics Pros: - Continous unification of the linuxtv API, allowing all calls to be made through one API. - easy for application developers Cons: - Due to the key/value pairs used for S2API getters the statistical values can't be read as a unique block, so we loose the guarantee, that all of the values can be treatend as one unit expressing the signals state at a concrete time. - Due to the general architecture of the S2API the delay between requesting and receiving the actual data could become too big to allow realtime interpretation of the data (as it is needed for applications like satellite finders, etc.) I hope that this summary is technically correct in all points, if not I'd be thankful for objective corrections. I am not going to articulate my personal opinion in this mail, but I will do it in another mail in reply to this one, so that this mail can be seen as a neutral summary of the current situation. So now it's everyones turn to think about the options and give an opinion. In the end I am quite sure that all of us would have great benefits of an improved statistics API. Cheers, Julian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov a écrit : On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fusté wrote: Mauro Carvalho Chehab wrote: In summary, While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up to 16 bytes (since a read loop for 2^16 is not that expensive), the current approach won't scale with bigger scancode spaces. So, it is needed expand it to work with bigger scancode spaces, used by more recent IR protocols. I'm afraid that any tricks we may try to go around the current limits to still keep using the same ioctl definition will sooner or later cause big headaches. The better is to redesign it to allow using different scancode spaces. I second you: input layer events from drivers should be augmented with a protocol member, allowing us to define new ioctl and new ways to efficiently store and manage sparse scancode spaces (tree, hashtable ). Userspace has no business knowing how driver maps hardware data stream into a keycode, only what is being mapped to what. The way is is done can change from driver-to-driver, from release to release. If I come up with an super-smart or super-stupid way of storing key mapping I won't want to modify userpsace tools to support it. But this is the point for IR. Userspace need a stable and universal driver to driver way to represent the hardware data stream. This is needed for only one but very important application: creating and modifying exchangeable remote mappings. The way of storing in kernel key mapping should not have any impacts on usersapce tools. If this is the case, this is because the actual ioctl is too tied to the way these mapping are stored. These need to changed or be expanded for IR. It will allow us to abstract the scancode value and to use variable length scancode depending on the used protocol, and using the most appropriate scheme to store the scancode/keycode mapping per protocol. The today scancode space will be the legacy one, the default if not specified protocol. It will permit to progressively clean up the actual acceptable mess in the input layer and finally using real scancode - keycode mappings everywhere if it is cleaner/convenient. I am unable to parse this part, sorry. My bad, my English is awful, sorry. :-( Best regards, Emmanuel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
Hallo Thomas! Am 02.12.2009 15:31, schrieb Thomas Kernen: Is someone already working on supporting the TBS 6980 Dual DVB-S2 PCIe card? http://www.tbsdtv.com/english/product/6980.html Have you seen/tried their all-in-one linux source package which was released 2009-12-03? http://www.tbsdtv.com/download/common/linux_tbs_all.rar – Matthias BTW: Where did you get yours? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: That is why I think we should go the other way around - introduce the core which receivers could plug into and decoder framework and once it is ready register lirc-dev as one of the available decoders. The core needs to allow for RF remotes too. -Bluetooth remotes are already in kernel somehow, I don't know how they work, -RF4CE, the 802.15.4 stack has been recently merged, the remotes use a protocol on top of that. These remotes will hit the consumer market next year. Sony, Panasonic and other big names are behind this. -Zwave, the Harmony remotes use Zwave. There is no Zwave support in the kernel that I am aware of. Zwave is proprietary. After these protocols are decoded you end up with scancodes. The scancodes need to get injected into input somehow and then flow through the mapping process. Decoding down to the scancodes probably happens over in the networking code. After an in-kernel IR decoder runs it needs to hand off the scancodes into the input subsystem. This same API can be used by the networking code to hand off RF scancodes. Yes, the same core should be able to work with non infra red remotes, but, depending on how the device is implemented. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: On Nov 26, 2009, at 2:43 PM, Andy Walls wrote: On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Andy Walls awa...@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. ... 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. So I had one of the people who does all the license and patent audits for Fedora packages look at the Philips patent on RC-6. He's 100% positive that the patent *only* covers hardware, there should be no problem whatsoever writing a software decoder for RC-6. OK. Thanks for having some professionals take a look. (I'm assuming that's the only patent.) So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. Good! Please, try to design the decoder as an independent module that gets data from a kfifo and generate scancodes for the input API. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? IMO, the better is, by default, to open just one input device per IR receiver. From what I understand from our discussions, if the user wants to filter IR commands into several input interfaces, some userspace interface will be provided to allow the creation of other input interfaces for that purpose. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: On Nov 26, 2009, at 2:43 PM, Andy Walls wrote: On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Andy Walls awa...@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. ... 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. So I had one of the people who does all the license and patent audits for Fedora packages look at the Philips patent on RC-6. He's 100% positive that the patent *only* covers hardware, there should be no problem whatsoever writing a software decoder for RC-6. OK. Thanks for having some professionals take a look. (I'm assuming that's the only patent.) So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. Applications expect to query device capabilities and expect them to stay somewhat stable (we do support keymap change but I don't think anyone expectes flip-flopping). With RC-5, you have no fields describing the remote. So, all the driver could do is an educated guess. From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that you can distinguish two different remotes when someone press a key there. However, I don't think it is a good idea to automatically create a new interface every time a different vendor is detected. Maybe the user simply have a RC-6 IR to control his TV and doesn't have any intention on using that device on his computer. IMO, the better is to have an API to allow creation of multiple interfaces per IR receiver, based on some scancode matching table and/or on some matching mask. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, or to match address/command tuples on protocols where you just have those fields. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: What about capabilities of the receiver, what frequencies? If a receiver has multiple frequencies, how do you report what frequency the data came in on? IMO, via sysfs. We probably need to think what exactly we report through sysfs siunce it is ABI of sorts. Yes, sure. Probably, the exact needs will popup only when we start to actually writing that part of the core. My intention for now is to just create a /sys/class/irrcv, with one node per each IR receiver and adding a protocol enumeration/selection node there, and add some capabilities for the in-kernel decoders and lirc_dev to create new nodes under that class. When the decoders/lirc_dev patches popup, we'll need to review those sysfs API's. What about multiple apps simultaneously using the pulse data? IMO, the better is to limit the raw interface to just one open. Why woudl we want to do this? Quite often there is a need for observer that maybe does not act on data but allows capturing it. Single-user inetrfaces are PITA. That should work fine as well, but I'm not sure how we'll detect overrun with several kfifo readers. How big is the receive queue? It should be big enough to receive at least one keycode event. Considering that the driver will use kfifo (IMO, it is a good strategy, especially since you won't need any lock if just one open is allowed), it will require a power of two size. Would not it be wither driver- or protocol-specific? Probably. How does access work, root only or any user? IMO, it should be the same requirement as used by an input interface. How are capabilities exposed, sysfs, etc? IMO, sysfs. What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. I think Jon meant userspace interface for attaching particular decoder. I don't think we need an userspace interface for the in-kernel decoders. All it needs is to enable/disable the protocol decoders, imo via sysfs interface. If there is an in-kernel decoder should the pulse data stop being reported, partially stopped, something else? I don't have a strong opinion here, but, from the previous discussions, it seems that people want it to be double-reported by default. If so, I think we need to implement a command at the raw interface to allow disabling the in-kernel decoder, while the raw interface is kept open. Why don't you simply let consumers decide where they will get their data? How? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DVB(!!)-Statistics API
Am 08.12.09 10:16, schrieb Julian Scheel: Hello together, after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options Actually Manu did propose a new API for fetching enhanced statistics. It uses new IOCTL to directly fetch the statistical data in one go from the frontend. This propose was so far rejected by Mauro who wants to use the S2API get/set calls instead. Now to give everyone a quick overview about the advantages and disadvantages of both approaches I will try to summarize it up: 1st approach: Introduce new IOCTL Pros: - Allows a quick fetch of the entire dataset, which ensures that: 1. all values are fetched in one go (as long as possible) from the frontend, so that they can be treated as one united and be valued in conjunction 2. the requested values arrive the caller in an almost constant timeframe, as the ioctl is directly executed by the driver - It does not interfere with the existing statistics API, which has to be kept alive as it is in use for a long time already. (unifying it's data is not the approach of this new API) Cons: - Forces the application developers to interact with two APIs. The S2API for tuning on the one hand and the Statistics API for reading signal values on the other hand. 2nd approach: Set up S2API calls for reading statistics Pros: - Continous unification of the linuxtv API, allowing all calls to be made through one API. - easy for application developers Cons: - Due to the key/value pairs used for S2API getters the statistical values can't be read as a unique block, so we loose the guarantee, that all of the values can be treatend as one unit expressing the signals state at a concrete time. - Due to the general architecture of the S2API the delay between requesting and receiving the actual data could become too big to allow realtime interpretation of the data (as it is needed for applications like satellite finders, etc.) I hope that this summary is technically correct in all points, if not I'd be thankful for objective corrections. I am not going to articulate my personal opinion in this mail, but I will do it in another mail in reply to this one, so that this mail can be seen as a neutral summary of the current situation. So now it's everyones turn to think about the options and give an opinion. In the end I am quite sure that all of us would have great benefits of an improved statistics API. Cheers, Julian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html The above mail of course has nothing to do with USB-Statistics. I must have been slightly confused when typing the message title! Sorry for that! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
No more suffers caused by jelly manhood at night.
World's No 1 doctor recommended solution to many of the common intimacy problems. http://dhwtd.ecwyqutt.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. Applications expect to query device capabilities and expect them to stay somewhat stable (we do support keymap change but I don't think anyone expectes flip-flopping). OK. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. Good! Please, try to design the decoder as an independent module that gets data from a kfifo and generate scancodes for the input API. Hmmm. Let me see how the protoype turns out keeping that design objective in mind. I've already got the current RC-5 and NEC decoding state machines in cx23885-input a bit layered, but they are taking advantage of specific events signaled by my v4l2_subdev implementation. Strictly speaking the state machines don't have to. All of the remote protocols I have played with make framing pretty easy. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? IMO, the better is, by default, to open just one input device per IR receiver. From what I understand from our discussions, if the user wants to filter IR commands into several input interfaces, some userspace interface will be provided to allow the creation of other input interfaces for that purpose. Hmm. That's not what I just thought I read from Dmitry Oh well. If I don'y get it done by 24 Dec, it'll be in the new year. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. Applications expect to query device capabilities and expect them to stay somewhat stable (we do support keymap change but I don't think anyone expectes flip-flopping). OK. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DVB-Statistics API
Hi Julian,
Let me add some corrections to your technical analysis.
Julian Scheel wrote:
Hello together,
after the last thread which asked about signal statistics details
degenerated into a discussion about the technical possibilites for
implementing an entirely new API, which lead to nothing so far, I wanted
to open a new thread to bring this forward. Maybe some more people can
give their votes for the different options
Actually Manu did propose a new API for fetching enhanced statistics. It
uses new IOCTL to directly fetch the statistical data in one go from the
frontend. This propose was so far rejected by Mauro who wants to use the
S2API get/set calls instead.
Now to give everyone a quick overview about the advantages and
disadvantages of both approaches I will try to summarize it up:
1st approach: Introduce new IOCTL
Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
1. all values are fetched in one go (as long as possible) from the
frontend, so that they can be treated as one united and be valued in
conjunction
2. the requested values arrive the caller in an almost constant
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to
be kept alive as it is in use for a long time already. (unifying it's
data is not the approach of this new API)
Cons:
- Forces the application developers to interact with two APIs. The S2API
for tuning on the one hand and the Statistics API for reading signal
values on the other hand.
2nd approach: Set up S2API calls for reading statistics
Pros:
- Continous unification of the linuxtv API, allowing all calls to be
made through one API. - easy for application developers
- Scaling values can be retrieved/negotiated (if we implement the set
mode) before requesting the stats, using the same API;
- API can be easily extended to support other statistics that may be needed
by newer DTV standards.
Cons:
- Due to the key/value pairs used for S2API getters the statistical
values can't be read as a unique block, so we loose the guarantee, that
all of the values can be treatend as one unit expressing the signals
state at a concrete time.
You missed the point here. The proposal patch groups all S2API
pairs into a _single_ call into the driver:
+ for (i = 0; i tvps-num; i++)
+ need_get_ops += dtv_property_prepare_get_stats(fe,
+ tvp + i, inode, file);
+
+ if (!fe-dtv_property_cache.need_stats) {
+ need_get_ops++;
+ } else {
+ if (fe-ops.get_stats) {
+ err = fe-ops.get_stats(fe);
+ if (err 0)
+ return err;
+ }
+ }
The dtv_property_prepare_get_stats will generate a bitmap field (need_stats)
that
will describe all value pairs that userspace is expecting. After doing it,
a single call is done to get_stats() callback.
All the driver need to do is to fill all values at dtv_property_cache. If the
driver
fills more values than requested by the user, the extra values will simply be
discarded.
In order to reduce latency, the driver may opt to not read the register values
for the
data that aren't requested by the user, like I did on cx24123 driver.
Those values will all be returned at the same time to userspace by a single
copy_to_user()
operation.
- Due to the general architecture of the S2API the delay between
requesting and receiving the actual data could become too big to allow
realtime interpretation of the data (as it is needed for applications
like satellite finders, etc.)
Not true. As pointed at the previous answer, the difference between a new ioctl
and S2API is basically the code at dtv_property_prepare_get_stats() and
dtv_property_process_get(). This is a pure code that uses a continuous struct
that will likely be at L3 cache, inside the CPU chip. So, this code will run
really quickly.
As current CPU's runs at the order of Teraflops (as the CPU clocks are at
gigahertz
order, and CPU's can handle multiple instructions per clock cycle), the added
delay
is in de order of nanosseconds.
On the other hand, a simple read of a value from an i2c device is in the order
of milisseconds, since I2C serial bus, speed is slow (typically operating at
100 Kbps).
So, the delay is determined by the number of I2C calls you have at the code.
With the new ioctl proposal, as you need to read all data from I2C (even the
ones
that userspace don't need), you'll have two situations:
- if you use S2API call to request all data provided by ioctl approach,
the delay will be the same;
- if you use S2API call to request less stats, the S2API delay will
be shorter.
For example, with cx24123, the S2API delay it will be 6 times shorter than the
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. The address field on RC-5 protocol is not meant to distinguish different vendors, but different applications. It identifies that a code should be sent to a TV or a VCR, or a DVD or a SAT. In the case of bundled IR's, some vendors like Hauppauge opted to use a reserved address to avoid conflicts with other equipments. It happens that vendor's reserved address can be different between two different vendors, but is just an educated guess to say that an address equal to 0x1e is Hauppauge. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
Matthias Wächter wrote: Hallo Thomas! Am 02.12.2009 15:31, schrieb Thomas Kernen: Is someone already working on supporting the TBS 6980 Dual DVB-S2 PCIe card? http://www.tbsdtv.com/english/product/6980.html Have you seen/tried their all-in-one linux source package which was released 2009-12-03? http://www.tbsdtv.com/download/common/linux_tbs_all.rar – Matthias BTW: Where did you get yours? Hello Matthias, I've ordered a card directly from TBS. It's currently being shipped hence I won't be able to test it until at least next week. Then I'll see how it behaves in my system alongside all the other cards I have in it. Regards, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Where is the documentation for the protocol? I'm not sure what you're meaning here. I've started a doc about IR at the media What is the format of the pulse stream data coming out of the lirc device? AFAIK, it is at: http://www.lirc.org/html/index.html It would be nice to to add it to DocBook after integrating the API in kernel. The point of those design review questions was to illustrate that the existing LIRC system is only partially designed. Subsystems need to be fully designed before they get merged. For example 36-40K and 56K IR signals are both in use. It is a simple matter to design a receiver (or buy two receivers) that would support both these frequencies. But the current LIRC model only supports a single IR receiver. Adjusting it to support two receivers is going to break the ABI. My choice would be to just tell the person with the 56K remote to just buy a new 38K remote, but other people are against that choice. That forces us into designing a system that can handle multiple receivers. There is a parallel problem with baseband encoded IR signals. We need to think about all of these use cases before designing the ABI. Only after we think we have a good ABI design should code start being merged. Of course we may make mistakes and have to fix the ABI, but there is nothing to be gained by merging the existing ABI if we already know it has problems. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. s/all of the loaded maps/all of the loaded maps per device/ You may have more than one IR receiver on a given machine. IMO, we may have a mask filter matching also, associated with each keycode table, to minimize the keycode seek time. Something like: if (scancode scancode_mask) check_scancode() This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. There's nothing wrong on receiving a scancode that won't map. This can simply be an event that you don't want to handle (for example, an IR code sent to user's TV set). IMO, the better is to provide this scancode at KERN_DEBUG (if debug is enabled), and via an observer program. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. The address field on RC-5 protocol is not meant to distinguish different vendors, but different applications. It identifies that a code should be sent to a TV or a VCR, or a DVD or a SAT. In the case of bundled IR's, some vendors like Hauppauge opted to use a reserved address to avoid conflicts with other equipments. It happens that vendor's reserved address can be different between two different vendors, but is just an educated guess to say that an address equal to 0x1e is Hauppauge. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. This may be an option, but I think we should be able to attach protocol decoders in parallel, directly to the IRQ handler. At least with RC-5 (that's what I personally use) it means reliable decoding, no need for any timeouts, the code is clean, fast (can be a part of hard IRQ handler) and simple. The decoder needs something like rc5_signal_change(ptr, space_or_mark, microseconds). At least mark-space or space-mark events must be reported. For better reliability, both of them. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl jonsm...@gmail.com writes: Data could be sent to the in-kernel decoders first and then if they don't handle it, send it to user space. Nope. It should be sent to all of them, they aren't dependent. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov dmitry.torok...@gmail.com writes: Why woudl we want to do this? Quite often there is a need for observer that maybe does not act on data but allows capturing it. Single-user inetrfaces are PITA. Lircd can work as a multiplexer. IMHO single-open lirc interface is ok, though we obviously need simultaneous operation of in-kernel decoders. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. I agree. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: I don't think we need an userspace interface for the in-kernel decoders. Of course we need it, to set (and probably retrieve) scancode-keycode mappings. This could probably be, ATM, the existing input layer channel. All it needs is to enable/disable the protocol decoders, imo via sysfs interface. This isn't IMHO needed at all. The protocol is enabled when at least one key using it is configured, otherwise it's disabled. We probably need some wildcard as well, to capture decoded scancodes (through the input layer). This is BTW pure optimization, the protocol could stay enabled all the time, only wasting the cycles. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. s/all of the loaded maps/all of the loaded maps per device/ You may have more than one IR receiver on a given machine. IMO, we may have a mask filter matching also, associated with each keycode table, to minimize the keycode seek time. Something like: if (scancode scancode_mask) check_scancode() This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. There's nothing wrong on receiving a scancode that won't map. This can simply be an event that you don't want to handle (for example, an IR code sent to user's TV set). IMO, the better is to provide this scancode at KERN_DEBUG (if debug is enabled), and via an observer program. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: Yes, an opaque type for scancode at the userspace API can be better, but passing a pointer to kernel will require some compat32 logic (as pointer size is different on 32 and 64 bits). Yes. I think we can't avoid that, but it's a single compat handler, I wouldn't worry about it too much. We don't need it in every driver fortunately. We may use something like an u8[] with an arbitrary large number of bytes. Yes. All of this pointed to by the pointer. In this case, we need to take some care to avoid LSB/MSB troubles. Sure. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. This may be an option, but I think we should be able to attach protocol decoders in parallel, directly to the IRQ handler. At least with RC-5 (that's what I personally use) it means reliable decoding, no need for any timeouts, the code is clean, fast (can be a part of hard IRQ handler) and simple. The decoder needs something like rc5_signal_change(ptr, space_or_mark, microseconds). At least mark-space or space-mark events must be reported. For better reliability, both of them. If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. It also helps to have a decoder independent of the kernel driver. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: I don't think we need an userspace interface for the in-kernel decoders. Of course we need it, to set (and probably retrieve) scancode-keycode mappings. This could probably be, ATM, the existing input layer channel. This is the standard/extended evdev interface already discussed. All it needs is to enable/disable the protocol decoders, imo via sysfs interface. This isn't IMHO needed at all. The protocol is enabled when at least one key using it is configured, otherwise it's disabled. We probably need some wildcard as well, to capture decoded scancodes (through the input layer). This is BTW pure optimization, the protocol could stay enabled all the time, only wasting the cycles. The enable/disable protocol decoder enable/disable interface is needed anyway, due to the needs for the hardware IR decoders (and the legacy IR decoders, while we don't convert all of them to the generic ones). So, IMO, the interface will be cleaner if we use it also for the generic IR decoders. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: With RC-5, you have no fields describing the remote. So, all the driver could do is an educated guess. It can't even do that, e.g. single remotes (even the dumb ones) can send different code groups (addresses) for different keys. IMO, the better is to have an API to allow creation of multiple interfaces per IR receiver, based on some scancode matching table and/or on some matching mask. I think setting the keytables for each logical device would do. I.e. just have a way to create additional logical devices. Each can have its own keytable. The decoders would send their output to all logical remotes, trying to match the tables etc. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, That would mean unnecessary limiting. or to match address/command tuples on protocols where you just have those fields. Precisely. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Multi-function remotes combine multiple single function remotes into a single device. All universal remotes I have seen are multi-function. They usually combine three to five single function remotes. Yours is a two function remote TV and SAT. When you push TV and SAT you are changing which single function remote is being emulated. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Note that it is common for multfunction remotes to completely change IR protocol families when you switch which single function remote you are emulating. I have my universal set for a Sony TV , JVC DVD player and a Comcast STB. All three of those use different IR protocols. By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. However, I prefer a different scheme for splitting the signals apart. Load separate maps containing scancodes for each address. When the IR signals come in they are matched against the maps and a keycode is generated when a match is found. Now there is no need to distinguish between the remotes. It doesn't matter which remote generated the signal. scancode RC5/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. scancode RC5/7/1 - protocol, address, command tuplet. Map this to KP_1 on interface 2. Using the maps to split the commands out also fixes the problem with Sony remotes which use multiple protocols to control a single device. scancode Sony12/12/1 - protocol, address, command tuplet. Map this to power_on on interface 1. scancode Sony15/12/1 - protocol, address, command tuplet. Map this to KP_1 on interface 1. I agree. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: IMO, the better is to have an API to allow creation of multiple interfaces per IR receiver, based on some scancode matching table and/or on some matching mask. I think setting the keytables for each logical device would do. Yes. I.e. just have a way to create additional logical devices. Each can have its own keytable. The decoders would send their output to all logical remotes, trying to match the tables etc. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, That would mean unnecessary limiting. If the mask is (unsigned)-1, it will not add any limit. This should be the default. The advantage of the mask is that you can speedup the keycode decoding by not calling a seek routine in the cases where it doesn't make sense. Also, the cost of scancode scancode_mask is cheap enough, comparing with the potential optimization gain of not seeking a data in a table that wouldn't match anyway. Also, the IR core may automatically generate such mask, by doing an and operation of all the scancodes at the table during table initialization/changes. If the mask is zero, it defaults to use a (unsigned) -1 mask. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. If you want to change the default map loading a new map will release the memory from the previous map. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. No. This can be provided by an udev application that will load the keytable when the device is connected. Of course before adding it into a module, we'll need to write such app. This will only affects the need of IR during boot time. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. We can't use __init, since another device needing the keymap may be hot-plugged. If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. Yes, but it needs just one map, not all of them. The maps shouldn't be linked into the drivers, as the same map is used by several different devices on different drivers. So, the option is to allow customizing the available keymaps, if CONFIG_EMBEDDED. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. This may be an option, but I think we should be able to attach protocol decoders in parallel, directly to the IRQ handler. At least with RC-5 (that's what I personally use) it means reliable decoding, no need for any timeouts, the code is clean, fast (can be a part of hard IRQ handler) and simple. The decoder needs something like rc5_signal_change(ptr, space_or_mark, microseconds). At least mark-space or space-mark events must be reported. For better reliability, both of them. If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. It also helps to have a decoder independent of the kernel driver. The first version of my code ran the decoders from the IRQ. That wasn't a good model for sharing decoders between drivers. So I switched to using a kernel thread. There is also the problem of handing decoded events off up the chain. You can't do that from IRQ context. If I remember correctly the kernel thread would run approximately two times per IR message received. But sometimes it would only run once. It's a random function of the load on the system. The kernel thread empties the FIFO and sends the pulses in parallel to the decoders. Code for doing this is in the patches I posted. I wasn't aware of kfifo when I wrote them so I coded my own fifo. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Where is the documentation for the protocol? I'm not sure what you're meaning here. I've started a doc about IR at the media What is the format of the pulse stream data coming out of the lirc device? AFAIK, it is at: http://www.lirc.org/html/index.html It would be nice to to add it to DocBook after integrating the API in kernel. The point of those design review questions was to illustrate that the existing LIRC system is only partially designed. Ah, ok. Subsystems need to be fully designed before they get merged. True. For example 36-40K and 56K IR signals are both in use. It is a simple matter to design a receiver (or buy two receivers) that would support both these frequencies. But the current LIRC model only supports a single IR receiver. Adjusting it to support two receivers is going to break the ABI. My choice would be to just tell the person with the 56K remote to just buy a new 38K remote, but other people are against that choice. That forces us into designing a system that can handle multiple receivers. There is a parallel problem with baseband encoded IR signals. We need to think about all of these use cases before designing the ABI. Only after we think we have a good ABI design should code start being merged. Of course we may make mistakes and have to fix the ABI, but there is nothing to be gained by merging the existing ABI if we already know it has problems. I have here machines with 3 or 4 IR receivers (well, in a matter of fact, I don't use all of them at the same time). Nothing stops someone to use all IR receivers at the same. I've seen some interesting applications developed for students, where just one computer running Linux is splitted into 4 different consoles. Nothing stops that, on such usages, you may have 4 different IR transceivers working at the same time. In order to keep supporting the in-kernel drivers, we should create one lirc device per each IR transceiver. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: add another YUYV format GUID
On 04.12.2009 05:59, Justin P. Mattock wrote: On 12/03/09 18:05, Daniel Ritz wrote: Hi Laurent On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote: Hi Daniel, On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote: For some unknown reason, on a MacBookPro5,3 the iSight Could you please send me the output of lsusb -v both with the correct and wrong GUID ? sure. i attached three files: isight-good.txt, isight-bad.txt, isight-good2.txt this is three reboots in a row from like 10 minutes ago. the first boot into linux was actually rebooting from OSX...first cold boot today directly into linux had the right GUID. _sometimes_ report a different video format GUID. Sometimes only ? Now that's weird. Is that completely random ? yes, sometimes only. it seems to be related to reboots, but i don't know what exactly triggers it. rmmod/modprobe doesn't trigger it. also, when the wrong GUID is reported, the only way of fixing it is to reboot. it really is just the GUID. even when the wrong one is reported, the device works just fine. i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other things, just to see it fail again. a reboot later and it worked, some time and reboot later it failed again... rgds -daniel This patch add the other (wrong) GUID to the format table, making the iSight work always w/o other problems. What it should report: 32595559--0010-8000-00aa00389b71 What it often reports: 32595559--0010-8000-00389b71 Signed-off-by: Daniel Ritzdaniel.r...@gmx.ch -- Regards, Laurent Pinchart I get weiredness whenever I shutdown the machine and then boot. If I boot, then reboot things work. interesting...does my little patch work for you as well? thanks -daniel Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
On 2009-12-08 13:31, Thomas Kernen wrote: Matthias Wächter wrote: Hallo Thomas! Am 02.12.2009 15:31, schrieb Thomas Kernen: Is someone already working on supporting the TBS 6980 Dual DVB-S2 PCIe card? http://www.tbsdtv.com/english/product/6980.html I got one last Thursday, also direct from TBS. They provide a mini CD with their own V4L which has support for it included, together with versions of scan-s2 and szap-s2, but I'm a relative newbie and I've already managed to break my MythTV 0.22 setup trying to get it working. Any tips on how to get it working with Ubuntu 9.10 and kernel 2.6.31-16.52 would be very handy. With their V4L I can only get as far as a successful channel scan. Ian -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov dmitry.torok...@gmail.com writes: No, the IR core responsible for registering receivers and decoders. Well. This makes me think now that LIRC can be just another decoder. Those are simple things. The only part which needs to be stable is the (in this case LIRC) kernel-user interface. For which some questions are still open. I believe Jon just oulined some of them. Those are rather how does it work, not let's change something because it's not optimal. No we do not. We do not merge something that we expect to rework almost completely (no, not the lirc-style device userspace inetrface, although even it is not completely finalized I believe, but the rest of the subsystem). I don't think we need to rework it almost completely. Perhaps we need to change a hook here or there. No, not at all. You merge core subsystem code, then start addig decoders... You must have at least one common decoder merged with the core code, otherwise you don't know if the core is adequate. And you have to have at least one common input device. But perhaps it is a workable idea after all, given the another decoder. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: The enable/disable protocol decoder enable/disable interface is needed anyway, due to the needs for the hardware IR decoders Why do they need it exactly? The key tables say all they need I hope? -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab mche...@redhat.com writes: If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. But the decoding itself is a really simple thing, why complicate it? There is no need for the kernel thread if the handler is fast (and it is). Userspace is obviously different. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: The enable/disable protocol decoder enable/disable interface is needed anyway, due to the needs for the hardware IR decoders Why do they need it exactly? The key tables say all they need I hope? You can't upload a key for an unsupported protocol. Also, provided that hardware decoders in general don't support decoding multiple protocols at the same time, it is needed to select what protocol it will be decoding. So, userspace needs to: - retrieve the list of the supported protocols; - identify if a given IR is capable of multiple protocols; - be able to select what protocol(s) decoder(s) will be enabled. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. But the decoding itself is a really simple thing, why complicate it? There is no need for the kernel thread if the handler is fast (and it is). The decoding of just one protocol may be fast, but having several decoders serialized (without kthreads, you're serializing the decoders) will possibly not be that fast. Also, you don't need wake the decoders kthreads for every event, but wait for some number of events to happen before waking it. For example, 16 pulse/space events correspond to 8 bits of data on most protocols, so you can wake the kthread only after 16 events for really simple decoders, or if a timeout event is detected. The number of events to wake may be customized per decoder. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Universal remotes make it much easier to achieve just works. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The Bundled choice came from the map built into the IR receiver's device driver. The other two choices were loaded by the IR core after ensuring that the hardware could receive from a universal remote. The core would also load a couple of default radio profiles Univeral SonyDR112_RADIO Univeral OnkyoTX8255_RADIO Same for automation and mouse/keyboard emulation. Myth looks in sysfs and builds a menu containing DVR devices and all bundled entries. First app to open the Bundled device gets to keep it. These apps could take just works even farther. When they start up they could listen on all three evdev devices: Morotola_DVR, SciAtlanta_DVR, Bundled. And then if you find Myth responding to unwanted commands you could disable the unwanted profiles by deselecting them in the Myth
Re: [PATCH] Add support for Zolid Hybrid PCI card
I accidently sent this mail to Michael's private address, I'm sorry for that. Hi, I bought the same card a couple of months ago and back then, it just wouldn't work. I set up a wiki page, which henk has updated with links to patches, to document the card as well as possible. I set up a thread on this mailing list (http://osdir.com/ml/video4linux-list/2009-05/msg00102.html) on making the card work, but that resulted to nothing. I was surprised to find this thread when I accidently searched for Zolid in my mailbox. I'm at my internship at the moment, but I'll try this patch as soon as I get home :) If you need the card for further development/testing: I'm willing to send it to you by mail. I just want it back when you're done testing, so I can finally watch tv on my computer :) Greetings, Sander Pientka 2009/9/14 Michael Krufky mkru...@kernellabs.com: On Wed, Sep 9, 2009 at 11:08 AM, Michael Krufky mkru...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 10:01 AM, s...@systol-ng.god.lan wrote: On Tue, Sep 08, 2009 at 05:57:12PM -0400, Michael Krufky wrote: Henk, Why do you expect a 8295? If your board uses the SAA7131, then we would expect an 8290 IF demod. Ah, I just checked the history of this email thread -- I must have read one of your previous emails too quickly. :-) Perhaps there is a typo in the document that you read -- tda8290 is correct. Just to come back to this point, Well zolid has a SAA7131E, if you look at the datasheet (botom of page 15) http://www.nxp.com/acrobat_download/datasheets/SAA7131E_3.pdf it says: The SAA7131E is functionally compatible with the SAA7135 audio and video broadcast decoder device and the stand-alone low-IF device TDA8295. So thats why I asked. Regards, Henk FIX YOUR MAILER!! It's a pain to reply to your emails -- I have to insert your actual email address each time :-( Anyway, I am under the impression that it's a typo in the datasheet. It is actually a tda8290. Henk, Just FYI, I merged your patch to my saa7134 repository last week: http://www.kernellabs.com/hg/~mkrufky/saa7134 I thought that I had replied to you already but that message seems to have gotten dropped somewhere :-/ I intend to send a pull request to Mauro for this, in addition to some other pending patches after he merges what I have already pending. Thanks again for your work. Regards, Mike Krufky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 9:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:16 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. No, please. We currently have already 89 different keymaps in-kernel. Creating 89 different interfaces per IR receiver is not useful at all. IMO, the interfaces should be created as the keymaps are associated to an specific IR receiver. Each IR receiver device driver would have a built-in keymap for the remote bundled with it. When you load the driver it will poke the input system and install the map. Any additional keymaps would get loaded from user space. You would load one keymap per input device. You might have 89 maps in the kernel with each map being built into the device driver for those 89 IR receivers. But you'll only own one or two of those devices so only one or two of the 89 maps will load. Building the map for the bundled receiver into the device driver is an important part of achieving just works. I suspect we'll have a 1,000 maps defined after ten years, most of these maps will be loaded from user space. But you'll only have two or three loaded at any one time into your kernel. You need one map per input device created. These maps are tiny, less than 1KB. Having all of these maps is the price of allowing everyone to use any more that they please. If you force the use of universal remotes most of the maps can be eliminated. Makes sense. Yet, I would add an option at Kbuild to create a module or not with the bundled IR keymaps. So, it should be possible to have all of them completely on userspace or having them at kernelspace. Removing the maps for the bundled remotes from the receiver device drivers will break just works. No. This can be provided by an udev application that will load the keytable when the device is connected. Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. The purpose of putting this table into __init is to get rid of all these udev scripts in the default case. Of course before adding it into a module, we'll need to write such app. This will only affects the need of IR during boot time. The map will be in an __init section of the IR device driver. When it is fed into the input system a RAM based structure will be created. We can't use __init, since another device needing the keymap may be hot-plugged. You can handle that with __devinit If you really want the 1KB memory back, use sysfs to remove the default map. An embedded system will have a bundled remote so it is going to want the map. Yes, but it needs just one map, not all of them. The maps shouldn't be linked into the drivers, as the same map is used by several different devices on Link them or #include them, it doesn't make any difference. different drivers. So, the option is to allow customizing the available keymaps, if CONFIG_EMBEDDED. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Jon Smirl wrote: This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? This case feels similar to that of Caps Lock, Num Lock and Scrool Lock, but I don't know if that scheme could be applied here. -- Regards, Feri. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 8, 2009 at 10:49 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. But the decoding itself is a really simple thing, why complicate it? There is no need for the kernel thread if the handler is fast (and it is). The decoding of just one protocol may be fast, but having several decoders serialized (without kthreads, you're serializing the decoders) will possibly not be that fast. Also, you don't need wake the decoders kthreads for every event, but wait Just wake the default kthread on each event. If you wake the default thread multiple times it is the same as waking it once. The default kthread doesn't schedule very fast. If you get 120 events and call wake 120 times, the thread is only going to visit your driver one or two times not 120 times. for some number of events to happen before waking it. For example, 16 pulse/space events correspond to 8 bits of data on most protocols, so you can wake the kthread only after 16 events for really simple decoders, or if a timeout event is detected. The number of events to wake may be customized per decoder. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. It shouldn't be hard to do it in kernelspace, since you'll need to have one evdev interface associated with the IR anyway, but this will add some extra complexity at the scancode-keycode conversion, but I'm wandering if we should do it or not. Maybe the better is to not do it in kernelspace, to avoid adding there an extra complexity that can easily be done in userspace. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Ok, but using the shipped IR even without a separate address group for different applications, and having it controlling radio app and tv app (not simultaneously) should not be hard, but I LIRC already covers such usecase, so maybe we don't need to worry about it. Universal remotes make it much easier to achieve just works. True. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The Bundled choice came from the map built into the IR receiver's device driver. The other two choices
Re: soc_camera: OV2640
Hi Guennadi, On 12/7/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Alan On Mon, 7 Dec 2009, Alan Carvalho de Assis wrote: It's always better to cc a suitable list, in this case it is Linux Media Mailing List linux-media@vger.kernel.org Sure, here we go. I am trying to use an OV2640 camera with soc_camera. I'm using ov772x driver as base, but it needs too much modification to work with ov2640. I don't know that sensor specifically, but they can be quite different. Yes, in fact ov2640 appears quite different compared to ov772x and ov9640. The OV2640 chip remaps all registers when register 0xFF is 1 or when it is 0. This is not unusual. There are a few ways to implement this, for example, drivers/media/video/rj54n1cb0c.c uses 16-bit addresses, and decodes them to bank:register pairs in its reg_read() and reg_write() routines. Ok, I will try to implement it this way, case nobody suggests me a better approach. Best Regards, Alan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 08, 2009 at 09:44:29AM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: On Nov 26, 2009, at 2:43 PM, Andy Walls wrote: On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Andy Walls awa...@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. ... 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. So I had one of the people who does all the license and patent audits for Fedora packages look at the Philips patent on RC-6. He's 100% positive that the patent *only* covers hardware, there should be no problem whatsoever writing a software decoder for RC-6. OK. Thanks for having some professionals take a look. (I'm assuming that's the only patent.) So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. Applications expect to query device capabilities and expect them to stay somewhat stable (we do support keymap change but I don't think anyone expectes flip-flopping). With RC-5, you have no fields describing the remote. So, all the driver could do is an educated guess. From a quick look I did at the RC-6 Mode 6A docs I found, I suspect that you can distinguish two different remotes when someone press a key there. However, I don't think it is a good idea to automatically create a new interface every time a different vendor is detected. Maybe the user simply have a RC-6 IR to control his TV and doesn't have any intention on using that device on his computer. IMO, the better is to have an API to allow creation of multiple interfaces per IR receiver, based on some scancode matching table and/or on some matching mask. It should be possible to use the filter API to match different IR's by vendor/product on protocols that supports it, or to match address/command tuples
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 08, 2009 at 07:52:02AM -0500, Jon Smirl wrote: On Tue, Dec 8, 2009 at 7:35 AM, Andy Walls awa...@radix.net wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) Like I said, I think the preferred way is to represent every remote that can be distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. I agree that creating devices on the fly has problems. Another solution is to create one device for each map that is loaded. There would be a couple built-in maps for bundled remotes - each would create a device. Then the user could load more maps with each map creating a device. Incoming scancodes are matched against all of the loaded maps and a keycode event is generated if a match occurs. How many sancodes do we need to reliably recognize the device though? I am not sure users would want to press 5 random buttons in order to start using the remote, unless it happens exactly once and then we manage to store the data somewhere. This illustrates why there should an EV_IR event which communicates scancodes, without this event you can't see the scancodes that don't match a map entry. A scancode would be first matched against the map, then if there as no match an EV_IR event would be reported. Just report MSC_SCAN always. As I said elsewhere we can extend it to be multi-dword if needed (just need to agree on endianness). -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: What about capabilities of the receiver, what frequencies? If a receiver has multiple frequencies, how do you report what frequency the data came in on? IMO, via sysfs. We probably need to think what exactly we report through sysfs siunce it is ABI of sorts. Yes, sure. Probably, the exact needs will popup only when we start to actually writing that part of the core. My intention for now is to just create a /sys/class/irrcv, with one node per each IR receiver and adding a protocol enumeration/selection node there, and add some capabilities for the in-kernel decoders and lirc_dev to create new nodes under that class. When the decoders/lirc_dev patches popup, we'll need to review those sysfs API's. What about multiple apps simultaneously using the pulse data? IMO, the better is to limit the raw interface to just one open. Why woudl we want to do this? Quite often there is a need for observer that maybe does not act on data but allows capturing it. Single-user inetrfaces are PITA. That should work fine as well, but I'm not sure how we'll detect overrun with several kfifo readers. Push the data into readers so they can do te decoding at their own pace. Some can do it in interrupt context, some will need workqueue/thread. They can also regilate the depth of the buffer, according to their needs. How big is the receive queue? It should be big enough to receive at least one keycode event. Considering that the driver will use kfifo (IMO, it is a good strategy, especially since you won't need any lock if just one open is allowed), it will require a power of two size. Would not it be wither driver- or protocol-specific? Probably. How does access work, root only or any user? IMO, it should be the same requirement as used by an input interface. How are capabilities exposed, sysfs, etc? IMO, sysfs. What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. I think Jon meant userspace interface for attaching particular decoder. I don't think we need an userspace interface for the in-kernel decoders. All it needs is to enable/disable the protocol decoders, imo via sysfs interface. If there is an in-kernel decoder should the pulse data stop being reported, partially stopped, something else? I don't have a strong opinion here, but, from the previous discussions, it seems that people want it to be double-reported by default. If so, I think we need to implement a command at the raw interface to allow disabling the in-kernel decoder, while the raw interface is kept open. Why don't you simply let consumers decide where they will get their data? How? You end up with N evdev devices. Let application (MythTV) say I want to use /dev/input/event1 (well, it will need persistent udev rule, but that's a detail). Another application will chose another event node. User can decide she'd rather use lircd - and so configire applications to use event5. Any maybe turned off the in-kernel decoders if they are of no use and there is a concern that they consume too mcuh resoures. Won't this work? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 08, 2009 at 09:17:42AM -0200, Mauro Carvalho Chehab wrote: Jon Smirl wrote: On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Where is the documentation for the protocol? I'm not sure what you're meaning here. I've started a doc about IR at the media What is the format of the pulse stream data coming out of the lirc device? AFAIK, it is at: http://www.lirc.org/html/index.html It would be nice to to add it to DocBook after integrating the API in kernel. docbook. This is currently inside the kernel Documents/DocBook. If you want to browse, it is also available as: http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html For sure we need to better document the IR's, and explain the API's there. Is it a device interface or something else? lirc_dev should create a device interface. What about capabilities of the receiver, what frequencies? If a receiver has multiple frequencies, how do you report what frequency the data came in on? IMO, via sysfs. Say you have a hardware device with two IR diodes, one at 38K and one at 56K. Both of these receivers can get pulses. How do we tell the user space app which frequency the pulses were received on? Seems to me like there has to be a header on the pulse data indicating the received carrier frequency. There is also baseband signaling. sysfs won't work for this because of the queuing latency. Simply create two interfaces. One for each IR receiver. At sysfs, you'll have /sys/class/irrcv/irrcv0 for the first one and /sys/class/irrcv/irrcv1. Yes, please. Distinct hardware - distinct representation in the kernel. This is the most sane way. ... What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. Probably we should do what input layer does - the data is pushed into all handlers that are signed up for it and they can deal with it at their leisure. If there is an in-kernel decoder should the pulse data stop being reported, partially stopped, something else? I don't have a strong opinion here, but, from the previous discussions, it seems that people want it to be double-reported by default. If so, I think we need to implement a command at the raw interface to allow disabling the in-kernel decoder, while the raw interface is kept open. Data could be sent to the in-kernel decoders first and then if they don't handle it, send it to user space. You do not know what userspace wants to do with the data. They may want to simply observe it, store or do something else. Since we do provide interface for such raw[ish] data we just need to transmit it to userpsace as long as there are users (i.e. interface is open). Hmm... like adding a delay if the raw userspace is open and, if the raw userspace doesn't read all pulse data, it will send via in-kernel decoder instead? This can work, but I'm not sure if this is the better way, and will require some logic to synchronize lirc_dev and IR core modules. Also, doing it key by key will introduce some delay. If you're afraid of having the userspace app hanged and having no IR output, it would be simpler to just close the raw interface if an available data won't be read after a bigger timeout (3 seconds? 5 seconds?). We can not foresee all use cases. Just let all parties signed up for the data get and process it, do not burden the core with heuristics. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 08, 2009 at 07:46:52AM -0500, Andy Walls wrote: On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. Good! Please, try to design the decoder as an independent module that gets data from a kfifo and generate scancodes for the input API. Hmmm. Let me see how the protoype turns out keeping that design objective in mind. I've already got the current RC-5 and NEC decoding state machines in cx23885-input a bit layered, but they are taking advantage of specific events signaled by my v4l2_subdev implementation. Strictly speaking the state machines don't have to. All of the remote protocols I have played with make framing pretty easy. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? IMO, the better is, by default, to open just one input device per IR receiver. From what I understand from our discussions, if the user wants to filter IR commands into several input interfaces, some userspace interface will be provided to allow the creation of other input interfaces for that purpose. Hmm. That's not what I just thought I read from Dmitry I am a resonable guy ;) In cases when we can certainly say that there are 2 separate remotes (and we know characteristics somehow) we need to create 2 input devices. Otherwise we can't ;) -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: Why woudl we want to do this? Quite often there is a need for observer that maybe does not act on data but allows capturing it. Single-user inetrfaces are PITA. Lircd can work as a multiplexer. What this has to do with my statement? Did you mean retransmitter of sorts? Also I may explicitely not want the data stream to be multiplexed... IMHO single-open lirc interface is ok, though we obviously need simultaneous operation of in-kernel decoders. Why is the distinction? -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan
Sent: Thursday, December 03, 2009 9:25 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org;
hverk...@xs4all.nl; khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Subject: RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks
configurable
I was talking to Sekhar about this and actually he made some good
points
about this implementation.
If we consider specific IP, then the required clocks would remain
always be
the same. There might be some devices which may not be using some
clocks
(so as that specific feature).
Actually we are trying to create one more wrapper for clock
configuration.
Just to illustrate I am putting some other generic drivers examples
-
Omap-hsmmc.c -
This driver requires 2 clocks, interface and functional. The
devices which
would be using this driver have to define clock with names ick
and fck.
VPFE-Capture (Considering only current implementation) -
Currently we have vpfe_capture.c file (master/bridge driver) which
is
handling clk_get/put, and platform data is providing the details
about it.
Ideally we should handle it in respective ccdc driver file, since
he has
all the knowledge about required number of clocks and its name.
This way we
don't have to maintain/pass clock information in platform data.
I would appreciate any comments/thoughts/pointers here.
Though I agree that this clock could be set by the ccdc driver, I am
not sure if the same clock is used by an IP on different SOCs. For
example take
the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do
they use
vpss master and slave clocks as is done on DM6446? If this is true,
then we
could set the clock inside ccdc driver.
Let me know so that I can re-work the patch and send it to the list.
[Hiremath, Vaibhav] Murali,
They might be using different naming conventions but the number of clocks will
always remain the same. If not, then they are not same IP and most probably
will not use same driver.
Just to clarify more on your Q, AM3517 also uses 2 clocks
- vpfe_ck (functional clock)
- vpfe_pck (external clock, pixel clock)
Whereas you are referring them as master and slave clock.
Thanks,
Vaibhav
Murali
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata
= {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] WinTV HVR-900 USB (B3C0)
On Tue, Dec 8, 2009 at 12:35 PM, Rob Beard r...@esdelle.co.uk wrote: Hi folks, I've borrowed a WinTV HVR-900 USB stick from a friend of mine to see if I can get any reception in my area before forking out for one however I've run in to a couple of problems and wondered if anyone had used one of these sticks? The device appears to support both analogue and DVB-T (Freeview) TV however when I plug the device in it only appears to enable the analogue side of things (it comes up as /dev/video1 as I have a webcam on my laptop). I've downloaded and installed the firmware in /lib/firmware as per the instructions on the LinuxDVB web site and it appears to pick it up and I've even tried compiling the v4l-dvb drivers too which didn't appear to make any difference. Just to check it wasn't me going mad, I tried the dvb-utils scan utility and also Kaffene, both of which doesn't work (and I can't find a /dev/dvb directory either). If it helps, the output from /var/log/messages is here: http://pastebin.com/m34f1048f I just wondered if anyone else had one of these sticks actually working under Ubuntu 9.10? (I'm running kernel 2.6.31-16-generic-pae). The DVB-T portion of that particular board is unsupported (I have some code in the works but there are issues with the firmware redistribution rights). Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Tue, Dec 8, 2009 at 11:27 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 9:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:59 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Tue, Dec 8, 2009 at 8:30 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Andy Walls wrote: On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the end of the month. I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with a common set of parameters, so I may be able to set up the decoders to handle decoding from two different remote types at once. The HVR boards can ship with either type of remote AFAIK. I wonder if I can flip the keytables on the fly or if I have to create two different input devices? Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. RC-5 and RC-6 both contain an address field. My opinion is that different addresses represent different devices and in general they should appear on an input devices per address. The same IR can produce two different addresses. The IR bundled with my satellite STB produces two different codes, depending if you previously pressed TV or SAT key (in fact, I think it can even produce different protocols for TV, as it can be configured to work with different TV sets). You have a multi-function remote. Yes. That's why those keys don't send codes. When writing code you should think of this remote as being two indpendent virtual remotes, not a single one. Not really. I may think on it as a single device and use the two groups of functions to control two aspects at the same application. For example, I may map the TV group on kaffeine for DVB reception and the SAT group for DVD (well, probably, in this case, I'll use an IR with TV and DVD keys, instead ;) ). By using maps containing the two different addresses for TV and SAT you can split these commands onto two different evdev devices. True. I can do it, but I can opt to have both mapped as one evdev device as well. This will basically depend on how I want to mount my environment. This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. It is very common to have such remotes bundled with multimedia devices. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? Splitting them into multiple devices requires remembering state and scripting so it needs to be done in user space. It shouldn't be hard to do it in kernelspace, since you'll need to have one evdev interface associated with the IR anyway, but this will add some extra complexity at the scancode-keycode conversion, but I'm wandering if we should do it or not. Maybe the better is to not do it in kernelspace, to avoid adding there an extra complexity that can easily be done in userspace. If the user wants to control a radio app and a home automation app they need to choose. Keep the bundled remote and do some non-trivial scripting or buy a universal remote. Ok, but using the shipped IR even without a separate address group for different applications, and having it controlling radio app and tv app (not simultaneously) should not be hard, but I LIRC already covers such usecase, so maybe we don't need to worry about it. Universal remotes make it much easier to achieve just works. True. The IR core can contain default universal profiles for various classes of devices. Say Morotola_DVR and SciAtlanta_DVR. The core would check if the receiver is cable of receiving these profiles before loading them. There would be ten of these default universal profiles at most and you can unload them from RAM if they aren't needed. Now Myth can have a menu with three remote choices: Universal Morotola_DVR Universal SciAtlanta_DVR Bundled The
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Dec 8 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13588:065f9e34e07b gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v0 2/2] DaVinci - vpfe capture - Make clocks configurable
Vaibhav,
I have posted a re-worked patch with clocks configuration moved
to ccdc. From your response below, I understand the clocks
are being called differently on different SoCs even though they
use the same IP. So IMO, it is better to customize it on a SoC
by defining the clock names in the respective platform file as
done by my original patch. This will avoid confusion since we need to
keep the name in sync with hardware signal names.
-Murali
[Hiremath, Vaibhav] Murali,
They might be using different naming conventions but the number of clocks
will always remain the same. If not, then they are not same IP and most
probably will not use same driver.
Just to clarify more on your Q, AM3517 also uses 2 clocks
- vpfe_ck (functional clock)
- vpfe_pck (external clock, pixel clock)
Whereas you are referring them as master and slave clock.
Thanks,
Vaibhav
Murali
Thanks,
Vaibhav
};
static struct platform_device *davinci_evm_devices[] __initdata
= {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index fd0398b..45beb99 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
+ .num_clocks = 2,
+ .clocks = {vpss_master, vpss_slave},
};
static struct platform_device rtc_dev = {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-
media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for Zolid Hybrid PCI card
2009/9/14 Michael Krufky mkru...@kernellabs.com: On Wed, Sep 9, 2009 at 11:08 AM, Michael Krufky mkru...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 10:01 AM, s...@systol-ng.god.lan wrote: On Tue, Sep 08, 2009 at 05:57:12PM -0400, Michael Krufky wrote: Henk, Why do you expect a 8295? If your board uses the SAA7131, then we would expect an 8290 IF demod. Ah, I just checked the history of this email thread -- I must have read one of your previous emails too quickly. :-) Perhaps there is a typo in the document that you read -- tda8290 is correct. Just to come back to this point, Well zolid has a SAA7131E, if you look at the datasheet (botom of page 15) http://www.nxp.com/acrobat_download/datasheets/SAA7131E_3.pdf it says: The SAA7131E is functionally compatible with the SAA7135 audio and video broadcast decoder device and the stand-alone low-IF device TDA8295. So thats why I asked. Regards, Henk FIX YOUR MAILER!! It's a pain to reply to your emails -- I have to insert your actual email address each time :-( Anyway, I am under the impression that it's a typo in the datasheet. It is actually a tda8290. Henk, Just FYI, I merged your patch to my saa7134 repository last week: http://www.kernellabs.com/hg/~mkrufky/saa7134 I thought that I had replied to you already but that message seems to have gotten dropped somewhere :-/ I intend to send a pull request to Mauro for this, in addition to some other pending patches after he merges what I have already pending. Thanks again for your work. Regards, Mike Krufky On Tue, Dec 8, 2009 at 11:10 AM, Sander Pientka cumulus0...@gmail.com wrote: I accidently sent this mail to Michael's private address, I'm sorry for that. Hi, I bought the same card a couple of months ago and back then, it just wouldn't work. I set up a wiki page, which henk has updated with links to patches, to document the card as well as possible. I set up a thread on this mailing list (http://osdir.com/ml/video4linux-list/2009-05/msg00102.html) on making the card work, but that resulted to nothing. I was surprised to find this thread when I accidently searched for Zolid in my mailbox. I'm at my internship at the moment, but I'll try this patch as soon as I get home :) If you need the card for further development/testing: I'm willing to send it to you by mail. I just want it back when you're done testing, so I can finally watch tv on my computer :) Greetings, Sander Pientka Please do not top-quote. The policy on this mailing list is to include the reply BELOW the quoted text. Anyway, don't even bother testing any patch -- just use the latest v4l-dvb tree -- the code is all merged up. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH - v1] V4L-Fix videobuf_dma_contig_user_get() for non-aligned offsets
From: Muralidharan Karicheri m-kariche...@ti.com If a USERPTR address that is not aligned to page boundary is passed to the videobuf_dma_contig_user_get() function, it saves a page aligned address to the dma_handle. This is not correct. This issue is observed when using USERPTR IO machism for buffer exchange. Updates from last version:- Adding offset for size calculation as per comment from Magnus Damm. This ensures the last page is also included for checking if memory is contiguous. Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- drivers/media/video/videobuf-dma-contig.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/videobuf-dma-contig.c b/drivers/media/video/videobuf-dma-contig.c index d25f284..22c0109 100644 --- a/drivers/media/video/videobuf-dma-contig.c +++ b/drivers/media/video/videobuf-dma-contig.c @@ -141,9 +141,11 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, struct vm_area_struct *vma; unsigned long prev_pfn, this_pfn; unsigned long pages_done, user_address; + unsigned int offset; int ret; - mem-size = PAGE_ALIGN(vb-size); + offset = vb-baddr ~PAGE_MASK; + mem-size = PAGE_ALIGN(vb-size + offset); mem-is_userptr = 0; ret = -EINVAL; @@ -166,7 +168,7 @@ static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory *mem, break; if (pages_done == 0) - mem-dma_handle = this_pfn PAGE_SHIFT; + mem-dma_handle = (this_pfn PAGE_SHIFT) + offset; else if (this_pfn != (prev_pfn + 1)) ret = -EFAULT; -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DVB-Statistics API
On Tue, Dec 8, 2009 at 5:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Hi Julian,
Let me add some corrections to your technical analysis.
Julian Scheel wrote:
Hello together,
after the last thread which asked about signal statistics details
degenerated into a discussion about the technical possibilites for
implementing an entirely new API, which lead to nothing so far, I wanted
to open a new thread to bring this forward. Maybe some more people can
give their votes for the different options
Actually Manu did propose a new API for fetching enhanced statistics. It
uses new IOCTL to directly fetch the statistical data in one go from the
frontend. This propose was so far rejected by Mauro who wants to use the
S2API get/set calls instead.
Now to give everyone a quick overview about the advantages and
disadvantages of both approaches I will try to summarize it up:
1st approach: Introduce new IOCTL
Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
1. all values are fetched in one go (as long as possible) from the
frontend, so that they can be treated as one united and be valued in
conjunction
2. the requested values arrive the caller in an almost constant
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to
be kept alive as it is in use for a long time already. (unifying it's
data is not the approach of this new API)
Cons:
- Forces the application developers to interact with two APIs. The S2API
for tuning on the one hand and the Statistics API for reading signal
values on the other hand.
2nd approach: Set up S2API calls for reading statistics
Pros:
- Continous unification of the linuxtv API, allowing all calls to be
made through one API. - easy for application developers
- Scaling values can be retrieved/negotiated (if we implement the set
mode) before requesting the stats, using the same API;
- API can be easily extended to support other statistics that may be needed
by newer DTV standards.
Cons:
- Due to the key/value pairs used for S2API getters the statistical
values can't be read as a unique block, so we loose the guarantee, that
all of the values can be treatend as one unit expressing the signals
state at a concrete time.
You missed the point here. The proposal patch groups all S2API
pairs into a _single_ call into the driver:
+ for (i = 0; i tvps-num; i++)
+ need_get_ops += dtv_property_prepare_get_stats(fe,
+ tvp + i, inode, file);
+
+ if (!fe-dtv_property_cache.need_stats) {
+ need_get_ops++;
+ } else {
+ if (fe-ops.get_stats) {
+ err = fe-ops.get_stats(fe);
+ if (err 0)
+ return err;
+ }
+ }
The dtv_property_prepare_get_stats will generate a bitmap field (need_stats)
that
will describe all value pairs that userspace is expecting. After doing it,
a single call is done to get_stats() callback.
All the driver need to do is to fill all values at dtv_property_cache. If the
driver
fills more values than requested by the user, the extra values will simply be
discarded.
In order to reduce latency, the driver may opt to not read the register
values for the
data that aren't requested by the user, like I did on cx24123 driver.
Those values will all be returned at the same time to userspace by a single
copy_to_user()
operation.
- Due to the general architecture of the S2API the delay between
requesting and receiving the actual data could become too big to allow
realtime interpretation of the data (as it is needed for applications
like satellite finders, etc.)
Not true. As pointed at the previous answer, the difference between a new
ioctl
and S2API is basically the code at dtv_property_prepare_get_stats() and
dtv_property_process_get(). This is a pure code that uses a continuous struct
that will likely be at L3 cache, inside the CPU chip. So, this code will run
really quickly.
AFAIK, cache eviction occurs with syscalls: where content in the
caches near the CPU cores is pushed to the outer cores, resulting in
cache misses. Not all CPU's are equipped with L3 caches. Continuous
syscalls can result in TLB cache misses from what i understand, which
is expensive.
These are the numbers Intel lists for a Pentium M:
To Cycles
Register= 1
L1d ~3
L2 ~14
Main Memory ~240
As current CPU's runs at the order of Teraflops (as the CPU clocks are at
gigahertz
order, and CPU's can handle multiple instructions per clock cycle), the added
delay
is in de order of nanosseconds.
Consider STB's where DVB is generally deployed rather than the small
segment of home users running a stack on
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Dmitry, on 06 Dec 09 at 23:51, Dmitry Torokhov wrote: [...] I suppose we could add MSC_SCAN_END event so that we can transmit scancodes of arbitrary length. You'd get several MSC_SCAN followed by MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 bit. And I set a timeout to know that no MSC_SCAN_END will arrive? This is broken design IMHO. EV_SYN signals the end of state transmission. Furthermore lircd needs to know the length of the scan code in bits, not as a multiple of 32. I really do not think that LIRCD is the type of application that should be using evdev interface, but rather other way around. Well, all I'm asking is that lircd can keep using the LIRC interface for getting the scan codes. ;-) Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Jon, on 08 Dec 09 at 08:34, Jon Smirl wrote: [...] The point of those design review questions was to illustrate that the existing LIRC system is only partially designed. Subsystems need to be fully designed before they get merged. I'd say that a system that has proven itself in real world applications for 10 years, does not deserve to be called partially designed. For example 36-40K and 56K IR signals are both in use. It is a simple matter to design a receiver (or buy two receivers) that would support both these frequencies. But the current LIRC model only supports a single IR receiver. Adjusting it to support two receivers is going to break the ABI. Really? When we added support for multiple transmitters, we somehow managed to do without breaking the ABI. Do I miss something? Your example could even now be solved by using the LIRC_SET_REC_CARRIER ioctl. The driver would have to choose the receiver that best fits the requested frequency. [...] We need to think about all of these use cases before designing the ABI. Only after we think we have a good ABI design should code start being merged. Of course we may make mistakes and have to fix the ABI, but there is nothing to be gained by merging the existing ABI if we already know it has problems. The point is that we did not get up this morning and started to think about how the LIRC interface should look like. That happened 10 years ago. I'm not saying that the interface is the nicest thing ever invented, but it works and is extendable. If you see that something is missing please bring it up. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Andy, on 07 Dec 09 at 23:10, Andy Walls wrote: [...] (Christoph can correct me if I get anything wrong.) Just a few additions. [...] What is the time standard for the data, where does it come from? I think it is usec, IIRC. Yes, it is. I know that the hardware I work with has sub 100 ns resolution, Highest IR carrier frequency I know is 500kHz. usec resolution is enough even for raw modulated IR pulses. But you only look at the signal after it has been demodulated by the IR chip, so higher resolution would be overkill. [...] How do you define the start and stop of sequences? For the end of Rx signalling: Well with the Conexant hardware I can set a maximum pulse (mark or space) width, and the hardware will generate an Rx Timeout interrupt to signal the end of Rx when a space ends up longer than that max pulse width. The hardware also puts a special marker in the hardware pulse widht measurement FIFO (in band signalling essentially). I'm not sure anything like that gets communicated to userspace via lirc_dev, and I'm too tired to doublecheck right now. There is no such thing in the protocol. Some devices cannot provide any end of signal marker, so lircd handles this using timers. If there is some interest, the MODE2 protocol can be extended. We still have 7 bits unused... If you have determined the protocol you are after, it's easy to know what the pulse count should be and what the max pulse width should be (+ slop for crappy hardware) so finding the end of an Rx isn't hard. The button repeats intervals are *very* large. I've never seen a remote rapid fire codes back to back. I did. There are some protocols that have a gap of only 6000 us between signals. And the settop boxes are very picky about this. If you make it too long, they won't accept the command. [...] Is transmitting synchronous or queued? kfifo's IIRC. No, it's synchronous. How big is the transmit queue? No queue. [...] My particular gripes about the current LIRC interface: 1. The one thing that I wish were documented better were the distinction between LIRC_MODE_PULSE, LIRC_MODE_RAW, and LIRC_MODE2 modes of operation. I think I've figured it out, but I had to look at a lot of LIRC drivers to do so. No driver uses RAW until now and lircd does not support it. PULSE is used on the transmit path, MODE2 on the receive path. There is no special reasoning for that, it's rather historic. MODE2 makes sense on the receive path because you can easily distinguish between pulse/space. 2. I have hardware where I can set max_pulse_width so I can optimize pulse timer resolution and have the hardware time out rapidly on end of RX. I also have hardware where I can set a min_pulse_width to set a hardware low-pass/glitch filter. Currently LIRC doesn't have any way to set these, but it would be nice to have. Should be really easy to add these. The actual values could be derived from the config files easily. In band signalling of a hardware detected end of Rx may also make sense then too. See above. 3. As I mentioned before, it would be nice if LIRC could set a batch of parameters atomically somehow, instead of with a series of ioctl()s. I can work around this in kernel though. Is there any particular sequence that you are concerned about? Setting carrier frequency and then duty cycle is a bit problematic. Currently it's solved by resetting the duty cycle to 50% each time you change the carrier frequency. But as the LIRC interface is one user only, I don't see a real problem. Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl jonsm...@gmail.com writes: Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. Of course no. We will need a single program (script etc.) for all devices. And we will need a database of the known remotes (scan and key codes). You can handle that with __devinit __devinit is NOP with hot-plug. Fortunately we don't need the keymaps in the kernel. For certain uses we may (and may not) need to have one keymap built-in, perhaps something similar to the embedded initrd. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DVB-Statistics API
Manu Abraham wrote:
Not true. As pointed at the previous answer, the difference between a new
ioctl
and S2API is basically the code at dtv_property_prepare_get_stats() and
dtv_property_process_get(). This is a pure code that uses a continuous struct
that will likely be at L3 cache, inside the CPU chip. So, this code will run
really quickly.
AFAIK, cache eviction occurs with syscalls: where content in the
caches near the CPU cores is pushed to the outer cores, resulting in
cache misses. Not all CPU's are equipped with L3 caches. Continuous
syscalls can result in TLB cache misses from what i understand, which
is expensive.
It is very likely that the contents of struct fe to go into the cache during the
syscall. I was conservative when I talked about L3. Depending on the cache
sizes,
I won't doubt that the needed fields of the fe struct will go to L1 cache.
As current CPU's runs at the order of Teraflops (as the CPU clocks are at
gigahertz
order, and CPU's can handle multiple instructions per clock cycle), the
added delay
is in de order of nanosseconds.
Consider STB's where DVB is generally deployed rather than the small
segment of home users running a stack on a generic PC.
Even with STB, let's assume a very slow cpu that runs at 100 Megabytes/second.
So, the clock
speed is 10 nanoseconds. Assuming that this CPU doesn't have a good pipeline,
being
capable of handling only one instruction per second, you'll have one
instruction at executed
at each 10 nanoseconds (as a reference, a Pentium 1, running at 133 Mbps is
faster than this).
An I/O operation at i2c is of the order of 10^-3. Assuming that an additional
delay of 10%
(10 ^ -4) will deadly affect realtime capability (with it is very doubtful),
this means that
the CPU can run up to 10,000 (!!!) instructions to generate such delay. If you
compile that code
and check the number or extra instructions I bet it will be shorter enough to
not cause any
practical effect.
So, even on such bad hardware that is at least 20x slower than a netbook
running at 1Gbps,
what determines the delay is the amount of I/O you're doing, and not the number
of extra
code.
Hardware I/O is the most expensive operation involved.
True. That's what I said.
Case #1: the ioctl approach
code stripped
Now Case #2: based on s2api
code stripped
Now that we can see the actual code flow, we can see the s2api
approach requires an unnecessary large tokenizer/serializer, involving
multiple function calls.
Are you seeing there 10.000 assembler instructions or so? If not, the size of
the code is
not relevant.
Also: gcc optimizer transforms switches into a binary tree. So, if you have 64
cases on switch, it will require 7 comparations (log2(64)) to get a match.
For example, a quick look at the code you've presented, let's just calculate
the number of operations on the dtv_property_proccess_get() routine, without
debug stuff:
static int dtv_property_process_get() {
CMP (if fe-ops.get_property)
CMP (if r 0) This if only happens if the
first one is executed. On my patch, it is not executed
(the code you posted is the one
before my patch)
SWITCH (7 CMP's) due to binary tree optimization
done by gcc
MOV
}
So, that entire code (that has about 200 lines) has, in fact
9 comparations and one move instruction.
At dtv_property_prepare_get_stats(), the code is even cheaper: just a switch
with 8
elements (log2(8) = 3), so 3 comparations, and one move instruction.
The additional cost on dvb_frontend_ioctl_properties is:
2 MOVs
One loop calling dtv_property_prepare_get_stats() - up to 4 times to
retrieve
all quality values
one INC
one CMP and function CALL (the same cost exists also with the struct)
One loop calling dtv_property_get_stats() - up to 4 times to retrieve
all quality values
So, if I've calculated it right, we're talking about 2+1+16+1+2+1+40 = 63
instructions.
So, the real executed code is very cheap. On that very slow CPU, the delay will
be
about 63 x 10 nanosseconds = 630 nanosseconds of delay (being 220ns before the
call and 410ns after it).
This means 0.063% of a delay at the order of milisseconds required just one
I2C read (and, in general, you need more than one single read to get the stats).
Even if the code would double the size, the latency won't be affected.
Aspect #1. Comparing Case #1 and Case #2, i guess anyone will agree
that case 2 has very much code overhead in terms of the serialization
and serialization set/unset.
It has some overhead, but if you are concerned about the realtime case,
just run kernel perf tools. You'll see my point. If you have less I/O
to do (to retrieve just the data you need), Case #2 is much faster than Case #1.
Aspect #2, Comparing the data payload between Case #1 and Case #2, i
guess anyone can
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: Jon Smirl jonsm...@gmail.com writes: Why do you want to pull the 1KB default mapping table out of the device driver __init section and more it to a udev script? Now we will have to maintain a parallel udev script for ever receiver's device driver. Of course no. We will need a single program (script etc.) for all devices. And we will need a database of the known remotes (scan and key codes). The keycode database can be easily extracted from kernel drivers by script. I have it already at V4L/DVB development tree. You can handle that with __devinit __devinit is NOP with hot-plug. Fortunately we don't need the keymaps in the kernel. For certain uses we may (and may not) need to have one keymap built-in, perhaps something similar to the embedded initrd. I still think the better is to have them in kernel, but compiled only if selected at Kbuild. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov wrote: I am a resonable guy ;) In cases when we can certainly say that there are 2 separate remotes (and we know characteristics somehow) we need to create 2 input devices. Otherwise we can't ;) Only on very few specific cases (a few protocols), you can be (almost) sure. Even on this case, universal remotes can fake another IR. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Jon Smirl wrote: I don't like the idea of automatically loading 3 different keycodes at the same time. You may have overlaps between different keycode tables. The better is to have some userspace GUI that will allow the user to select what keycode table(s) he want to be available, if he decides to not use the bundled IR. Of course there is going to be overlap of the keycodes, but not the scancodes. There should be almost 100% overlap. What prevents users to create overlaps at scancodes? We might add some protection, but, providing that different keycode tables can be used by different applications, why do we need to prevent it? The three maps are there to support a non-technical user, a sophisticated user will disable two of them. This works because the non-technical user is only going to use one of the three IR device profiles. The other two may be loaded, but the user isn't sending any IR signals that match their maps. I doubt you can map all cases with just three profiles. Where this breaks down is if they are using SciAtlanta_DVR to control MythTV and they also happen to have a physical Motorola DVR in the same room. The Linux box is going to pick up the commands meant for the Motorola DVR and both boxes will respond.. In that cause they will need to figure figure out how to disable the Motorola DVR profile. I used to have a Set Top Box that has some broken code to decode IR. So, sometimes, when I used to press a key on my TV IR, the STB were getting the code, producing a really bad result. That's really bad. A normal user is able to click on some graphical application and select his IR model. The app may even have some photos or pictures representing the most used IR's. This is better than letting him to to to some forum, asking his friends, etc, trying to figure out why his PC is doing something wrong when he changes a channel on his TV. But is a non-technical person likely to have two DVRs in the same room? Well, I know someone that has an 8 year old children with a setup like this: a PC monitor that has an IR, and a PC with a TV board also with IR. Of course, both the monitor and the PC are at the same room. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, 2009-12-08 at 23:30 +0100, Christoph Bartelmus wrote: Hi Andy, on 07 Dec 09 at 23:10, Andy Walls wrote: [...] (Christoph can correct me if I get anything wrong.) Just a few additions. Christoph, Thanks for the corrections and additions. :) [...] I know that the hardware I work with has sub 100 ns resolution, Highest IR carrier frequency I know is 500kHz. usec resolution is enough even for raw modulated IR pulses. But you only look at the signal after it has been demodulated by the IR chip, so higher resolution would be overkill. Yes, it's overkill. It is more of a side effect of how I set up the hardware to uses as much of the bits in the pulse width measurement counter as possible for the longest expected valid measurment width. The LSB of the hardware pulse width measurement counter can convey a time change of as little as 74 ns depending on the setup of the Conexant integrated IR controller. [...] How do you define the start and stop of sequences? For the end of Rx signalling: Well with the Conexant hardware I can set a maximum pulse (mark or space) width, and the hardware will generate an Rx Timeout interrupt to signal the end of Rx when a space ends up longer than that max pulse width. The hardware also puts a special marker in the hardware pulse widht measurement FIFO (in band signalling essentially). I'm not sure anything like that gets communicated to userspace via lirc_dev, and I'm too tired to doublecheck right now. There is no such thing in the protocol. Some devices cannot provide any end of signal marker, so lircd handles this using timers. If there is some interest, the MODE2 protocol can be extended. We still have 7 bits unused... As I thought about this more, I could just pass up a space the length of the pulse width measurment timeout from the kernel up to LIRC. LIRC's decoders should know that the space is too long as well. No changes needed - I think. [...] Is transmitting synchronous or queued? kfifo's IIRC. No, it's synchronous. How big is the transmit queue? No queue. Oops, thanks for the correction. [...] My particular gripes about the current LIRC interface: 2. I have hardware where I can set max_pulse_width so I can optimize pulse timer resolution and have the hardware time out rapidly on end of RX. I also have hardware where I can set a min_pulse_width to set a hardware low-pass/glitch filter. Currently LIRC doesn't have any way to set these, but it would be nice to have. Should be really easy to add these. The actual values could be derived from the config files easily. Good. I thought it would be so. In band signalling of a hardware detected end of Rx may also make sense then too. See above. 3. As I mentioned before, it would be nice if LIRC could set a batch of parameters atomically somehow, instead of with a series of ioctl()s. I can work around this in kernel though. Is there any particular sequence that you are concerned about? Setting carrier frequency and then duty cycle is a bit problematic. Currently it's solved by resetting the duty cycle to 50% each time you change the carrier frequency. But as the LIRC interface is one user only, I don't see a real problem. The case I worry about is enabling the IR Rx hardware without the low pass filter properly set up to be consistent with the minimum expected Rx pulse width and the desired Rx carrier window or maximum expected Rx pulse width. The result could be a lot of useless interrupts from IR glitch measurements in bad ambient light conditions until all the parameters are consistent. Regards, Andy Christoph -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for 2.6.33] V4L/DVB updates
Linus,
Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
for_linus
For a series of345 patches that contain:
- new tuner driver for max2165;
- new dvb-usb driver for ec168;
- new frontend drivers for atbm8830, ds3000, ec100, stb6100,
- new radio driver for tef6862;
- new gspca drivers for pac7302, stv0680 and w996Xcf;
- new sensor drivers for ov9640 and rj54n1cb0c;
- IR core improvements to dynamically work with scancode/keycode tables;
- DVB docbook improvements to document ISDB-T and S2API;
- lots of drivers fixes, improvements and cleanups.
Cheers,
Mauro.
---
Documentation/DocBook/dvb/dvbapi.xml | 13 +
.../DocBook/dvb/{isdbt.xml = dvbproperty.xml} |4 +
Documentation/DocBook/dvb/frontend.h.xml | 415 ++
Documentation/DocBook/dvb/frontend.xml | 185 +-
Documentation/DocBook/media-entities.tmpl |3 +-
Documentation/DocBook/v4l/controls.xml | 20 +-
Documentation/DocBook/v4l/pixfmt.xml |5 +
Documentation/DocBook/v4l/videodev2.h.xml |7 +-
Documentation/DocBook/v4l/vidioc-g-fbuf.xml| 17 +
Documentation/video4linux/CARDLIST.cx23885 |2 +
Documentation/video4linux/CARDLIST.cx88|1 +
Documentation/video4linux/CARDLIST.em28xx |3 +-
Documentation/video4linux/CARDLIST.saa7134 |2 +
Documentation/video4linux/gspca.txt| 19 +-
Documentation/video4linux/si4713.txt |2 +-
Documentation/video4linux/zr364xx.txt |1 +
drivers/media/common/Makefile |2 +-
drivers/media/common/ir-functions.c| 71 +-
drivers/media/common/ir-keymaps.c | 167 +
drivers/media/common/ir-keytable.c | 429 ++
drivers/media/common/saa7146_video.c | 16 +-
drivers/media/common/tuners/Kconfig|7 +
drivers/media/common/tuners/Makefile |1 +
drivers/media/common/tuners/max2165.c | 442 ++
drivers/media/common/tuners/max2165.h | 48 +
drivers/media/common/tuners/max2165_priv.h | 60 +
drivers/media/common/tuners/mxl5005s.c |5 +-
drivers/media/common/tuners/mxl5005s.h |4 +
drivers/media/common/tuners/mxl5007t.c |2 +-
drivers/media/common/tuners/tda18271-common.c | 16 +-
drivers/media/common/tuners/tda18271-fe.c | 114 +-
drivers/media/common/tuners/tda18271-maps.c|1 +
drivers/media/common/tuners/tda18271-priv.h| 47 +-
drivers/media/common/tuners/tda18271.h | 12 +-
drivers/media/common/tuners/tda8290.c |1 +
drivers/media/common/tuners/tda9887.c |2 +-
drivers/media/common/tuners/xc5000.c | 97 +-
drivers/media/common/tuners/xc5000.h |6 +
drivers/media/dvb/bt8xx/dvb-bt8xx.c|2 +-
drivers/media/dvb/dm1105/dm1105.c | 12 +-
drivers/media/dvb/dvb-core/dvb_demux.c | 39 +
drivers/media/dvb/dvb-core/dvb_demux.h |5 +
drivers/media/dvb/dvb-core/dvb_frontend.c | 179 +-
drivers/media/dvb/dvb-core/dvbdev.h| 28 +
drivers/media/dvb/dvb-usb/Kconfig |8 +
drivers/media/dvb/dvb-usb/Makefile |3 +
drivers/media/dvb/dvb-usb/af9015.c | 33 +-
drivers/media/dvb/dvb-usb/af9015.h | 215 +-
drivers/media/dvb/dvb-usb/cxusb.c | 117 +
drivers/media/dvb/dvb-usb/dib0700_devices.c| 182 +-
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c|1 +
drivers/media/dvb/dvb-usb/dvb-usb-ids.h| 11 +
drivers/media/dvb/dvb-usb/dvb-usb.h|3 +
drivers/media/dvb/dvb-usb/ec168.c | 440 ++
drivers/media/dvb/dvb-usb/ec168.h | 73 +
drivers/media/dvb/dvb-usb/friio-fe.c | 59 +-
drivers/media/dvb/firewire/Kconfig |7 +-
drivers/media/dvb/firewire/Makefile|1 +
drivers/media/dvb/firewire/firedtv-1394.c | 41 +-
drivers/media/dvb/firewire/firedtv-avc.c | 54 +-
drivers/media/dvb/firewire/firedtv-dvb.c | 15 +-
drivers/media/dvb/firewire/firedtv-fw.c| 376 ++
drivers/media/dvb/firewire/firedtv-rc.c|2 +
drivers/media/dvb/firewire/firedtv.h | 19 +-
drivers/media/dvb/frontends/Kconfig| 21 +
drivers/media/dvb/frontends/Makefile |3 +
drivers/media/dvb/frontends/atbm8830.c | 495 ++
drivers/media/dvb/frontends/atbm8830.h | 76 +
drivers/media/dvb/frontends/atbm8830_priv.h| 75 +
drivers/media/dvb/frontends/au8522_decoder.c | 22
